Codepages

  • Artikel

Die meisten heute geschriebenen Anwendungen verarbeiten Zeichendaten hauptsächlich als Unicode, wobei die UTF-16-Codierung verwendet wird. Viele Legacyanwendungen verwenden jedoch weiterhin Zeichensätze, die auf Codepages basieren. Auch neue Anwendungen müssen manchmal mit Codepages arbeiten, oft aus einem der folgenden Gründe:

  • Um mit Legacyanwendungen zu kommunizieren.
  • Um mit älteren E-Mail- und Nachrichtenservern zu kommunizieren, die Unicode möglicherweise nicht immer unterstützen.
  • Für die Kommunikation mit der Windows-Konsole für Legacyzwecke. (Die Konsole unterstützt Unicode, aber einige legacy-Befehlszeilenanwendungstools möglicherweise nicht.)

Hinweis

Neue Windows-Anwendungen sollten Unicode verwenden, um die Inkonsistenzen unterschiedlicher Codeseiten zu vermeiden und die Lokalisierung zu erleichtern.

 

Jede Codepage wird durch einen Codepagebezeichner( z. B. 1252) dargestellt und von den API-Funktionen Unicode und Zeichensatz behandelt. Eine Liste der unterstützten Codepagebezeichner finden Sie unter Codepage-Bezeichner. Die Referenz "Code Pages" im Microsoft Go Global Developer Center enthält vollständige Beschreibungen vieler Codepages.

Windows-Codepages, die häufig als "ANSI-Codepages" bezeichnet werden, sind Codepages, für die Nicht-ASCII-Werte (Werte größer als 127) internationale Zeichen darstellen. Diese Codepages werden nativ in Windows Me verwendet und sind auch unter Windows NT und höher verfügbar.

Hinweis

Ursprünglich basierte die Windows-Codepage 1252, die häufig für Englisch und andere westeuropäische Sprachen verwendete Codepage, auf einem Entwurf des American National Standards Institute (ANSI). Dieser Entwurf wurde schließlich ISO 8859-1, aber die Windows-Codepage 1252 wurde implementiert, bevor die Norm endgültig wurde, und entspricht nicht genau der ISO 8859-1.

 

Viele Windows-API-Funktionen verfügen über die Versionen "A" (ANSI) und "W" (breit, Unicode). Die "A"-Version verarbeitet Text basierend auf Windows-Codepages, während die "W"-Version Unicode-Text verarbeitet. Weitere Informationen finden Sie unter Windows-Datentypen für Zeichenfolgen und Konventionen für Funktionsprototypen.

Windows-Codepages werden manchmal auch als "aktive Codepages" oder "systemaktive Codepages" bezeichnet. Ein Windows-Betriebssystem verfügt immer über eine aktuell aktive Windows-Codepage. Alle ANSI-Versionen von API-Funktionen verwenden die aktuell aktive Codepage.

OEM-Codepages (Original Equipment Manufacturer) sind Codepages, für die Nicht-ASCII-Werte Linienzeichnungs- und Satzzeichen darstellen. Diese Codepages wurden ursprünglich für MS-DOS verwendet und werden weiterhin für Konsolenanwendungen verwendet. Sie werden auch für die nicht erweiterten Dateinamen in den Dateisystemen FAT12, FAT16 und FAT32 verwendet, wie unter In Dateinamen verwendete Zeichensätze beschrieben. Die übliche OEM-Codepage für Englisch ist die Codepage 437.

Sowohl für Windows-Codeseiten als auch für OEM-Codepages entsprechen die Codewerte 0x00 bis 0x7F dem 7-Bit-ASCII-Zeichensatz. Codewerte 0x00 über 0x19 und 0x7F immer standardisierte Steuerzeichen darstellen und 0x20 bis 0x7E standardisierte anzeigebare Zeichen darstellen. Zeichen, die durch die restlichen Codes dargestellt werden, 0x80 bis 0xff, variieren zwischen den Zeichensätzen. Jeder Zeichensatz enthält verschiedene Sonderzeichen, die in der Regel für eine Sprache oder Gruppe von Sprachen angepasst werden. Die Windows-Codepage 1252 und die OEM-Codepage 437 werden in der Regel in der USA verwendet.

Zusätzlich zu Windows- und OEM-Codepages können Ihre Anwendungen nicht native Codepages verwenden. Beispiele hierfür sind EBCDIC- und Macintosh-Codepages.

Zwei Unicode-Codierungen (UTF-7 und UTF-8) werden als Codepages implementiert. Wie andere Codepages ist jede Seite durch einen numerischen Bezeichner bekannt und kann mit vielen der gleichen Unicode- und Zeichensatz-API-Funktionen behandelt werden.

Codepages können SBCS-Seiten (Single-Byte Character Set ) oder DBCS-Seiten (Double-Byte Character Set ) sein. Auf SBCS-Seiten codiert jedes Byte direkt ein einzelnes Zeichen, sodass es möglich ist, genau 256 verschiedene Zeichen darzustellen (einschließlich Steuerzeichen, Buchstaben, Ziffern, Interpunktion, Symbole usw.). DBCS-Codepages werden für Sprachen wie Japanisch und Chinesisch verwendet. In einer solchen Codepage verfügen einige Zeichen über Zwei-Byte-Codierungen mit bestimmten Bytewerten (immer Werte größer als 127), die als "Leadbytes" dienen. Anstatt Zeichen selbst zu codieren, können Leadbytes nur in Verbindung mit einem "Trail byte" einem Zeichen zugeordnet werden.

Einige Legacyprotokolle erfordern die Verwendung von SBCS- und DBCS-Codepages. Jede SBCS/DBCS-Codepage unterstützt unterschiedliche Zeichen, aber keine Codepage unterstützt die volle Breite der von Unicode bereitgestellten Zeichen. Jede SBCS/DBCS-Codepage unterstützt eine andere Teilmenge, die unterschiedlich codiert ist.

Hinweis

Daten, die von einer SBCS- oder DBCS-Codepage in eine andere konvertiert werden, sind beschädigt, da derselbe Datenwert auf verschiedenen Codeseiten ein anderes Zeichen codieren kann. Daten, die aus Unicode in SBCS oder DBCS konvertiert werden, unterliegen Datenverlust, da eine bestimmte Codepage möglicherweise nicht in der Lage ist, jedes Zeichen darzustellen, das in diesen bestimmten Unicode-Daten verwendet wird.

 

Zusätzlich zu SBCS- und DBCS-Codepages verfügen Ihre Anwendungen über die Multibyte-Zeichensatz-Codepages 52936, 54936, 51949 und 5022x, die einen ähnlichen Ansatz wie für einen DBCS verwenden. Eine Multibyte-Zeichensatzcodepage geht jedoch über die Zwei-Byte-Codierungen einiger Zeichen hinaus. UTF-7 und UTF-8 verwenden einen ähnlichen Ansatz, um Unicode basierend auf einem 7-Bit- bzw. 8-Bit-Bytes zu codieren. Weitere Informationen finden Sie unter Unicode.

Mehrere Unicode- und Zeichensatzfunktionen ermöglichen es Ihren Anwendungen, Codepages zu verarbeiten. Eine Anwendung kann die Funktionen GetCPInfo und GetCPInfoEx verwenden, um Informationen zu einer Codepage abzurufen. Diese Informationen enthalten das Standardzeichen, das verwendet wird, wenn ein Zeichen in einer konvertierten Zeichenfolge keinen entsprechenden Eintrag auf der Codepage aufweist.

Eine Anwendung kann die Funktionen MultiByteToWideChar und WideCharToMultiByte verwenden, um zwischen Zeichenfolgen basierend auf Windows-Codepages und Unicode-Zeichenfolgen zu konvertieren. Obwohl ihre Namen auf "MultiByte" verweisen, funktionieren diese Funktionen genauso gut mit SBCS-, DBCS- und Multibyte-Zeichensatz-Codepages.

Hinweis

WideCharToMultiByte kann einige Daten verlieren, wenn die angegebene Codepage nicht alle Zeichen in einer Unicode-Zeichenfolge darstellen kann.

 

Ihre Anwendung kann zwischen Windows-Codeseiten und OEM-Codepages mit den Standardfunktionen der C-Runtime-Bibliothek konvertieren. Die Verwendung dieser Funktionen stellt jedoch das Risiko eines Datenverlusts dar, da die Zeichen, die von jeder Codepage dargestellt werden können, nicht genau übereinstimmen.

Ihre Anwendungen können auch die GetACP-Funktion aufrufen. Diese Funktion ruft den Bezeichner der aktuellen Windows-Codepage (ANSI) ab.

Zeichensätze