1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205
|
.\" Hey Emacs! This file is -*- nroff -*- source.
.\"
.\" Copyright (C) Markus Kuhn, 1996
.\"
.\" 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, write to the Free
.\" Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111,
.\" USA.
.\"
.\" 1995-11-26 Markus Kuhn <mskuhn@cip.informatik.uni-erlangen.de>
.\" First version written
.\"
.\" 2000-02-14 Sebastian Rittau <srittau@jroger.in-berlin.de>
.\" Translated into German
.\"
.TH UTF-8 7 "14. Februar 2001" "Linux" "Verschiedenes"
.SH NAME
UTF-8 \- eine ASCII-kompatible Unicode-Kodierung
.SH BESCHREIBUNG
Der
.BR Unicode -Zeichensatz
ist durch 16-Bit-Wörter definiert. Die einfachste
Unicode-Kodierung
.RB ( UCS-2 )
besteht aus einer Folge von 16-Bit-Zeichen. Solche Zeichenketten
können 8-Bit-Bestandteile wie '\\0' or '/' enthalten, die eine
besondere Bedeutung z.B. in Dateinamen oder Bibliotheksfunktionen
besitzen. Außerdem arbeiten die meisten UNIX-Programme mit
.BR ASCII -Dateien
und können 16-Bit-Wörter nicht ohne größere Änderungen verarbeiten.
Darum ist
.B UCS-2
keine geeignete externe Kodierung von
.B Unicode
in Dateinamen, Text-Dateien, Environment-Variablen, etc. Das
.BR "ISO 10646 Universal Character Set (UCS)" ,
eine Erweiterung von
.BR Unicode ,
wird sogar durch 31-Bit-Wörter definiert. Die einfache
.BR UCS-4 -Kodierung
(eine Folge von 32-Bit-Wörtern) leidet unter denselben Probleme wie die
.BR UCS-2 -Kodierung.
Die
.BR UTF-8 -Kodierung
von
.B Unicode
und
.B UCS
hat diese Probleme nicht und sollte deshalb für den
.BR Unicode -Zeichensatz
unter unixoiden Betriebssystemen verwendet werden.
.SH EIGENSCHAFTEN
Die
.BR UTF-8 -Kodierung
besitzt die folgenden Eigenschaften:
.TP 0.2i
*
Die
.BR UCS -Zeichen
0x00000000 bis 0x0000007f (die klassischen in
.B US-ASCII
enthaltenen Zeichen) werden einfach als die Bytes 0x00 bis 0x7f kodiert.
(Die stellt die
.BR ASCII -Kompatibilität
sicher.) Das bedeutet, dass Dateien
und Zeichenketten, die nur aus 7-Bit-Zeichen bestehen, unter
.B ASCII
und
.B UTF-8
dieselbe Kodierung haben.
.TP
*
Alle
.BR UCS -Zeichen
über 0x7f werden als Folge mehrerer Bytes im Bereich 0x80 bis 0xfd
dargestellt, so dass kein
.BR ASCII -Byte
als Teil eines anderen Zeichens
auftritt und es keine Probleme z.B. mit '\\0' oder '/' gibt.
.TP
*
Die lexikographische Sortierreihenfolge von
.BR UCS-4 -Zeichenketten
wird nicht beeinträchtigt.
.TP
*
Alle 2^31
.BR UCS -Zeichen
können mit
.B UTF-8
kodiert werden.
.TP
*
Die Bytes 0xfe und 0xff werden nicht von der
.BR UTF-8 -Kodierung
benutzt.
.TP
*
Das erste Byte einer Folge mehrerer Bytes, die einen einzelnen
.RB nicht- ASCII -Zeichen
darstellen, ist grundsätzlich im Bereich
0xc0 bis 0xfd und zeigt an, wie lang die Folge ist. Alle anderen
Bytes der Folge sind im Bereich 0x80 bis 0xbf. Dadurch wird eine
einfache Resynchronisation ermöglichst, da die Kodierung
status-unabhängig und daher rebust gegenüber fehlenden oder verloren
gegangenen Bytes ist.
.TP
*
.B UTF-8
kodierte
.BR UCS -Zeichen
können bis zu sechs Bytes lang sein. Allerdings werden
.BR Unicode -Zeichen
maximal drei Bytes lang. Da Linux nur den 16-Bit
.BR Unicode -Zeichensatz
benutzt (und nicht den 31-Bit
.BR UCS -Zeichensatz),
können
.BR UTF-8 -Folgen
unter Linux ein, zwei oder drei Bytes lang sein.
.SH KODIERUNG
Die folgenden Byte-Folgen werden benutzt, um ein Zeichen darzustellen.
Die zu benutzende Folge hängt vom
.BR UCS -Code
des Zeichens ab:
.TP 0.4i
0x00000000 - 0x0000007F:
.RI 0 xxxxxxx
.TP
0x00000080 - 0x000007FF:
.RI 110 xxxxx
.RI 10 xxxxxx
.TP
0x00000800 - 0x0000FFFF:
.RI 1110 xxxx
.RI 10 xxxxxx
.RI 10 xxxxxx
.TP
0x00010000 - 0x001FFFFF:
.RI 11110 xxx
.RI 10 xxxxxx
.RI 10 xxxxxx
.RI 10 xxxxxx
.TP
0x00200000 - 0x03FFFFFF:
.RI 111110 xx
.RI 10 xxxxxx
.RI 10 xxxxxx
.RI 10 xxxxxx
.RI 10 xxxxxx
.TP
0x04000000 - 0x7FFFFFFF:
.RI 1111110 x
.RI 10 xxxxxx
.RI 10 xxxxxx
.RI 10 xxxxxx
.RI 10 xxxxxx
.RI 10 xxxxxx
.PP
Die
.IR xxx -Bits
müssen durch den Code des Zeichens in Binärdarstellung ersetzt
werden. Es wird die jeweils kürzeste Folge benutzt, die den Code
des Zeichen darstellen kann.
.SH BEISPIELE
Das
.BR Unicode -Zeichen
0xa9 = 1010 1001 (das Copyright-Zeichen) wird in
.B 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
.SH "KONFORM ZU"
ISO 10646, Unicode 1.1, XPG4, Plan 9.
.SH AUTOR
Markus Kuhn <mskuhn@cip.informatik.uni-erlangen.de>
.br
Deutsche Übersetzung: Sebastian Rittau <srittau@jroger.in-berlin.de>
.SH "SIEHE AUCH"
.BR unicode (7)
|