[Python-de] Deutsche Unicode-FAQ

Martin v. Loewis martin at v.loewis.de
Fri Nov 8 18:46:55 EST 2002


Gerson.Kurz at t-online.de (Gerson Kurz) writes:

> Ich freue mich auf Kritik (natürlich nicht wirklich, aber das
> sagt man halt so ;); 

Mir klingt das alles sehr klar und richtig. Trotzdem ein paar
Kommentare:

- /** The value is used for character storage. */
    private char value[];
  Hier muss man natürlich wissen, das char ein Datentyp in Java ist,
  der 65536 verschiedene Werte annehmen kann. Das ist also was anderes
  als char in C, was nur 256 Werte kennt.

- "wie in ANSI". Das Microsoft mit "ANSI" einen Zeichensatz
  bezeichnet, finde ich verwerflich. An dieser Stelle passt "ASCII"
  besser.

- "7Unicode" ???

- Generieren des BOM: Wenn Du als Encoding "utf-16" verwendest, gibt
  Python automatisch ein BOM mit aus. Allerdings gibt es keine
  Garantie, dass das dann tatsächlich LE wird - es wird die "native"
  endianness verwendet. Genauso beim Einlesen: Wenn Du "utf-16" beim
  Dekodieren verwendest, wird überprüft, ob die ersten Bytes ein BOM
  sind, dann daraus die Byteorder abgelesen, und das BOM überlesen.

> - Die unsaubere Ausdrucksweise, die man beispielsweise auf www.unicode.org
> findet ("How Unicode differs from other encodings" oder in der MSDN "Unicode
> is a worldwide character-encoding standard that uses 16-bit code values to
> represent all the characters used in modern computing", verbunden mit meiner
> Manie, solche Aussagen korinthenkackerisch zu interpretieren ;)

Das Unicode-Konsortium hat sich jahrelang gegen die Einsicht gewehrt,
dass auch 64k Zeichenposition zuwenig für diese Welt ist. UTF-8 konnte
schon immer mehr kodieren, aber Technologien, die auf "2-Byte-Unicode"
gesetzt hatten, standen vor einem Problem.

Dieses Problem ist mit UTF-16 umgangen worden: Manche Zeichen haben in
UTF-16 4 Bytes!!!. Beispielsweise gibt es das Zeichen

<U00010330> GOTHIC LETTER AHSA

mit der interessanten Beobachtung:

>>> x=u"\U00010330"
>>> x.encode("utf-16le")
'\x00\xd80\xdf' # Man muss zweimal hinschaun, um hier 4 Bytes zu zählen.

UTF-16 bietet nämlich wiederum einen Escape-Mechanismus: Der Bereich
von D800 bis DFFF ist reserviert für UTF-16. Paare (sog. surrogate
pairs) von zwei UTF-16-Codepunkten kodieren ein Zeichen. Python hat
mit surrogate pairs auch so seine Schwierigkeiten:

>>> len(x)
2

Eigentlich müsste die Länge von x 1 sein (es ist ja nur ein
Zeichen). Glücklicherweise fällt das in der Praxis nicht auf, weil die
Zeichen jenseits von U+10000 (noch) relativ selten
vorkommen. Zukünftige Pythonversionen werden vielleich 4 Bytes pro
Unicode-Zeichen verwenden (sog. UCS-4-Modus), dann kann man die
gothischen Buchstaben auch wieder "richtig" repräsentieren. Im Moment
verwendet Python i.d.R. den UCS-2-Modus, damit ist auch die Übergabe
von Unicode an Win32-Systemrufe relativ einfach (die ja auch UCS-2
erwarten).

Ciao,
Martin





More information about the Python-de mailing list