Codierungen

Artikel
08/20/2008

Aktualisiert: November 2007

.NET Framework speichert Text intern als Unicode mit UTF-16-Codierung. Diese Textdaten transformiert ein Encoder in eine Bytesequenz. Ein Decoder transformiert dann eine Bytesequenz in dieses interne Format. Eine Codierung beschreibt die Regeln, anhand derer ein Encoder oder Decoder ausgeführt wird. Die UTF8Encoding-Klasse beschreibt z. B. die Regeln für die Codierung und Decodierung einer Bytesequenz, die Text als Unicode mit UTF-8-Codierung darstellt. Die Codierung und Decodierung kann auch bestimmte Validierungsschritte umfassen. Die UnicodeEncoding-Klasse prüft z. B. alle Ersatzzeichen, um sicherzustellen, dass sie gültige Ersatzzeichenpaare bilden. Beide Klassen erben von der Encoding-Klasse.

Auswählen einer Codierung

Gemäß Unicode-Standard wird jedem Zeichen aller unterstützten Schriften ein Codepunkt (eine Zahl) zugewiesen. Dieser Codepunkt kann beispielsweise mit einem UTF (Unicode Transformation Format) codiert werden. Weitere Informationen über die UTFs, die von den Klassen in System.Text unterstützt werden, finden Sie unter "Verwenden der Unicode-Codierung" in Unicode in .NET Framework.

Auswählen einer Encoding-Klasse

Die Encoding-Klasse ist sehr allgemein. Die unterstützten Klassen, die von Encoding erben, ermöglichen .NET-Anwendungen die Verwendung der allgemeinen Codierungen, die häufig in älteren Anwendungen zu finden sind. Zusätzliche Codierungen können von Ihnen implementiert werden. Wenn Sie jedoch die Möglichkeit zur Auswahl einer Codierung haben, wird dringend empfohlen, eine Unicode-Codierung zu verwenden, normalerweise UTF8Encoding oder UnicodeEncoding (UTF32Encoding wird ebenfalls unterstützt). Dabei wird UTF8Encoding gegenüber ASCIIEncoding bevorzugt. Wenn es sich um ASCII-Inhalte handelt, sind die beiden Codierungen identisch. UTF8Encoding kann jedoch auch alle Unicode-Zeichen darstellen, wohingegen ASCIIEncoding nur die Unicode-Zeichenwerte zwischen U+0000 und U+007F unterstützt. Da ASCIIEncoding keine Fehlererkennung bereitstellt, bietet UTF8Encoding auch im Hinblick auf die Sicherheit die größeren Vorteile.

UTF8Encoding wurde auf schnellstmögliche Codierung optimiert und sollte daher schneller sein als jede andere Codierung. Selbst bei Inhalten, bei denen es sich um reine ASCII-Daten handelt, erfolgen mit UTF8Encoding durchgeführte Operationen schneller als mit ASCIIEncoding durchgeführte Operationen. Sie sollten daher in Erwägung ziehen, ASCIIEncoding nur für bestimmte ältere Anwendungen zu verwenden. Doch selbst in diesem Fall stellt UTF8Encoding möglicherweise die bessere Wahl dar. Ausgehend von den Standardeinstellungen sind folgende Szenarien möglich:

Wenn die Anwendung Inhalte, die keine reinen ASCII-Daten sind, mit ASCIIEncoding codiert, wird jedes Nicht-ASCII-Zeichen als Fragezeichen ("?") codiert. Wenn die Anwendung diese Daten anschließend decodiert, gehen die Informationen verloren.
Wenn die Anwendung Inhalte, die keine reinen ASCII-Daten sind, mit UTF8Encoding codiert und als ASCII-Daten interpretiert, so erscheint das Ergebnis unverständlich. Wenn die Anwendung diese Daten aber anschließend decodiert, durchlaufen die Daten einen erfolgreichen Roundtrip.

Auswählen einer Fallbackstrategie

Wenn eine Anwendung versucht, ein Zeichen, für das keine Zuordnung vorhanden ist, zu codieren oder zu decodieren, muss sie eine Fallbackstrategie, also eine Fehlerbehandlungsroutine implementieren. Es gibt zwei Arten von Fallbackstrategien:

Fallback mit ähnlichen Zeichen

Wenn die Zeichen in der Zielcodierung/-decodierung keine genaue Entsprechung besitzen, kann die Anwendung versuchen, sie einem ähnlichen Zeichen zuzuordnen.
Fallback mit Ersatzzeichenfolge

Wenn kein ähnliches Zeichen vorhanden ist, kann die Anwendung eine Ersatzzeichenfolge angeben.

Beispielsweise kann eine Anwendung GetEncoding(1252, 0, 0) aufrufen (siehe GetEncoding). Hierdurch wird Codepage 1252 (die Windows-Codepage für westeuropäische Sprachen) angegeben, wobei encoderFallback und decoderFallback auf 0 (null) festgelegt sind. Als Standardverhalten erfolgt für bestimmte Unicode-Zeichen eine Zuordnung mit ähnlichen Zeichen. So wird z. B. CIRCLED LATIN CAPITAL LETTER S (eingekreister lateinischer Großbuchstabe S, U+24C8) vor der Codierung in LATIN CAPITAL LETTER S (lateinischer Großbuchstabe S, U+0053) geändert, während SUPERSCRIPT FIVE (hochgestellte Fünf, U+2075) in DIGIT FIVE (Ziffer Fünf, U+0035) geändert wird. Wenn die Anwendung die Daten anschließend von Codepage 1252 wieder in Unicode decodiert, geht der Kreis um den Buchstaben verloren, und 2⁵ wird zu 25. Andere Konvertierungen können sogar noch drastischere Auswirkungen haben. Das INFINITY-Symbol (Unendlichkeitssymbol, U+221E) in Unicode könnte z. B. DIGIT EIGHT (Ziffer Acht, U+0038) zugeordnet werden.

Die Strategien mit ähnlichen Zeichen variieren bei den verschiedenen Codepages und sind nicht detailliert dokumentiert. Beispielsweise werden bei einigen Codepages lateinische Zeichen in voller Breite den gängigeren halbbreiten lateinischen Zeichen zugeordnet. Bei anderen Codepages hingegen erfolgt diese Zuordnung nicht.

Selbst bei einer aggressiven Strategie mit ähnlichen Zeichen besteht in einigen Codierungen für manche Zeichen keine denkbare Zuordnung. Ein chinesisches Idiogramm etwa besitzt in Codepage 1252 keine sinnvolle Zuordnung. In diesem Fall wird eine Ersatzzeichenfolge verwendet. Standardmäßig handelt es sich bei dieser Zeichenfolge um ein einzelnes QUESTION MARK (Fragezeichen, U+003F).

Die Zuordnung mit ähnlichen Zeichen ist das Standardverhalten für Encoding, wodurch Unicode-Daten in Codepagedaten codiert werden. Es gibt ältere Anwendungen, die auf diesem Verhalten basieren. In den meisten neuen Anwendungen sollte dieses Verhalten jedoch aus Sicherheitsgründen vermieden werden. Durch eine Codierung mit ähnlichen Zeichen sollten Anwendungen z. B. keinen Domänennamen ausdrücken.

Die Anwendungen sollten die folgenden Alternativen zur Zuordnung ähnlicher Zeichen verwenden:

Verwenden Sie nur Unicode-Codierungen (UTF8Encoding, UnicodeEncoding und UTF32Encoding), um Fallbackprobleme zu vermeiden.

Vorsicht:
UTF7Encoding stellt technisch zwar eine Unicode-Codierung dar, ist aber weniger robust und sicher als die anderen Codierungen. In einigen Situationen kann die Änderung eines Bits die Interpretation einer ganzen UTF-7-Zeichenfolge radikal ändern. In anderen Situationen können grundlegend andere UTF-7-Zeichenfolgen den gleichen Text codieren. Folglich sollten Sie UTF-7 nicht verwenden, wenn Sie die Wahl zwischen mehreren Codierungen haben. UTF-8 wird gegenüber UTF-7 vorgezogen.

UTF7Encoding stellt technisch zwar eine Unicode-Codierung dar, ist aber weniger robust und sicher als die anderen Codierungen. In einigen Situationen kann die Änderung eines Bits die Interpretation einer ganzen UTF-7-Zeichenfolge radikal ändern. In anderen Situationen können grundlegend andere UTF-7-Zeichenfolgen den gleichen Text codieren. Folglich sollten Sie UTF-7 nicht verwenden, wenn Sie die Wahl zwischen mehreren Codierungen haben. UTF-8 wird gegenüber UTF-7 vorgezogen.

Verwenden Sie EncoderExceptionFallback und DecoderExceptionFallback. Sie lösen eine Ausnahme aus (EncoderFallbackException bzw. DecoderFallbackException), falls ein Zeichen nicht genau zugeordnet wird.
Verwenden Sie grundsätzlich EncoderReplacementFallback und DecoderReplacementFallback, um eine Ersatzzeichenfolge einzusetzen, falls ein Zeichen nicht genau zugeordnet wird. Dies ist das Standardverhalten für ASCIIEncoding. Bei dieser Zeichenfolge handelt es sich standardmäßig nur um ein Fragezeichen. Es werden jedoch Methoden bereitgestellt, mit denen in einer Anwendung eine andere Zeichenfolge ausgewählt werden kann. Dies ist in der Regel, aber nicht notwendigerweise ein einzelnes Zeichen. DecoderReplacementFallback wird bei der Transformation von Text in Unicode verwendet. Ein dabei häufig verwendetes Zeichen ist REPLACEMENT CHARACTER (Ersatzzeichen, U+FFFD).
Verwenden Sie einen benutzerdefinierten EncoderFallback und/oder DecoderFallback, um eine bevorzugte Strategie zu implementieren. Weitere Informationen finden Sie unter Anwendungsbeispiel für Fallbackcodierung.

Zwei weitere Hinweise zu Fallbackstrategien für die Codierung (oder Decodierung) mit ähnlichen Zeichen:

Die Zuordnung ähnlicher Zeichen stellt meist ein Codierungsproblem und kein Decodierungsproblem dar. Es gibt sehr wenige Codepages, die Zeichen enthalten, die in Unicode nicht erfolgreich zugeordnet werden können. Da diese Zeichen nicht häufig verwendet werden, wurden sie in Unicode ausgelassen.
Es gibt keine unterstützten benannten Objekte, die den Fallbacks mit ähnlichen Zeichen entsprechen. Das Fallback mit ähnlichen Zeichen ist für jede Codepage verschieden. Wenn die Anwendung für ein einzelnes Encoding-Objekt zwischen einem Fallback mit ähnlichen Zeichen und einem anderen Fallback wechseln muss, sollte sie in einer Variablen eine Kopie des ursprünglich am besten geeigneten Objekts speichern, bevor sie ein anderes Fallbackobjekt zuweist. Anschließend kann die Anwendung das Fallback mit ähnlichen Zeichen wiederherstellen, indem sie Encoding.EncoderFallback (oder Encoding.DecoderFallback) diesen Wert erneut zuweist.