Python 3 ist dafür bekannt, Unicode besonders einfach zu unterstützen. Wenn es trotzdem zu einer UnicodeDecodeException kommt, muss das gar nicht mal am Quelltext liegen.
Heute habe ich die ganze Zeit versucht, ein Programm mit Unicode-Eingabe zu starten. Jedes mal las ich:
File "/usr/lib/python3.0/io.py", line 1494, in write
b = encoder.encode(s)
File "/usr/lib/python3.0/encodings/ascii.py", line 22, in encode
return codecs.ascii_encode(input, self.errors)[0]
<strong>UnicodeEncodeError:</strong> 'ascii' codec can't encode character '\xf6' in position 40: ordinal not in range(128)
b = encoder.encode(s)
File "/usr/lib/python3.0/encodings/ascii.py", line 22, in encode
return codecs.ascii_encode(input, self.errors)[0]
<strong>UnicodeEncodeError:</strong> 'ascii' codec can't encode character '\xf6' in position 40: ordinal not in range(128)
Nun, offensichtlich wollte mein Programm also ASCII ausgeben. Warum zur Hölle will es denn den ASCII-Coder nutzen? Ich benutze doch UTF.8-kodierte Strings! Kein Wunder, dass das nicht klappt…
Lösung: Das Programm wurde mit
LANG=C
gestartet. Damit wurde eine ANSI-Console aktiviert.
LANG="en_US.utf8"
tut es auch und verhindert solche blöden Fehler. MAN!
2 Kommentare
David
23. Juli 2009 von 23:33 (UTC 1) Link zu diesem Kommentar
Die Umgebungsvariable LANG setzt die Sprache des gesamten Systemes. Falls du einzelne Programme in einer C oder Posix Umgebung starten willst empfehle ich ein Programm wie folgt zu starten.
oder
Könnte Interessant sein wenn du darauf angewiesen bist ein Programm unter einer speziellen Umgebung starten zu wollen.
Ben
24. Juli 2009 von 14:28 (UTC 1) Link zu diesem Kommentar
Aber genau das war mein Problem:
“LANG=C date” schaltet auf eine ANSI-Console, wo nur ASCII-Zeichen zu Verfügung stehen. Die Ausgabe von nicht-ASCII-Zeichen brachte dann diese Exception.
“LANG=*.UTF-8 date” schaltet hingegen nicht auf eine ANSII-Console um. Daher war das die Lösung.
Damit wollte ich also den Irrglauben auslöschen, dass C einfach nur die Sprache umschaltet, was viele denken.