.\" -*- coding: UTF-8 -*-
.\" Copyright (C) Markus Kuhn, 1996, 2001
.\"
.\" %%%LICENSE_START(GPLv2+_DOC_FULL)
.\" This is free documentation; you can redistribute it and/or
.\" modify it under the terms of the GNU General Public License as
.\" published by the Free Software Foundation; either version 2 of
.\" the License, or (at your option) any later version.
.\"
.\" The GNU General Public License's references to "object code"
.\" and "executables" are to be interpreted as the output of any
.\" document formatting or typesetting system, including
.\" intermediate and printed output.
.\"
.\" This manual is distributed in the hope that it will be useful,
.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
.\" GNU General Public License for more details.
.\"
.\" You should have received a copy of the GNU General Public
.\" License along with this manual; if not, see
.\" .
.\" %%%LICENSE_END
.\"
.\" 1995-11-26 Markus Kuhn
.\" First version written
.\" 2001-05-11 Markus Kuhn
.\" Update
.\"
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH UTF\-8 7 "6. März 2019" GNU Linux\-Programmierhandbuch
.SH BEZEICHNUNG
UTF\-8 \- eine ASCII\-kompatible Multibyte\-Unicode\-Kodierung
.SH 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 »\e0« 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.
.PP
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.
.SS Eigenschaften
Die UTF\-8\-Kodierung hat die folgenden netten Eigenschaften:
.TP 0.2i
*
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.
.TP
*
Alle UCS\-Zeichen über 0x7f werden als Folge mehrerer Bytes im Bereich 0x80
bis 0xfd dargestellt, so dass kein \fBASCII\fP\-Byte als Teil eines anderen
Zeichens auftritt und es keine Probleme z.B. mit »\e0« oder »/« gibt.
.TP
*
Die lexikographische Sortierreihenfolge von UCS\-4\-Zeichenketten bleibt
erhalten.
.TP
*
Alle möglichen 2^31 UCS\-Zeichen können mit UTF\-8 kodiert werden.
.TP
*
Die Bytes 0xc0, 0xc1, 0xfe und 0xff werden in der UTF\-8\-Kodierung nicht
verwendet.
.TP
*
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.
.TP
*
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.
.SS Kodierung
Die folgenden Byte\-Folgen werden für die Darstellung eines Zeichens
verwendet. Die zu verwendende Folge hängt vom \fBUCS\fP\-Code des Zeichens ab:
.TP 0.4i
0x00000000 \- 0x0000007F:
0\fIxxxxxxx\fP
.TP
0x00000080 \- 0x000007FF:
110\fIxxxxx\fP 10\fIxxxxxx\fP
.TP
0x00000800 \- 0x0000FFFF:
1110\fIxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP
.TP
0x00010000 \- 0x001FFFFF:
11110\fIxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP
.TP
0x00200000 \- 0x03FFFFFF:
111110\fIxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP
.TP
0x04000000 \- 0x7FFFFFFF:
1111110\fIx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP
.PP
Die \fIxxx\fP\-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.
.PP
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.
.SS Beispiel
Das Unicode\-Zeichen 0xa9 = 1010 1001 (das Copyright\-Zeichen) wird in UTF\-8
als
.PP
.RS
11000010 10101001 = 0xc2 0xa9
.RE
.PP
dargestellt und das Zeichen 0x2260 = 0010 0010 0110 0000 (das
Ungleich\-Symbol) als:
.PP
.RS
11100010 10001001 10100000 = 0xe2 0x89 0xa0
.RE
.SS "Bemerkungen zur Anwendung"
Anwender müssen, z.B. mit
.PP
.RS
export LANG=en_GB.UTF\-8,
.RE
.PP
eine UTF\-8\-Locale wählen, um die UTF\-8\-Unterstützung in Programmen zu
aktivieren.
.PP
Anwendungs\-Software, die auf den verwendeten Zeichensatz achten muss, sollte
immer, z. B. mit
.PP
.RS
setlocale(LC_CTYPE, ""),
.RE
.PP
die Locale setzen und Programmierer anschließend den Ausdruck
.PP
.RS
strcmp(nl_langinfo(CODESET), "UTF\-8") == 0
.RE
.PP
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.
.PP
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 \fBmbsrtowcs\fP(3) und \fBwcswidth\fP(3) nutzen, um
Zeichen und Cursorpositionen zählen.
.PP
Die offizielle Escape\-Sequenz aus einem ISO\-2022\-Kodierungsschema (wie zum
Beispiel von VT100\-Terminals verwendet) nach UTF\-8 ist ESC % G
("\ex1b%G"). Die entsprechende Sequenz für die Rückkehr von UTF\-8 zu ISO
2022 ist ESC % @ ("\ex1b%@"). Andere ISO\-2022\-Sequenzen (wie zum Umschalten
der G0\- und G1\-Sätze) sind im UTF\-8\-Modus nicht anwendbar.
.SS 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.
.SS Standards
.\" .SH AUTHOR
.\" Markus Kuhn
ISO/IEC 10646\-1:2000, Unicode 3.1, RFC\ 3629, Plan 9.
.SH "SIEHE AUCH"
\fBlocale\fP(1), \fBnl_langinfo\fP(3), \fBsetlocale\fP(3), \fBcharsets\fP(7),
\fBunicode\fP(7)
.SH KOLOPHON
Diese Seite ist Teil der Veröffentlichung 5.10 des Projekts
Linux\-\fIman\-pages\fP. 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/.
.PP
.SH ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von
Sebastian Rittau
und
Martin Eberhard Schauer
erstellt.
.PP
Diese Übersetzung ist Freie Dokumentation; lesen Sie die
.UR https://www.gnu.org/licenses/gpl-3.0.html
GNU General Public License Version 3
.UE
oder neuer bezüglich der
Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
.PP
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden,
schicken Sie bitte eine E-Mail an die
.MT debian-l10n-german@lists.debian.org
Mailingliste der Übersetzer
.ME .