Bewährte Methoden für die Entwicklung weltweit einsatzbereiter Anwendungen

In diesem Abschnitt werden die bewährten Methoden beschrieben, die sie beim Entwickeln von weltweit einsatzbereiten Anwendungen befolgen müssen.

Bewährte Methoden für die Globalisierung

1. Machen Sie Ihre Anwendung intern unicode.

2. Verwenden Sie die kulturfähigen Klassen, die vom System.Globalization Namespace bereitgestellt werden, um Daten zu bearbeiten und zu formatieren.

   • Verwenden Sie zum Sortieren die SortKey Klasse und die CompareInfo Klasse.
   • Verwenden Sie für Zeichenfolgenvergleiche die CompareInfo Klasse.
   • Verwenden Sie für die Datums- und Uhrzeitformatierung die DateTimeFormatInfo Klasse.
   • Verwenden Sie für numerische Formatierungen die NumberFormatInfo Klasse.
   • Verwenden Sie für gregorianische und nicht gregorianische Kalender die Calendar Klasse oder eine der spezifischen Kalenderimplementierungen.

3. Verwenden Sie die Kultureigenschaften-Einstellungen, die von der System.Globalization.CultureInfo Klasse in den geeigneten Situationen bereitgestellt werden. Verwenden Sie die CultureInfo.CurrentCulture Eigenschaft zum Formatieren von Aufgaben, z. B. Datum und Uhrzeit oder numerische Formatierung. Verwenden Sie die CultureInfo.CurrentUICulture Eigenschaft, um Ressourcen abzurufen. Die CurrentCulture-Eigenschaft und die CurrentUICulture-Eigenschaft können für jeden Thread einzeln festgelegt werden.

4. Ermöglichen Sie Der Anwendung das Lesen und Schreiben von Daten in und aus einer Vielzahl von Codierungen mithilfe der Codierungsklassen im System.Text Namespace. Gehen Sie nicht von ASCII-Daten aus. Gehen Sie davon aus, dass internationale Zeichen überall bereitgestellt werden, wo ein Benutzer Text eingeben kann. Beispielsweise sollte die Anwendung internationale Zeichen in Servernamen, Verzeichnissen, Dateinamen, Benutzernamen und URLs akzeptieren.

5. Wenn Sie die UTF8Encoding Klasse aus Sicherheitsgründen verwenden, verwenden Sie die von dieser Klasse angebotene Fehlererkennungsfunktion. Erstellen Sie zum Aktivieren des Fehlererkennungsfeatures eine Instanz der Klasse mithilfe des Konstruktors, der einen throwOnInvalidBytes Parameter verwendet, und legen Sie den Wert dieses Parameters auf true.

6. Behandeln Sie Zeichenfolgen nach Möglichkeit als ganze Zeichenfolgen anstelle einer Reihe einzelner Zeichen. Dies ist besonders wichtig beim Sortieren oder Suchen nach Teilzeichenfolgen. Dadurch werden Probleme im Zusammenhang mit der Analyse kombinierter Zeichen verhindert. Sie können auch mit Texteinheiten und nicht mit einzelnen Zeichen arbeiten, indem Sie die System.Globalization.StringInfo Klasse verwenden.

7. Zeigen Sie Text mithilfe der klassen an, die vom System.Drawing Namespace bereitgestellt werden.

8. Um Konsistenz über alle Betriebssysteme hinweg sicherzustellen, dürfen Benutzereinstellungen CultureInfo nicht überschreiben. Verwenden Sie den CultureInfo Konstruktor, der einen useUserOverride Parameter akzeptiert, und setzen Sie diesen auf false.

9. Testen Sie ihre Anwendungsfunktionalität auf internationalen Betriebssystemversionen mit internationalen Daten.

10. Wenn eine Sicherheitsentscheidung auf dem Ergebnis eines Zeichenfolgenvergleichs oder der Änderung der Groß-/Kleinschreibung beruht, sollten Sie eine kulturunabhängige Zeichenfolgenoperation verwenden. Diese Praxis stellt sicher, dass das Ergebnis nicht vom Wert von CultureInfo.CurrentCulture beeinflusst wird. Im Abschnitt "Zeichenfolgenvergleiche, die die aktuelle Kultur verwenden" der Bewährten Methoden für die Verwendung von Zeichenfolgen finden Sie ein Beispiel, in dem veranschaulicht wird, wie kultursensitive Zeichenfolgenvergleiche zu inkonsistenten Ergebnissen führen können.

11. Verwenden Sie CultureInfo für jedes Element, das für den Austausch verwendet wird (z. B. ein Feld in einem JSON-Dokument in einem API-Aufruf) oder zur Speicherung dient; zusätzlich sollten Sie explizit ein Roundtrip-Format angeben (z. B. den "O""o" Datums- und Uhrzeit-Formatbezeichner). Obwohl die Formatzeichenfolgen für die invariante Kultur stabil sind und sich wahrscheinlich nicht ändern, kann die Angabe einer expliziten Formatzeichenfolge dazu beitragen, die Absicht Ihres Codes zu verdeutlichen.

    • Berücksichtigen Sie für Datums-/Uhrzeitelemente die Ratschläge und Beobachtungen des Noda Time-Autors Jon Skeet, der wertvolle Erkenntnisse teilt. Weitere Informationen finden Sie unter Jon Skeet: Das Speichern von UTC ist kein Allheilmittel.

12. Globalisierungsdaten sind nicht stabil, und Sie sollten Ihre Anwendung und deren Tests mit diesem Aspekt schreiben. Es wird mehrmals pro Jahr über Hostbetriebssystemkanäle auf allen unterstützten Plattformen aktualisiert. Diese Daten werden in der Regel nicht mit der Laufzeit verteilt.

Bewährte Methoden für die Lokalisierung

1. Verschieben Sie alle lokalisierbaren Ressourcen in DLLs, die nur für Ressourcen vorgesehen sind. Lokalisierbare Ressourcen umfassen Elemente der Benutzeroberfläche, z. B. Zeichenfolgen, Fehlermeldungen, Dialogfelder, Menüs und eingebettete Objektressourcen.

2. Codieren Sie keine Zeichenfolgen oder Ressourcen der Benutzeroberfläche.

3. Speichern Sie in den DLLs, die nur für Ressourcen vorgesehen sind, keine nicht lokalisierbaren Ressourcen. Dies verwirrt Übersetzer.

4. Verwenden Sie keine zusammengesetzten Zeichenfolgen, die zur Laufzeit aus verketteten Ausdrücken erstellt werden. Zusammengesetzte Zeichenfolgen sind schwierig zu lokalisieren, da sie häufig eine englische Grammatikreihenfolge annehmen, die nicht für alle Sprachen gilt.

5. Vermeiden Sie mehrdeutige Konstrukte wie "Leerer Ordner", bei denen die Zeichenfolgen je nach grammatikalischen Rollen der Zeichenfolgenkomponenten unterschiedlich übersetzt werden können. Beispielsweise kann "leer" entweder ein Verb oder ein Adjektiv sein, was zu unterschiedlichen Übersetzungen in Sprachen wie Italienisch oder Französisch führen kann.

6. Vermeiden Sie die Verwendung von Bildern und Symbolen, die Text in Ihrer Anwendung enthalten. Sie sind teuer zu lokalisieren.

7. Für die Erweiterung der Zeichenfolgen sollte auf der Benutzeroberfläche viel Platz vorhanden sein. In einigen Sprachen können Ausdrücke 50-75 Prozent mehr Platz benötigen als in anderen Sprachen.

8. Verwenden Sie die System.Resources.ResourceManager Klasse, um Ressourcen basierend auf der Kultur abzurufen.

9. Verwenden Sie Visual Studio , um Windows Forms-Dialogfelder zu erstellen, damit sie mithilfe des Windows Forms-Ressourcen-Editors (Winres.exe) lokalisiert werden können. Windows Forms-Dialogfelder dürfen nicht manuell codiert werden.

10. Ordnen Sie die professionelle Lokalisierung (Übersetzung) an.

11. Eine vollständige Beschreibung des Erstellens und Lokalisierens von Ressourcen finden Sie unter Ressourcen in .NET-Apps.

Bewährte Methoden für die Globalisierung für ASP.NET und andere Serveranwendungen

1. Legen Sie die Eigenschaften CurrentUICulture und CurrentCulture in Ihrer Anwendung explizit fest. Verlassen Sie sich nicht auf Standardwerte.

2. Beachten Sie, dass ASP.NET Anwendungen verwaltete Anwendungen sind und daher dieselben Klassen wie andere verwaltete Anwendungen zum Abrufen, Anzeigen und Bearbeiten von Informationen basierend auf Kultur verwenden können.

3. Beachten Sie, dass Sie die folgenden drei Codierungstypen in ASP.NET angeben können:

   • requestEncoding Gibt die vom Browser des Clients empfangene Codierung an.
   • responseEncoding Gibt die Codierung an, die an den Clientbrowser gesendet werden soll. In den meisten Fällen sollte diese Codierung dieselbe sein wie die, die für requestEncoding angegeben wurde.
   • fileEncoding gibt die Standardcodierung für .aspx-, ASMX- und ASAX-Dateianalyse an.

4. Geben Sie die Werte für die requestEncoding, responseEncoding, fileEncoding, culture und uiCulture-Attribute an den folgenden drei Stellen in einer ASP.NET-Anwendung an.

   • Im Abschnitt "Globalisierung" einer Web.config Datei. Diese Datei ist außerhalb der ASP.NET Anwendung. Weitere Informationen finden Sie unter <globalization> Element.
   • In einer Seitendirektive. Beachten Sie, dass die Datei bereits gelesen wurde, wenn sich eine Anwendung auf einer Seite befindet. Daher ist es zu spät, fileEncoding und requestEncoding anzugeben. Nur uiCulture, culture, und responseEncoding kann in einer Seitendirektive angegeben werden.
   • Programmgesteuert im Anwendungscode. Diese Einstellung kann je nach Anforderung variieren. Wie bei der Seitenanweisung ist es bei Erreichen des Anwendungscodes bereits zu spät für die Festlegung von Werten für fileEncoding und requestEncoding. Nur uiCulture, culture, und responseEncoding kann im Anwendungscode angegeben werden.

5. Der uiCulture-Wert kann auf die vom Browser akzeptierte Sprache festgelegt werden.

6. Für Anwendungen, die verteilt werden und Updates ohne Ausfallzeiten zulassen (z. B. Azure Container-Apps), oder ähnlichen Szenarien, müssen Sie Situationen berücksichtigen, in denen möglicherweise mehrere Instanzen der Anwendung mit unterschiedlichen Formatregeln oder anderen kulturellen Daten bestehen, insbesondere bezüglich der Zeitzonenregelungen.

   • Wenn Ihre Anwendungsbereitstellung eine Datenbank enthält, denken Sie daran, dass die Datenbank über eigene Globalisierungsregeln verfügt. In den meisten Fällen sollten Sie keine globalisierungsbezogenen Funktionen in der Datenbank ausführen.
   • Wenn Ihre Anwendungsbereitstellung eine Clientanwendung oder ein Web-Frontend mit Ressourcen für die Client-Globalisierung enthält, gehen Sie davon aus, dass sich die Clientressourcen von den ressourcen unterscheiden, die für Ihren Server verfügbar sind. Erwägen Sie die ausschließliche Durchführung von Globalisierungsfunktionen auf dem Client.

Empfehlungen für robuste Tests

1. Um Abhängigkeiten expliziter zu machen und das Testen möglicherweise zu erleichtern und parallelisierbar zu gestalten, sollten Sie erwägen, kulturrelevante Einstellungen, wie z. B. Parameter, explizit an Methoden zu übergeben, die Formatierungen ausführen, und an CultureInfo Methoden, die mit Datums- und Uhrzeitwerten arbeiten. Sie sollten außerdem beim Abrufen der Uhrzeit TimeProvider oder einen ähnlichen Typ verwenden.

2. Bei den meisten Tests sollten Sie nicht explizit die genaue Ausgabe eines bestimmten Formatierungsvorgangs oder den genauen Offset einer Zeitzone überprüfen. Formatierungs- und Zeitzonendaten können sich jederzeit ändern und können sich zwischen zwei anderen identischen Instanzen eines Betriebssystems (und potenziell unterschiedlichen Prozessen auf demselben Computer) unterscheiden. Die Verwendung eines genauen Werts macht Tests anfällig.

   • Im Allgemeinen ist die Überprüfung, dass einige Ausgaben empfangen wurden, ausreichend (z. B. nicht leere Zeichenfolgen beim Formatieren).
   • Bei einigen Datenelementen und -formaten können Sie stattdessen überprüfen, ob die Daten im Eingabewert geparst werden (Roundtripping). Es ist auf Fälle zu achten, in denen Felder verworfen werden (z. B. das Jahr bei einigen datumsbezogenen Feldern), oder wenn der Wert abgeschnitten oder gerundet wird (wie bei der Gleitkommaausgabe).
   • Wenn Sie explizite Anforderungen zur Überprüfung aller lokalisierten Formatausgaben haben, sollten Sie im Rahmen der Testeinrichtung eine benutzerdefinierte Kultur erstellen und verwenden. In den meisten einfachen Fällen kann dies durch Instanziieren eines CultureInfo Objekts mit dem Konstruktor new CultureInfo(..) und Festlegen der DateTimeFormat Eigenschaften NumberFormat erfolgen. Bei komplizierteren Fällen ermöglicht die Unterklassifizierung des Typs das Überschreiben zusätzlicher Eigenschaften. Dies bietet potenzielle zusätzliche Vorteile, wie z. B. die Möglichkeit zur Pseudolokalisierung mit Ressourcendateien.
   • Wenn Sie explizite Anforderungen haben, um die Ergebnisse aller Datums-/Uhrzeitvorgänge zu überprüfen, sollten Sie bei der Testeinrichtung eine benutzerdefinierte TimeZoneInfo Instanz erstellen und verwenden. Dies bietet möglicherweise noch weitere Vorteile, da Sie z. B. stabile Tests bestimmter Sonderfälle (z. B. auf Änderungen an DST-Regeln) aktivieren können.

Siehe auch

• Globalisierung und Lokalisierung
• Ressourcen in .NET-Apps