Provided by: manpages-de_0.10-1_all bug

BEZEICHNUNG

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

BESCHREIBUNG

       Der  Unicode-3.0-Zeichensatz  ist  durch  16-Bit-Worter  definiert. Die
       einfachste  Unicode-Kodierung  (UCS-2)  besteht  aus  einer  Folge  von
       16-Bit-Zeichen.  Solche  Zeichenketten  konnen  als  Bestandteile viele
       16-Bit-Zeichen wie '\0' oder '/' enthalten, die z. B. in Dateinamen und
       anderen Argumenten von C-Bibliotheksfunktionen eine besondere Bedeutung
       haben. AuBerdem arbeiten die meisten UNIX-Programme  mit  ASCII-Dateien
       und  konnen  16-Bit-Worter  nicht  ohne groBere Anderungen 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, wird sogar
       durch  31-Bit-Worter  definiert.  Die  zugehorige UCS-4-Kodierung (eine
       Folge von 32-Bit-Wortern) leidet  unter  denselben  Problemen  wie  die
       UCS-2-Kodierung.

       Die  UTF-8-Kodierung  von Unicode und UCS hat diese Probleme nicht. Sie
       ist der  gebrauchliche  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-Kompatibilitat hergestellt. Dateinamen
         und Zeichenketten, die nur aus  7-Bit-ASCII-Zeichen  bestehen,  haben
         darum unter ASCII und UTF-8 dieselbe Kodierung.

       * Alle UCS-Zeichen uber 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 moglichen 2^31 UCS-Zeichen konnen mit UTF-8 kodiert werden.

       * Die  Bytes  0xfe  und  0xff  werden  von  der  UTF-8-Kodierung  nicht
         verwendet.

       * Das erste Byte einer Multibyte-Folge,  die  ein  einzelnes  nicht  in
         ASCII enthaltenes UCS-Zeichen darstellt, ist grundsatzlich im Bereich
         0xc0 bis 0xfd und zeigt die Lange der Folge an.  Alle  anderen  Bytes
         der  Folge  sind im Bereich 0x80 bis 0xbf. Dadurch wird eine einfache
         Neusynchronisierung ermoglich, da die Kodierung zustandslos und daher
         robust gegenuber fehlenden oder verloren gegangenen Bytes ist.

       * UTF-8-kodierte  UCS-Zeichen  konnen  bis  zu sechs Byte lang sein. Da
         aber die  Unicode-Norm  keine  Zeichen  uber  0x10FFFF  spezifiziert,
         konnen Unicode-Zeichen in UTF-8 nur bis zu vier Byte lang sein.

   Kodierung
       Die  folgenden  Byte-Folgen  werden  fur die Darstellung eines Zeichens
       verwendet. Die zu verwendende Folge hangt 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  Binardarstellung
       ersetzt.  Es wird die jeweils kurzeste 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-Datenstromen enthalten sein.

   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 mussen, z.B. mit

              export LANG=en_GB.UTF-8,

       eine UTF-8-Locale wahlen, um die UTF-8-Unterstutzung 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 anschlieBend den Ausdruck

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

       auswerten, um festzustellen, ob eine UTF-8-Locale ausgewahlt wurde  und
       ob    daher    samtliche   Standard-Klartexteingaben   und   -ausgaben,
       Terminalkommunikation,    Klartext-Dateiinhalte,     Dateinamen     und
       Umgebungsvariablen in UTF-8 kodiert sind.

       An  Einzel-Byte-Kodierungen gewohnte Programmierer mussen daran denken,
       dass zwei bislang  getroffene  Annahmen  in  UTF-8-Locales  nicht  mehr
       gultig  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
       unterstutzen,   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 zahlen.

       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 fur die Ruckkehr von UTF-8 zu ISO
       2022  ist  ESC  %  @  ("\x1b%@").  Andere  ISO-2022-Sequenzen  (wie zum
       Umschalten der G0- und G1-Satze) sind im UTF-8-Modus nicht anwendbar.

       Es ist zu hoffen, dass in absehbarer Zeit UTF-8 ASCII und ISO 8859  auf
       allen   Ebenen   als  gemeinsame  Zeichenkodierung  auf  POSIX-Systemen
       ersetzt, was diese zu einer wesentlich  machtigeren  Umgebung  fur  den
       Umgang mit Klartext macht.

   Sicherheit
       Die  Standards  Unicode  und  UCS  fordern, dass Erzeuger von UTF-8 die
       kurzeste  mogliche  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
       kurzesten   sind,   nicht   akzeptieren   durfen.  Dies  geschieht  aus
       Sicherheitsgrunden:     Wenn     Benutzereingaben     auf      mogliche
       Sicherheitsverletzungen  uberpruft werden, konnte ein Programm nur nach
       den ASCII-Versionen von "/../" oder ";" oder NUL suchen und  ubersehen,
       dass  es  viele  Moglichkeiten  einer Nicht-ASCII-Darstellung neben der
       kurzesten UFT-8-Kodierung dieser Zeichen gibt.

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

SIEHE AUCH

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

KOLOPHON

       Diese  Seite  ist  Teil  der   Veroffentlichung   3.32   des   Projekts
       Linux-man-pages.  Eine Beschreibung des Projekts und Informationen, wie
       Fehler    gemeldet     werden     konnen,     finden     sich     unter
       http://www.kernel.org/doc/man-pages/.

"UBERSETZUNG

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

       Diese  Ubersetzung  ist  Freie Dokumentation; lesen Sie die GNU General
       Public  License  Version  3  oder  neuer   bezuglich   der   Copyright-
       Bedingungen. Es wird KEINE HAFTUNG ubernommen.

       Wenn  Sie  Fehler  in  der  Ubersetzung  dieser  Handbuchseite  finden,
       schicken     Sie     bitte     eine     E-Mail     an     <debian-l10n-
       german@lists.debian.org>.