Provided by: manpages-de_4.23.1-1_all bug

BEZEICHNUNG

       UTF-8 - eine ASCII-kompatible Multibyte-Unicode-Kodierung

BESCHREIBUNG

       Der  Unicode-3.0-Zeichensatz  ist  durch  16-Bit-Wörter  definiert.  Die offensichtlichste
       Unicode-Kodierung (UCS-2) besteht aus einer Folge von 16-Bit-Zeichen. Solche Zeichenketten
       können  –  als Bestandteile vieler 16-Bit-Zeichen – Bytes wie »\0« oder »/« enthalten, die
       z. B. in Dateinamen und anderen  Argumenten  von  C-Bibliotheksfunktionen  eine  besondere
       Bedeutung haben. Außerdem arbeiten die meisten UNIX-Programme mit ASCII-Dateien und können
       16-Bit-Wörter nicht ohne größere Änderungen verarbeiten. Darum ist UCS-2  keine  geeignete
       externe  Kodierung  von  Unicode  in Dateinamen, Text-Dateien, Umgebungsvariablen usw. Der
       ISO/IEC 10646 Universal Character Set (UCS), eine Erweiterung von  Unicode,  belegt  sogar
       einen  noch  größeren  Code-Raum – 31 Bit. Die offensichtliche UCS-4-Kodierung dafür (eine
       Folge von 32-Bit-Wörtern) leidet unter denselben Problemen wie die UCS-2-Kodierung.

       Die  UTF-8-Kodierung  von  Unicode  und  UCS  hat  diese  Probleme  nicht.  Sie  ist   der
       gebräuchliche Anwendungsfall des Unicode-Zeichensatzes auf UNIX-artigen Betriebssystemen.

   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

              11000010 10101001 = 0xc2 0xa9

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

              11100010 10001001 10100000 = 0xe2 0x89 0xa0

   Bemerkungen zur Anwendung
       Anwender müssen, z.B. mit

              export LANG=en_GB.UTF-8,

       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

              setlocale(LC_CTYPE, ""),

       die Locale setzen und Programmierer anschließend den Ausdruck

              strcmp(nl_langinfo(CODESET), "UTF-8") == 0

       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.

       An  Einzel-Byte-Kodierungen  wie  US-ASCII oder ISO/IEC 8859 gewöhnte Programmierer müssen
       daran denken, dass zwei bislang getroffene Annahmen in  UTF-8-Locales  nicht  mehr  gültig
       sind.  Erstens  bedeutet  ein  einziges  Byte  nicht mehr unbedingt ein einzelnes Zeichen.
       Zweitens, da moderne Terminal-Emulatoren im UTF-8-Modus auch chinesische,  japanische  und
       koreanische  Zeichen doppelter Breite sowie Kombinationszeichen ohne horizontalen Vorschub
       unterstützen, setzt die Ausgabe eines einzelnen Zeichens nicht  unbedingt  den  Cursor  um
       eine   Position   weiter,   wie  es  bei  ASCII  der  Fall  war.  Heutzutage  sollten  Sie
       Bibliotheksfunktionen  wie  mbsrtowcs(3)  und   wcswidth(3)   nutzen,   um   Zeichen   und
       Cursorpositionen zählen.

       Die  offizielle  Escape-Sequenz  aus einem ISO/IEC-2022-Kodierungsschema (wie zum Beispiel
       von VT100-Terminals verwendet) nach UTF-8  ist  ESC  %  G  ("\x1b%G").  Die  entsprechende
       Sequenz  für  die  Rückkehr  von  UTF-8  zu  ISO/IEC 2022  ist  ESC % @ ("\x1b%@"). Andere
       ISO/IEC-2022-Sequenzen (wie zum Umschalten der G0- und G1-Sätze) sind im UTF-8-Modus nicht
       anwendbar.

   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.

SIEHE AUCH

       locale(1), nl_langinfo(3), setlocale(3), charsets(7), unicode(7)

ÜBERSETZUNG

       Die   deutsche   Übersetzung   dieser   Handbuchseite   wurde   von    Sebastian    Rittau
       <srittau@jroger.in-berlin.de>   und   Martin  Eberhard  Schauer  <Martin.E.Schauer@gmx.de>
       erstellt.

       Diese Übersetzung ist Freie Dokumentation;  lesen  Sie  die  GNU  General  Public  License
       Version  3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copyright-
       Bedingungen. Es wird KEINE HAFTUNG übernommen.

       Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-
       Mail an die Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.