Eigenschaften¶

Die UTF-8-Kodierung hat die folgenden netten Eigenschaften:

•

Die UCS-Zeichen 0x00000000 bis 0x0000007f (die klassischen US-ASCII-Zeichen) werden einfach als die Bytes 0x00 bis 0x7f kodiert und auf diese Weise die ASCII-Kompatibilität hergestellt. Dateinamen und Zeichenketten, die nur aus 7-Bit-ASCII-Zeichen bestehen, haben darum unter ASCII und UTF-8 dieselbe Kodierung.

•

Alle UCS-Zeichen über 0x7f werden als Folge mehrerer Bytes im Bereich 0x80 bis 0xfd dargestellt, so dass kein ASCII-Byte als Teil eines anderen Zeichens auftritt und es keine Probleme z.B. mit »\0« oder »/« gibt.

•

Die lexikographische Sortierreihenfolge von UCS-4-Zeichenketten bleibt erhalten.

•

Alle möglichen 2^31 UCS-Zeichen können mit UTF-8 kodiert werden.

•

Die Bytes 0xc0, 0xc1, 0xfe und 0xff werden in der UTF-8-Kodierung nicht verwendet.

•

Das erste Byte einer Multibyte-Folge, die ein einzelnes nicht in ASCII enthaltenes UCS-Zeichen darstellt, ist grundsätzlich im Bereich 0xc2 bis 0xfd und zeigt die Länge der Folge an. Alle anderen Bytes der Folge sind im Bereich 0x80 bis 0xbf. Dadurch wird eine einfache Neusynchronisierung ermöglich, da die Kodierung zustandslos und daher robust gegenüber fehlenden oder verloren gegangenen Bytes ist.

•

UTF-8-kodierte UCS-Zeichen können bis zu sechs Byte lang sein. Da aber die Unicode-Norm keine Zeichen über 0x10FFFF spezifiziert, können Unicode-Zeichen in UTF-8 nur bis zu vier Byte lang sein.

Kodierung¶

Die folgenden Byte-Folgen werden für die Darstellung eines Zeichens verwendet. Die zu verwendende Folge hängt vom UCS-Code des Zeichens ab:

0x00000000 - 0x0000007F:

0xxxxxxx

0x00000080 - 0x000007FF:

110xxxxx 10xxxxxx

0x00000800 - 0x0000FFFF:

1110xxxx 10xxxxxx 10xxxxxx

0x00010000 - 0x001FFFFF:

11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

0x00200000 - 0x03FFFFFF:

111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

0x04000000 - 0x7FFFFFFF:

1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

Die xxx-Bits werden durch den Code des Zeichens in Binärdarstellung ersetzt, mit dem höchstwertigsten Bit zuerst (Big Endian). Es wird die jeweils kürzeste Multibyte-Folge benutzt, die den Code des Zeichens darstellen kann.

Die UCS-Codewerte 0xd800…0xdfff (UTF-16-Ersatzzeichen) sowie 0xfffe und 0xffff (in UCS keinem Zeichen zugeordnet; UCS noncharacters) sollten nicht in standardkonformen UTF-8-Datenströmen enthalten sein. Gemäß RFC 3629 sollte kein Punkt oberhalb von U+10FFFF verwendet werden, wodurch Zeichen auf vier Byte beschränkt werden.

Beispiel¶

Das Unicode-Zeichen 0xa9 = 1010 1001 (das Copyright-Zeichen) wird in UTF-8 als

dargestellt und das Zeichen 0x2260 = 0010 0010 0110 0000 (das Ungleich-Symbol) als:

Bemerkungen zur Anwendung¶

Anwender müssen, z.B. mit

eine UTF-8-Locale wählen, um die UTF-8-Unterstützung in Programmen zu aktivieren.

Anwendungs-Software, die auf den verwendeten Zeichensatz achten muss, sollte immer, z. B. mit

die Locale setzen und Programmierer anschließend den Ausdruck

auswerten, um festzustellen, ob eine UTF-8-Locale ausgewählt wurde und ob daher sämtliche Standard-Klartexteingaben und -ausgaben, Terminalkommunikation, Klartext-Dateiinhalte, Dateinamen und Umgebungsvariablen in UTF-8 kodiert sind.

Programmers accustomed to single-byte encodings such as US-ASCII or ISO/IEC 8859 have to be aware that two assumptions made so far are no longer valid in UTF-8 locales. Firstly, a single byte does not necessarily correspond any more to a single character. Secondly, since modern terminal emulators in UTF-8 mode also support Chinese, Japanese, and Korean double-width characters as well as nonspacing combining characters, outputting a single character does not necessarily advance the cursor by one position as it did in ASCII. Library functions such as mbsrtowcs(3) and wcswidth(3) should be used today to count characters and cursor positions.

The official ESC sequence to switch from an ISO/IEC 2022 encoding scheme (as used for instance by VT100 terminals) to UTF-8 is ESC % G ("\x1b%G"). The corresponding return sequence from UTF-8 to ISO/IEC 2022 is ESC % @ ("\x1b%@"). Other ISO/IEC 2022 sequences (such as for switching the G0 and G1 sets) are not applicable in UTF-8 mode.

Sicherheit¶

Die Standards Unicode und UCS fordern, dass Erzeuger von UTF-8 die kürzeste mögliche Form liefern. Z. B. ist der Erzeugung einer Zwei-Byte-Sequenz mit dem ersten Byte 0xc0 nicht konform. Unicode 3.1 fordert, dass konforme Programme in ihrer Eingabe Formen, die nicht die kürzesten sind, nicht akzeptieren dürfen. Dies geschieht aus Sicherheitsgründen: Wenn Benutzereingaben auf mögliche Sicherheitsverletzungen überprüft werden, könnte ein Programm nur nach den ASCII-Versionen von "/../" oder ";" oder dem Nullbyte suchen und übersehen, dass es viele Möglichkeiten einer Nicht-ASCII-Darstellung neben der kürzesten UFT-8-Kodierung dieser Zeichen gibt.

Standards¶

ISO/IEC 10646-1:2000, Unicode 3.1, RFC 3629, Plan 9.