unicode Datein

[Andev]

Natürlich unterstützt die Windows-Konsole Unicode, auch ohne jede CP-Umstellung.

Ach wirklich? UTF-8 funktioniert bei mir weder bei Windows 7 noch bei Windows XP in der »cmd.exe«. Ohne irgendeine »CP-Umstellung«.

Nicht?
Seit NT 3.0 ist Unicode (als UCS/UTF-16) in Windows implementiert. Deine Konsole sollte problemlos Unicodezeichen anzeigen, manipulieren und ausgeben können, solange die gewählt Schriftart die Zeichen unterstützt - bei Windows 7 mit "Lucida Console" der Fall. Manuell umstellen für Anwendungen wie Python auf UTF-8 kannst Du mit "chcp 65001". Das habe ich oben nur nicht als Lösung vorgeschlagen, da CPython damit Schwierigkeiten hat und in der Regel abstürzt (liegt m.E. an der gewählten CRT-Umsetzung). Daher auch die manuelle Umstellung innerhalb Pythons in meinem Beispiel oben auf UTF-16. Damit funktioniert das alles problemlos, zumindest unter Powershell (cmd ist unter Umständen noch weiter anzupassen, habe ich nicht weiter getestet).

Warum Du als Entwickler "cmd.exe" nutzt statt Powershell/Powershell ISE, insbesondere nach Deinen Kommentaren oben über den "Terminalemulator", ist mir ein Rätsel. Wenn Dir das immer noch nicht reicht, kannst Du mit Interix auch direkt eine Korn- oder Bash-Shell nutzen.

[nomnom]

Natürlich unterstützt die Windows-Konsole Unicode, auch ohne jede CP-Umstellung.

Ach wirklich? UTF-8 funktioniert bei mir weder bei Windows 7 noch bei Windows XP in der »cmd.exe«. Ohne irgendeine »CP-Umstellung«.

Nicht?
Seit NT 3.0 ist Unicode (als UCS/UTF-16) in Windows implementiert. Deine Konsole sollte problemlos Unicodezeichen anzeigen, manipulieren und ausgeben können, solange die gewählt Schriftart die Zeichen unterstützt - bei Windows 7 mit "Lucida Console" der Fall. Manuell umstellen für Anwendungen wie Python auf UTF-8 kannst Du mit "chcp 65001". Das habe ich oben nur nicht als Lösung vorgeschlagen, da CPython damit Schwierigkeiten hat und in der Regel abstürzt (liegt m.E. an der gewählten CRT-Umsetzung). Daher auch die manuelle Umstellung innerhalb Pythons in meinem Beispiel oben auf UTF-16. Damit funktioniert das alles problemlos, zumindest unter Powershell (cmd ist unter Umständen noch weiter anzupassen, habe ich nicht weiter getestet).

Warum Du als Entwickler "cmd.exe" nutzt statt Powershell/Powershell ISE, insbesondere nach Deinen Kommentaren oben über den "Terminalemulator", ist mir ein Rätsel. Wenn Dir das immer noch nicht reicht, kannst Du mit Interix auch direkt eine Korn- oder Bash-Shell nutzen.

Inzwischen benutze ich „xfce4-terminal“ mit der „Bourne-again shell“. Allerdings stürzen meine Python-Programme, die Sonderzeichen ausgeben ab, wenn man versucht, sie unter Windows auszuführen. Ich habe bei der „cmd“ nicht kapiert, wo ich da Einstellungen treffen kann, deswegen blieb es auch bei der „Standard“-Schrift (die anscheinend kein Unicode unterstützt). Na ja. Ich ziehe mich mal aus der Diskussion zurück … Habe inzwischen ja auch nicht mehr die Möglichkeit mich damit zu beschäftigen. Möchte ich auch nicht …

[jerch]

Natürlich unterstützt die Windows-Konsole Unicode, auch ohne jede CP-Umstellung.
Ach wirklich? UTF-8 funktioniert bei mir weder bei Windows 7 noch bei Windows XP in der »cmd.exe«. Ohne irgendeine »CP-Umstellung«.

@nomnom & Andev:
Das ist kein Widerspruch, da UTF-8 != UTF-16 != UTF-32. Die bilden zwar alle mehr oder weniger den Unicode-Zeichenraum ab, die Zeichen sind aber was UTF-8 angeht, sehr anders repräsentiert. Zusätzlich deckt UTF-32 einen größeren Zeichenraum ab, bzw. arbeitet UTF-16 mit Multi-Multibytetricks, um da aufzuschliessen. Windows nutzt seit langem UTF-16, mit UTF-8 hat Microsoft seine liebe Not, UTF-32 wird nicht unterstützt von OS-Seite. Für Python z.B. bedeutet dies, das Unicode-Strings auf Linux heutzutage meist in UTF-32 vorliegen, während auf Windows UTF-16 genutzt wird.

Während Unicode den theoretischen Zeichenraum spezifiziert, sind die UTFs die technische Realisierung davon.

[lunar]

@jerch: Dafür hat Linux seine liebe Not mit UTF-16

[Andev]

Die Unterschiede zwischen Unicode und UTF wurden bereits angesprochen, aber gut, dass das noch einmal deutlich gemacht wird.

Linux setzt auf UTF-8 und auch das erst seit wenigen Jahren, ich habe hier immer noch ein paar Altmaschinen rumsitzen ("Altmaschinen"! Aus 2001 bis 2003!), mit denen der Datenaustausch durch dieses unsägliche ASCII immer noch regelmäßig Kopfschmerzen verursacht. Dass die 4-Byte-Vorgabe in wchar_t eine UTF-32-Unterstützung eingeführt hat ist zwar richtig, aber keine eigentliche *NIX-Sache und unterscheidet sich nicht wesentlich von der Windowsunterstützung.
Unter Windows ist das wirkliche Problem die variable Bitlänge von UTF-16 (ursprünglich UCS-2 mit fester Länge), unzählige - auch gute - Programmierer haben damit ihre Schwierigkeiten und auch Python gehört zu den Programmen, in denen hier ein wenig unsauber gearbeitet wurde. Mit Python 3.3 wurde das ganze verschlimmbessert aber leider noch nicht gelöst. Hat wahrscheinlich auch keine hohe Priorität. Von den ganzen BOM-Ideologien möchte ich gar nicht erst anfangen.

Probleme mit UTF-8 unter Windows sollten aber schon lange der Vergangenheit angehören, reguläre Anwendungen hatten die ohnehin nie, und für Anwendungen mit Konsolenausgabe wurde vor ~8 Jahren die Konsole durch Powershell abgelöst wurde und die ISE-Variante für Entwickler soll explizit die Kompatibilitätsprobleme lösen.

Wäre natürlich trotzdem schön, wenn sich die Entwickler der verschiedenen Systeme endlich einmal zusammensetzen könnten um eine sinnvolle Lösung zur Interoperabilität zu finden, ähnlich den Browserherstellern bei HTML5. Diese ideologischen Grabenkämpfe sind eine furchtbare Sache ("UTF-16 is evil", "UTF-32 is stupid", "ASCII is enough for everybody", "Your shell cannot do what mine does").