Provided by: manpages-de_2.5-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
       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  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-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 2022 ist ESC % @ ("\x1b%@").  Andere  ISO-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 NUL 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)

KOLOPHON

       Diese Seite  ist  Teil  der  Veröffentlichung  4.15  des  Projekts  Linux-man-pages.  Eine
       Beschreibung  des  Projekts,  Informationen,  wie  Fehler gemeldet werden können sowie die
       aktuelle Version dieser Seite finden sich unter https://www.kernel.org/doc/man-pages/.

Ü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  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 <debian-l10n-german@lists.debian.org>.