UTF-8-Konsole Windows

[Sirius3]

@Hellstrom: Programm A übergibt Text an Programm B. In welchem Encoding der Text übergeben wird, sollten die beiden Programme vorher ausmachen. Mit Deinem Ansatz hast Du Glück, wenn die Konsole UTF-8-codierten Text entgegen nimmt. Das ist aber bei weitem nicht überall der Fall, gerade unter Linux. Wann es bei Dir klappt, ist also Zufall.
Erst Bytes+Encoding ergibt sinnvollen Text. Programmiersprachen, die das von Haus aus unterstützen (Python, Java), haben einen speziellen Datentyp für Text und einen für Bytes, weil es eben nicht dasselbe. Wie Text intern realisiert wird, kann für Dich egal sein, dass es aber einen Unterschied zwischen Text und Bytes gibt, ganz und gar nicht.
Außerhalb von Programmen gibt es nur Bytes. Wenn also Text aus einem Programm raus soll, z.B. auf die Konsole, dann nur als Bytes+Encoding, wobei das Encoding eben getrennt von den Bytes ausgehandelt werden muß.

[Hellstorm]

Deswegen ist es ja wunderschön, wenn alle Programme UTF-8 können. Man muss sich dann eben nicht um irgendwas kümmern. Im übrigen hat mittlerweile jede halbwegs verbreitete Linux-Distribution UTF-8 als Standard (glücklicherweise). Linux ist da zwar immer sehr langsam (Debian hat UTF-8 erst 2006 oder 2007 als Standard benutzt; Windows schon mit NT 4.0 im Jahr 1996), aber im Allgemeinen ist das mittlerweile überall der Standard (oder zeigt mir bitte ein Gegenbeispiel). Und das auch zum Glück: Die ganzen anderen Kodierungen sind einfach nur ein Krampf, weil man dann wieder irgendeine Sprache nicht benutzen kann (Wer sich über ein paar fehlgeschlagene Umlaute ärgert, soll sich mal vorstellen, wie es ist, wenn man eine gesamte Sprache nicht schreiben kann).

Deswegen ist es auch kein Zufall. Das ist mittlerweile normal. Ich habe noch keine Linux-Distri der letzten Jahre erlebt, wo das nicht geklappt hätte (bitte immer Gegenbeispiele). Natürlich mag es sein, dass ich bei Debian 1.1 oder Suse 1.0 das nicht mehr benutzen kann, aber dann denk ich mir: Bitte mach ein Upgrade, wir sind im Jahr 2013. Ansonsten hast du halt Pech, dass die Software nicht geht.

Bei Windows ist jetzt natürlich nur das Problem, dass die Konsole dort ein absolutes Schattendasein führt und praktisch gar keine Aktualisierung erfährt. Deswegen läuft die dort noch nicht standardmäßig als UTF-8. Aber was genau soll ich dagegen jetzt machen? Ich will, dass die Zeichen unterstützt werden, deswegen brauche ich UTF-8 und stelle das für mich ein. Eine Alternative gibt es da einfach nicht. Die Zeichen nicht zu benutzen und mich nur auf ASCII zu beschränken ist keine Option, sorry.

Erst Bytes+Encoding ergibt sinnvollen Text. Programmiersprachen, die das von Haus aus unterstützen (Python, Java), haben einen speziellen Datentyp für Text und einen für Bytes, weil es eben nicht dasselbe.

Was ist denn dann der Unterschied? Wenn ich einen Datentext für Text habe, ist es doch nur so, dass man das ganze leichter schreiben und behandeln kann (Ich will ja eben nicht immer jedes Mal „E6 97 A5 E6 9C AC E8 AA 9E 0A“ anstatt „日本語“ schreiben). „Text“ kann doch gar nicht gespeichert werden. Text ist doch einfach nur ein willkürliche Belegung von Bytes auf grafische Symbole (=Buchstaben), der Schlüssel dazu heißt „Zeichenkodierung“.

Natürlich ergibt erst Bytes (was sollte es denn sonst sein, was anderes als Bits/Bytes gibt es doch am PC nicht?) + Zeichenkodierung (+ eine Schriftart und die Darstellungsalgorithmen, damit man auch was sehen kann) sinnvollen Text. Das ist doch klar und ist auch kein Unterschied, ob ich jetzt ASCII, Shift-JIS oder UTF-8 nutze. Selbst C wandelt doch automatisch den Text von einem char in Bytes um (bzw. was heißt umwandeln, es wird so intern gespeichert). Ein Text ist doch daher im Grunde auch nur eine Sammlung von Integern. Ein C-Array ist doch beispielsweise auch einfach nur eine Aneinanderhängung von Integern, die man mit einer Zeichenkodierung dann wieder lesbar macht.

Text ist doch einfach nur eine Reihe von Bytes, die mit einer Zeichenkodierung von bzw. zu Bytes umgewandelt werden. Dafür ist die Zeichenkodierung doch da. In den meisten Fällen kann man von ASCII ausgehen, aber wenn man etwas umfangreicheres haben möchte, braucht man eben eine andere Kodierung. Aber da ist doch egal, was ich jetzt benutze, nur die Position und der Umfang der Tabelle unterscheidet sich (Natürlich gibt es manchmal noch etwas kompliziertere Sachen wie Multi-byte-Encodings oder Escape-Sequenzen, aber das können die Programme ja verstehen, wenn sie die entsprechende Kodierung können).


Ich sehe das ganze Problem hier irgendwie nicht. Ich will eigentlich nur wissen, wie man Python mit Unicode (ob das jetzt UTF-7, UTF-8, UTF-16 oder UTF-32 ist, ist egal) vernünftig auf einer Windows-Konsole nutzen kann. Unter Linux (lies: jede halbwegs gebräuchliche aktuelle Distribution) klappt es ohne Probleme, unter Windows allerdings nicht von Haus aus, da die Zeichenkodierung auf CP850 (o.ä.) steht. Dass man da jetzt meinetwegen die Kodierung aushandeln muss, ist klar, aber kein Hindernis. Genau das will ich ja wissen.

[BlackJack]

@Hellstorm: Mit der Umleitung in eine Datei hast Du einen schönen Fehler gezeigt den die Entwickler bei Python 3 IMHO gemacht haben. Alles „funktioniert” einfach. Pustekuchen, es funktioniert nur solange man sich auf dem selben System mit den selben Einstellungen bewegt. Das hast Du selbst doch schon festgestellt, dass es auf Windows nicht mehr funktioniert. Das selbe Programm kann dann plötzlich nicht mehr die selben Zeichen ausgeben oder in eine Datei umleiten oder Daten die es auf in eine Datei geschrieben hat, nicht mehr aus der selbst geschriebenen Datei lesen. Das automatische Kodieren mit ”der” “Systemkodierung“ lässt Leute denken sie müssten sich jetzt nicht mehr selber mit Text, Bytes, und Kodierungen beschäftigen, was Du ja nach eigener Aussage auch gar nicht tun willst. Das ist aber schlicht falsch, denn wenn man ein tatsächlich *funktionierendes* Programm schreiben will, dann muss man genau das selbe wie bei Python 2 machen — selber explipizit an den Übergängen zur Aussenwelt kodieren und dekodieren und die Kodierung zumindest optional konfigurierbar machen für die Fälle wo es keinen Weg gibt eine Kodierung zu ermitteln oder zu raten. In dem Punkt hat sich eigentlich *überhaupt nichts* geändert, ausser dass Anfänger und solche die sich nicht mit den schmutzigen Details beschäftigen wollen erst einmal eingelullt werden und dann behaupten das mit Unicode sei in Python 3 viel einfacher geworden. Ist es nicht. IMHO ist es schlechter geworden weil Python einem nicht früher mit einer entsprechenden Ausnahme auf die Finger haut wenn man sich nicht ordentlich um Unicode kümmert.

[jens]

Interessanter Thread. Aber warum wird eigentlich nicht estmal auf http://wiki.python-forum.de/Von%20Umlau ... 0Encodings verwiesen?

Die Eingabeaufforderung ist keine Box um DOS Programme laufen zu lassen. Das geht schon längere Zeit nicht mehr. Dazu gibt es z.B. http://www.dosbox.com/ die ein echtes DOS emuliert.

Von https://de.wikipedia.org/wiki/Cmd.exe :

Es handelt sich bei cmd.exe um eine native Win32-Anwendung, daher ist der Name „DOS-Eingabeaufforderung“ irreführend: es wird zwar eine Kommandozeile für MS-DOS-Befehle zur Verfügung gestellt, die selbst allerdings nicht unter MS-DOS als Betriebssystem läuft

Ich denke aus Standard CodePage wird Latin-1 verwendet. Mit "chcp 65001" sollte man auf UTF-8 umschalten können...

[Sirius3]

Ich denke aus Standard CodePage wird Latin-1 verwendet. Mit "chcp 65001" sollte man auf UTF-8 umschalten können...

Schön, das bringt mein cmd-Fenster zum abstürzen. Scheint wohl ein untested feature zu sein.

@Hellstrom: Windows nutzt seit NT4.0 eine 16bit-Kodierung von Zeichen die weitestgehend mit Unicode übereinstimmt. Eine UTF-8-Unterstützung gibt es von Systemseite aus nicht. Das hat zur Folge, dass die meisten Systemprogramme damit nicht umgehen können.

[Hellstorm]

@Blackjack:

Finde ich nicht. Meiner Meinung nach liegt hier der „Fehler“ ganz klar in der Windows-Konsole, die eben nicht vernünftig weiterentwickelt wird (bzw. im Gegensatz zum restlichen System kein Unicode verwendet; wobei Windows ja normalerweise wohl UTF-16 verwendet, aber das ist ja auch kein Problem).

Mittlerweile speichern doch die meisten (gut geschriebenen) Programme standardmäßig ihre Dateien als UTF-8. Würdest du da auch sagen, dass sie das nicht machen sollten und sich der Benutzer darum kümmern muss? Letztendlich ist es doch sinnvoll, wenn irgendwann mal alles aus Unicode besteht, da es einfach die gesamte Zeichenkodierungssache unglaublich vereinfacht. Nur bei ganz ganz wenigen Sachen ist eine alte, einfache Kodierung vielleicht noch sinnvoll (Mir käme da z.B. gerade ein Text-LCD, was man mit dem PC verbindet, in den Sinn: Das hat ja eh nur einen beschränkten Zeichenvorrat und dort ist vielleicht intern die Dekodierung von UTF-8 zu aufwändig (wobei man dann allerdings auch einfach UTF-16 verwenden könnte, aber nun gut)). Aber bei normalen Computeranwendungen sehe ich absolut gar keinen Vorteil von Nicht-Unicode-Kodierungen gegenüber Unicode: Irgendwann kommt immer der Punkt, wo ein Benutzer dann doch mal irgendein „exotisches“ Zeichen eingeben möchte, und seien es nur die Anführungszeichen „“ oder ein Name mit einem ć drin. Wie ich bei sehr vielen Programmen erlebt habe, hat dann letztendlich der Programmierer wieder genau diesen einen Fall doch nicht bedacht und es gibt Probleme. Wenn alles auf Unicode läuft, klappt es einfach ohne Probleme.

Natürlich müssen alle anderen Programme auch unter Unicode laufen, aber genau das sollte letztendlich das Ziel sein (Ich sage nicht, dass Unicode der Weisheit letzter Schluss ist, aber es gibt halt im Moment nichts ernstzunehmendes Alternatives).

Daher ist nicht Python 3 das Problem, sondern die Windows-Konsole. Wie man eben sieht, läuft es unter Linux ohne Probleme (unter MacOS weiß ich nicht, aber ich denke dort auch). Bei Python 3 hat man den Vorteil, dass es eben automatisch in Unicode läuft, bei Python 2 gibt es bestimmt einige Leute, die das Thema dann ignorieren, weil es sie selber nicht betrifft (Davon gibt es unglaublich viele Programme im Internet). Wobei ich mich zugebenermaßen noch nicht wirklich mit den ganzen Sachen beschäftigt habe, ich bin im Moment erst noch dabei, halbwegs lauffähige Programme zu entwickeln

@jens:
Ja, mit chcp 65001 klappt es. Allerdings kommen dann am Ende der Ausgabe immer zusätzlich irgendwelche merkwürdigen Zeichen. Da muss ich noch mal etwas schauen. Scheint aber schon mal der richtige Weg zu sein (hoffe ich).

@Sirius:
Das ist UTF-16. Das stimmt nicht weitesgehend mit Unicode überein, sondern ist einfach Unicode, mit dem Unterschied, dass einfach alle Zeichen in zwei Bytes kodiert werden (Ergibt dann ca. 65000 Zeichen. Aber selbst das reicht nicht mehr aus, deswegen kann man dort mit speziellen Zeichen noch mehr Zeichen speichern). UTF-8 ist variabel in der Länge, man muss dann allerdings oft etwas komplizierter schauen, was genau ein Zeichen ist.
Unicode ist die Tabelle, wo alle Zeichen drin stehen. Davon gibt es dann mehrere Kodierungen, die diese Tabelle auf Bytes abbilden: UTF-7 (7 Bit), UTF-8 (8 Bit), UTF-16 (16 Bit), UTF-32 (32 Bit). Das ist aber alles Unicode.
UTF-8 hat sich bei der normalen Datenspeicherung durchgesetzt, weil es ASCII-kompatibel ist (ASCII ist einfach ein Subset von UTF-8). Bei UTF-16 ist das nicht der Fall, deswegen nutzt man das normalerweise nicht zur Speicherung, sondern wird intern von Windows verwendet. Außerdem braucht man bei UTF-16 die Angabe von Big oder Little Endian, bei UTF8 ist das nicht der Fall.

[jens]

Wie man eben sieht, läuft es unter Linux ohne Probleme (unter MacOS weiß ich nicht, aber ich denke dort auch).

Ich vermute allerdings, nur in aktuellen Linux Distributionen, denn die haben IMHO alle auf UTF-8 umgestellt. Auf älteren Systemen ist es dann aber wieder ein Problem...

[BlackJack]

@Hellstorm: Windows (NT oder nicht) hat zu irgendeiner Zeit mal UTF-8 benutzt? Die UTF-Kodierungen und Unicode-Implementierungen haben auch ihre Macken. Man kann zum Beispiel Probleme damit bekommen wenn die selbe Zeichenkette einmal „composed” und einmal „decomposed” vorliegt, und die Implementierung nicht normalisiert und somit der Vergleich von gleichen Texten fehlschlägt. MacOS speichert im Dateinamen zum Beispiel „decomposed” und CPython normalisiert Unicode weder bei der Dekodierung noch bei Operationen wie Vergleichen.

Du demonstrierst in Deinem letzten Beitrag auch schön die Insellösung. Ja klar funktioniert das mit Linux das auf UTF-8 eingestellt ist. Schön das *Deine* Welt nur daraus zu bestehen scheint. Andere müssen mit mehr Systemen arbeiten und auch Daten zwischen denen austauschen. Man kann auch bei vielen Systemen nicht einfach mal eben ein Upgrade machen, wenn das produktiv etwas drauf läuft. Und das nur wegen der Kodierung in der Konsole. Da kann man auch nicht sagen „Pech gehabt”. Was ist denn das für ein Unsinn? Selbst auf einem „UTF-8-Linux” gibt es Software wo man sich um die Kodierung kümmern muss, also sie zumindest explizit einstellen muss weil UTF-8 eben doch nicht überall die Voreinstellung ist. Datenbanken zum Beispiel sind so ein Thema wo man oft noch Einstellungen vornehmen muss. Und bei Windows ist dann halt Ende weil das sogar im gleichen System in der Konsole etwas anderes benutzt als bei der „Systemkodierung” und beides ist in aller Regel kein UTF-8 sondern jeweils eine Kodierung die nicht alle Unicode-Zeichen abdeckt.

Das die Konsole unter Windows in CP850 läuft hat nichts mit Schattendasein zu tun, sondern mit Rückwärtskompatibilität. Es gibt halt noch genug Software die keine Ahnung von Unicode hat und die einfach davon ausgeht, dass unter einem Windows in der Konsole Bytes ausgegeben werden können, die CP850 kodierten Zeichen entsprechen.

Ausserdem gibt es Unmengen von vorhandenen Daten aus den letzten Jahrzehnten in den verschiedensten Kodierungen. Man wird sich also auch in Zukunft mit dem Thema Kodierung als Programmierer auseinandersetzen müssen, wenn man sich nicht auf seine kleine Insel von Linux nach 2006 beschränken kann.

Das Aushandeln der Kodierung ist halt genau das Problem: Es gibt keinen allgemeinen Weg dafür der das zurverlässig kann, und in vielen Fällen geht es schlicht gar nicht. Das schreibe ich jetzt nicht das erste mal hier. Überliest Du das jedes mal? Und dort wo ausgehandelt wird, und dann halt CP850 raus kommt, gefällt es Dir anscheinend nicht.

Wenn Du überall UTF-8 haben willst, dann mach das halt. Explizit! Mache ich in der Regel genau so. Vieles was ich schreibe schreibt und erwartet UTF-8, worum ich mich bei Python 2 halt explizit kümmern muss, zum Beispiel durch entsprechende Wrapper aus `io` um `sys.std*`. Und wenn es etwas flexibler sein muss bekommt das Programm eine Option die der Benutzer auf eine andere Kodierung setzen kann. So viel muss man als Programmierer aber halt schon tun.

Windows verwendet alle möglichen Kodierungen. Und genau so machen das Windows-Anwendungen. CP1251 und CP850 in unseren Breitengraden und UTF-16. Andere Kodierungen in anderen Ländern und Regionen. Das was Du also der Windowskonsole vorwirfst, kannst Du jeder Windowssoftware vorwerfen. Das mag aus Deiner Sicht dann vielleicht keine „gute” Software sein, aber dass ist das mit dem man da draussen konfrontiert wird.

Und es bleibt ein IMHO ein Fehler in Python 3, denn selbst wenn Windows einheitlich UTF-16 verwenden würde, sind Programme bei denn scheinbar alles automagisch richtig gemacht wird, nicht portabel weil unter Linux UTF-8 und unter Windows UTF-16 verwendet würde und damit die Daten die das Programm geschrieben hat, nicht mehr von ihm selber gelesen werden können, ohne dass man sich explizit um die Kodierung kümmert. Das muss man als Programmierer machen. Jemand der sich darum drücken will ist IMHO kein guter Programmierer weil er versucht ein allgegenwärtiges Problem durch fest Augen zukneifen zu lösen versucht und Daten und Tatsachen ignoriert.

Na klar wäre Unicode überall eine nette Sache, das Problem ist aber das es nicht überall eingesetzt wird. Nicht einmal ansatzweise! Und da ich heute noch mit zu DOS-Zeiten kodierten Daten und Programmen aus dieser Zeit konfrontiert bin, sehe ich auch nicht, dass sich das in absehbarer Zeit auf magische Weise ändern wird. Unter Linux, und wenn man sich nur darauf beschränkt sieht es ja ganz gut aus, aber ich habe halt regelmässig mit dem parsen von Logdateien und ab und zu dem Konvertieren von Daten zwischen Windowsprogrammen zu tun und da ist es egal ob es alte oder neue Software ist, und auch ob es Individualsoftware oder ein Standardprodukt ist, man muss immer erst schauen wie die Daten kodiert sind. Es deutet für mich nichts darauf hin, dass man in absehbarer Zeit eine bestimmte Kodierung annehmen kann und nur in Ausnahmefällen noch etwas anderes verwendet wird. Noch schlimmer, man sieht auch fast regelmässig so etwas wie ”XML”-Dateien die keine Kodierung angegeben haben und CP1251 kodiert sind. Weil es zu viele Programmierer gibt, die sich mit dem Thema nicht befassen wollen oder können.

Das sich UTF-8 bei der „normalen Datenspeicherung” durchgesetzt hat ist vielleicht wieder Deine Linux-Insel. Windows scheint UTF-16 zu bevorzugen. Und im asiatischen Sprachraum wird wohl auch der ein oder andere UTF-8 als ziemliche Platzverschwendung ansehen, auch wenn er Linux verwendet.

@jens: Das die Windowskonsole kein echtes DOS mehr laufen lässt ist egal, die Standardkodierung ist trotzdem noch CP850. Das weiss ich aus eigener Erfahrung und das zeigt doch auch der Stacktrace der Ausnahme wegen der dieses Thema hier existiert.

Ich denke viele Privatanwender unterschätzen wie viele Textanwendungen aus DOS-Zeiten heute noch als Branchen- und Individuallösungen laufen die ihre „GUI” aus den Grafikzeichen aus DOS-Zeiten aufbauen und wo statt einer teuren „Neuentwicklung” das DOS-Programm einfach als Windows-Konsolenanwendung neu übersetzt wurde. Da spielt vielleicht auch hinein das die meisten Leute sich nicht klar machen das selbst verhältnismässig kleine Individualsoftware-Projekte schnell mal den Preis von einem Kleinwagen kosten. Das ist dann die Entscheidung zwischen, das Projekt übersetzt jetzt mal ein mittelmässiger Programmierer mit einem anderen Compiler und einer kleinen allgemeinen Kompatibiltätsbibliothek nahezu unverändert für die Windows-Konsole für ein paar hundert Euro, und mindestens ein guter Programmierer mit Domänenwissen portiert das jetzt zu einer Windowsanwendung und konvertiert alle Daten für 20,000€, das Programm kann danach aber nicht mehr, nur das was es vorher auch konnte.

[Hellstorm]

@Hellstorm: Windows (NT oder nicht) hat zu irgendeiner Zeit mal UTF-8 benutzt? Die UTF-Kodierungen und Unicode-Implementierungen haben auch ihre Macken. Man kann zum Beispiel Probleme damit bekommen wenn die selbe Zeichenkette einmal „composed” und einmal „decomposed” vorliegt, und die Implementierung nicht normalisiert und somit der Vergleich von gleichen Texten fehlschlägt. MacOS speichert im Dateinamen zum Beispiel „decomposed” und CPython normalisiert Unicode weder bei der Dekodierung noch bei Operationen wie Vergleichen.

Tut mir leid, da habe ich mich undeutlich ausgedrückt. Ich meinte, dass Windows Unicode benutzt (nicht speziell UTF-8). Windows benutzt ja UTF-16.

Ich hab ja auch gesagt, dass Unicode nicht unbedingt der Weisheit letzter Schluss ist. Dass MacOS z.B. ein ä immer als a + Doppelpunkt kodiert, woanders allerdings direkt der zusammengesetzte Buchstabe genutzt wird, ist mir auch schon sehr sehr oft aufgefallen. Finde ich auch sehr störend. Es gibt da auch noch andere Sachen, wo irgendetwas doppelt kodiert ist usw. Aber immerhin kann man die Sachen damit schreiben, bei alten Kodierungen geht es nicht.
Dass (vernünftig unterstütztes) Unicode sehr sehr viel Aufwand in der Implementierung erfordert stimmt natürlich. Wobei das jetzt natürlich nur begrenzt was mit der eigentlichen Zeichenkodierung zu tun hat, sondern mit Unicode an sich.

Du demonstrierst in Deinem letzten Beitrag auch schön die Insellösung. Ja klar funktioniert das mit Linux das auf UTF-8 eingestellt ist. Schön das *Deine* Welt nur daraus zu bestehen scheint. Andere müssen mit mehr Systemen arbeiten und auch Daten zwischen denen austauschen. Man kann auch bei vielen Systemen nicht einfach mal eben ein Upgrade machen, wenn das produktiv etwas drauf läuft. Und das nur wegen der Kodierung in der Konsole. Da kann man auch nicht sagen „Pech gehabt”. Was ist denn das für ein Unsinn? Selbst auf einem „UTF-8-Linux” gibt es Software wo man sich um die Kodierung kümmern muss, also sie zumindest explizit einstellen muss weil UTF-8 eben doch nicht überall die Voreinstellung ist. Datenbanken zum Beispiel sind so ein Thema wo man oft noch Einstellungen vornehmen muss. Und bei Windows ist dann halt Ende weil das sogar im gleichen System in der Konsole etwas anderes benutzt als bei der „Systemkodierung” und beides ist in aller Regel kein UTF-8 sondern jeweils eine Kodierung die nicht alle Unicode-Zeichen abdeckt.

Das die Konsole unter Windows in CP850 läuft hat nichts mit Schattendasein zu tun, sondern mit Rückwärtskompatibilität. Es gibt halt noch genug Software die keine Ahnung von Unicode hat und die einfach davon ausgeht, dass unter einem Windows in der Konsole Bytes ausgegeben werden können, die CP850 kodierten Zeichen entsprechen.

Tut mir leid, ich geh natürlich erstmal von der normalen Consumer-Lösung aus (Geschäftliche Sachen betreffen mich nicht so sehr – Jetzt kann man hier natürlich wieder kritisieren, dass ich da die Augen vor verschließe). Aber auch da könnte man doch Lösungen entwickeln: Was würde denn z.B. dagegen sprechen, die Konsole unter Windows 9 unter Unicode laufen zu lassen und einfach eine Option für Rückwärtskompatibilität einzubauen, die dann eine andere Kodierung einstellt? Im Grunde so etwas wie dieses chcp, nur eben systemweit und mit Unicode als Standard (der dann allerdings umstellbar ist). Das gibt es doch bei sehr vielen anderen Sachen in Windows auch (Kompatibilitätsmodus usw). Wer dann noch ältere Software hat, die das fordert, der stellt halt einfach die Option um.

Ausserdem gibt es Unmengen von vorhandenen Daten aus den letzten Jahrzehnten in den verschiedensten Kodierungen. Man wird sich also auch in Zukunft mit dem Thema Kodierung als Programmierer auseinandersetzen müssen, wenn man sich nicht auf seine kleine Insel von Linux nach 2006 beschränken kann.

Klar, ich sage ja nicht, dass man sich gar nicht mehr darum kümmern muss. Aber wenn im eigenen Projekt diese Fälle nicht zur Geltung kommen, dann vereinfacht es die Sache doch unglaublich, wenn es einfach funktioniert, oder nicht?
Wenn man sich dann trotzdem doch darum kümmern muss, dann ist das ja immer noch eine Option für den speziellen Fall.

Das Aushandeln der Kodierung ist halt genau das Problem: Es gibt keinen allgemeinen Weg dafür der das zurverlässig kann, und in vielen Fällen geht es schlicht gar nicht. Das schreibe ich jetzt nicht das erste mal hier. Überliest Du das jedes mal? Und dort wo ausgehandelt wird, und dann halt CP850 raus kommt, gefällt es Dir anscheinend nicht.

Nee, das überlese ich nicht Ich wollte in meinem vorliegenden Fall halt im Grunde nur wissen, was ich da einstellen muss. Das war es einfach nur.

Aber Python kann doch sogar erkennen, was die aktuelle Kodierung ist. Wo ist denn dann das Problem?

Windows verwendet alle möglichen Kodierungen. Und genau so machen das Windows-Anwendungen. CP1251 und CP850 in unseren Breitengraden und UTF-16. Andere Kodierungen in anderen Ländern und Regionen. Das was Du also der Windowskonsole vorwirfst, kannst Du jeder Windowssoftware vorwerfen. Das mag aus Deiner Sicht dann vielleicht keine „gute” Software sein, aber dass ist das mit dem man da draussen konfrontiert wird.

Naja, „andere Kodierungen in anderen Ländern und Regionen“ ist ja genau die Sache, wofür es Unicode gibt. Klar bin ich mir bewusst, dass es solche Software gibt, aber ich ärger mich halt immer drüber (Wie gesagt, ich rede hier nur über Consumersoftware). Man arrangiert sich zwar damit, aber es wäre halt doch irgendwie besser, wenn es einfach problemlos funktionieren würde, oder nicht?

Und es bleibt ein IMHO ein Fehler in Python 3, denn selbst wenn Windows einheitlich UTF-16 verwenden würde, sind Programme bei denn scheinbar alles automagisch richtig gemacht wird, nicht portabel weil unter Linux UTF-8 und unter Windows UTF-16 verwendet würde und damit die Daten die das Programm geschrieben hat, nicht mehr von ihm selber gelesen werden können, ohne dass man sich explizit um die Kodierung kümmert. Das muss man als Programmierer machen. Jemand der sich darum drücken will ist IMHO kein guter Programmierer weil er versucht ein allgegenwärtiges Problem durch fest Augen zukneifen zu lösen versucht und Daten und Tatsachen ignoriert.

Natürlich. Wobei es mir selbst unter Windows so vorkommt, als ob für vieles, was nach draußen gelangt, UTF-8 benutzt wird. Nur intern im Programm wird UTF-16 benutzt (ohne das jetzt genauer mit Faktenwissen füttern zu können).

UTF-8 und UTF-16 haben ja für sich selber den Vorteil, dass sie untereinander voll umwandelbar sind. Ich will da jetzt natürlich nichts behaupten, aber die eigentliche Umrechnung könnte man doch dem System überlassen. Das System kann ja auch zuerst angeben, was denn eigentlich für eine Kodierung benutzt wird. Naja, aber da habe ich keine Ahnung von, deswegen sage ich da nichts weiter zu.

Na klar wäre Unicode überall eine nette Sache, das Problem ist aber das es nicht überall eingesetzt wird. Nicht einmal ansatzweise! Und da ich heute noch mit zu DOS-Zeiten kodierten Daten und Programmen aus dieser Zeit konfrontiert bin, sehe ich auch nicht, dass sich das in absehbarer Zeit auf magische Weise ändern wird. Unter Linux, und wenn man sich nur darauf beschränkt sieht es ja ganz gut aus, aber ich habe halt regelmässig mit dem parsen von Logdateien und ab und zu dem Konvertieren von Daten zwischen Windowsprogrammen zu tun und da ist es egal ob es alte oder neue Software ist, und auch ob es Individualsoftware oder ein Standardprodukt ist, man muss immer erst schauen wie die Daten kodiert sind. Es deutet für mich nichts darauf hin, dass man in absehbarer Zeit eine bestimmte Kodierung annehmen kann und nur in Ausnahmefällen noch etwas anderes verwendet wird. Noch schlimmer, man sieht auch fast regelmässig so etwas wie ”XML”-Dateien die keine Kodierung angegeben haben und CP1251 kodiert sind. Weil es zu viele Programmierer gibt, die sich mit dem Thema nicht befassen wollen oder können.

Wäre es dann aber nicht sinnvoll, wenn auch unter Windows dann Unicode standardmäßig für sowas geschrieben wird? Du sagst ja, dass es viele Programmierer gibt, die sich damit nicht befassen wollen. Man kann jetzt natürlich sagen: „Die sollen sich gefälligst damit befassen“, aber wie du oben schon gesagt hast, die Realität ist ja anders. Dann wäre es doch sinnvoll, sich dieser Realität zu fügen und die Dateien dann auf einen neueren Standard umzustellen, so dass sich irgendwann das Problem erledigt haben könnte (klar, vielleicht hat man dann in 30 Jahren immer noch Logdateien von vor 60 Jahren, aber die Zahl wird wahrscheinlich abnehmen).

Wenn den Programmierern die Kodierung egal ist, dann ist es ihnen doch auch egal, ob im Programm CP1251, ISO-8859-1, UTF-8 oder UTF-16 herauskommt. Wenn man nicht richtig direkt auf Byte-Ebene arbeitet sondern im Programm einfach nur einen String speichert (so wie ich das gemacht habe), dann kann die eigentliche Kodierung ja egal sein (das setzt jetzt natürlich wieder voraus, dass alles gleich ist, aber das sollte ja das Ziel sein).

Ich denke viele Privatanwender unterschätzen wie viele Textanwendungen aus DOS-Zeiten heute noch als Branchen- und Individuallösungen laufen die ihre „GUI” aus den Grafikzeichen aus DOS-Zeiten aufbauen und wo statt einer teuren „Neuentwicklung” das DOS-Programm einfach als Windows-Konsolenanwendung neu übersetzt wurde. Da spielt vielleicht auch hinein das die meisten Leute sich nicht klar machen das selbst verhältnismässig kleine Individualsoftware-Projekte schnell mal den Preis von einem Kleinwagen kosten. Das ist dann die Entscheidung zwischen, das Projekt übersetzt jetzt mal ein mittelmässiger Programmierer mit einem anderen Compiler und einer kleinen allgemeinen Kompatibiltätsbibliothek nahezu unverändert für die Windows-Konsole für ein paar hundert Euro, und mindestens ein guter Programmierer mit Domänenwissen portiert das jetzt zu einer Windowsanwendung und konvertiert alle Daten für 20,000€, das Programm kann danach aber nicht mehr, nur das was es vorher auch konnte.

Aber dafür kann man doch auf Wunsch eine Option schalten, die diese Rückwärtskompatibilität zulässt. So viel wird man den Unternehmen doch bei der Migration auf eine neue Windows-Version zutrauen können und da ist so eine Umstellung wohl das kleinste Problem, oder nicht?

Ich sage ja nicht, dass man die alten Möglichkeiten abschaffen sollte, aber einfach die Standardeinstellung umstellen und die alte Einstellung in einen Kompatibilitätsmodus machen. Das macht Linux doch auch nicht anders, wer will, kann sich dort doch eine ISO-8859-1-Locale (oder was anderes) installieren.

Wenn ich persönlich hier für mich was programmiere, was ich vielleicht in meinem Bekanntenkreis verteile, dann würde ich Windows, Linux und Mac OS in der Programmierung berücksichtigen. Aber es wäre doch schon sehr viel praktischer, wenn ich erwarten könnte, dass zumindest die Textkodierung überall halbwegs vernünftig läuft. Ich entwickel ja nicht für Unternehmen, sondern für den Privatgebrauch, und da haben die meisten Leute ein halbwegs aktuelles Betriebssystem.

[Hyperion]

Tut mir leid, da habe ich mich undeutlich ausgedrückt. Ich meinte, dass Windows Unicode benutzt (nicht speziell UTF-8). Windows benutzt ja UTF-16.

Ich hab ja auch gesagt, dass Unicode nicht unbedingt der Weisheit letzter Schluss ist.

Du hast etwas grundsätzliches noch nicht verstanden: UTF-* != Unicode

Wenn Du das verstanden hast, wird vermutlich auch der "Rest" klarer

[BlackJack]

@Hellstorm: Python kann in einigen sehr wenigen Fällen erkennen was die Gegenseite als Kodierung erwartet, und rät in den anderen Fällen (Python 3) oder geht vom kleinsten gemeinsamen Nenner ASCII aus (Python 2). Wo das Problem ist fragst Du? Na dass *Du* damit offensichtlich unzufrieden bist. Und ich halt mit dem Verhalten von Python 3 weil es Programmierer die nicht über das Thema Kodierungen nachdenken in falscher Sicherheit wiegt, dass ihr Programm mit Unicode generell automatisch richtig umgeht. Was nicht geht, weil „richtig” nicht zuverlässig ermittelt werden kann. Nicht plattformübergreifend, aber auch noch nicht einmal auf ein und dem selben System. Es gibt nicht *die* aktuelle Kodierung.

Ich verstehe Deine Logik nicht: Du sagst die Programmierer die sich nicht mit Kodierung befassen (wollen/können) sollen sich doch mal mit Kodierung befassen und alles in *einer* gemeinsamen Kodierung speichern, dann wird in Zukunft alles gut. Das widerspricht sich doch. Wenn sich mehr Programmierer mit Kodierungen befassen würden, dann würde IMHO schneller alles gut, oder zumindest besser. Denn dann würde es wahrscheinlich mehr Anwendungen geben die 1. UTF-8 oder UTF-16 schreiben und auch beides standardmässig lesen können *und* 2. die Möglichkeit bieten per Optionen andere Kodierungen fürs lesen und schreiben einzustellen.

Übrigens bist Du letztendlich irgendwie doch meiner Meinung das das Verhalten von Python 3 ein Fehler ist, denn meine bevorzugte Lösung wäre da nämlich das Standard UTF-8 wäre, genau wie bei den Quelltexten selber. UTF-8 auf jedem System und in jeder Umgebung und nicht überall etwas anderes. Das würde garantieren dass es keine `Unicode(En|De)codeError` geben könnte und dass die Daten zumindest von dem gleichen Python-Programm überall sowohl geschrieben, als auch gelesen werden können, auch wenn man Daten zwischen den Systemen/Umgebungen überträgt.

Das Privatpersonen ein halbwegs aktuelles Betriebssystem haben würde ich nicht als gegeben ansehen. Viele haben das System was beim Rechner dabei war und bleiben dabei bis die Unterstützung ausläuft oder noch länger. Ich weiss nicht mehr die genaue Prozentzahl, aber selbst ich war überrascht wie viele Privatanwender noch Windows XP einsetzen. Ich glaube das so jeder Dritte private Windowsrechner in Deutschland.

[Hyperion]

Nicht zu vergessen eine Option für die ``print``-Funktion, der man ein Encoding übergeben könnte! Das nervt aktuell so richtig...

[Hellstorm]

Du hast etwas grundsätzliches noch nicht verstanden: UTF-* != Unicode

Wenn Du das verstanden hast, wird vermutlich auch der "Rest" klarer

Nene, ich hab das schon verstanden Ich hab mich nur undeutlich ausgedrückt, weil ich im Satz davor von Linux als UTF-8 geredet habe. Dass Windows UTF-16 benutzt weiß ich. Dass Unicode auch nur das „Rahmenwerk“ ausdrückt aber keine „technische“ Zeichenkodierung ist, weiß ich auch. (Wobei UTF-16 ja zumindest die BMP direkt abbildet).

Auch wenn ich vom Programmieren nicht wirklich Ahnung habe, Unicode verstehe ich doch schon recht gut (habe mir sogar das Buch gekauft!)

@Hellstorm: Python kann in einigen sehr wenigen Fällen erkennen was die Gegenseite als Kodierung erwartet, und rät in den anderen Fällen (Python 3) oder geht vom kleinsten gemeinsamen Nenner ASCII aus (Python 2). Wo das Problem ist fragst Du? Na dass *Du* damit offensichtlich unzufrieden bist. Und ich halt mit dem Verhalten von Python 3 weil es Programmierer die nicht über das Thema Kodierungen nachdenken in falscher Sicherheit wiegt, dass ihr Programm mit Unicode generell automatisch richtig umgeht. Was nicht geht, weil „richtig” nicht zuverlässig ermittelt werden kann. Nicht plattformübergreifend, aber auch noch nicht einmal auf ein und dem selben System. Es gibt nicht *die* aktuelle Kodierung.

Naja, gut, ok. Ich hab gemerkt, dass man das doch wirklich von mehreren Seiten betrachten muss

Ich verstehe Deine Logik nicht: Du sagst die Programmierer die sich nicht mit Kodierung befassen (wollen/können) sollen sich doch mal mit Kodierung befassen und alles in *einer* gemeinsamen Kodierung speichern, dann wird in Zukunft alles gut. Das widerspricht sich doch. Wenn sich mehr Programmierer mit Kodierungen befassen würden, dann würde IMHO schneller alles gut, oder zumindest besser. Denn dann würde es wahrscheinlich mehr Anwendungen geben die 1. UTF-8 oder UTF-16 schreiben und auch beides standardmässig lesen können *und* 2. die Möglichkeit bieten per Optionen andere Kodierungen fürs lesen und schreiben einzustellen.

Naja, Programmierer die sich mit „Low-Level-Sachen“ (ich nenn das jetzt einfach mal so) beschäftigen sollen sich doch mit Kodierung beschäftigen. Da geht es halt nicht anders.
Aber bei einem relativ „einfachen“ Programm ist das in vielen Fällen vielleicht nicht nötig (Was nicht heißt, dass ich nicht trotzdem jedem Programmierer anraten würde, sich damit eingehend zu beschäftigen). Wenn viele Programmierer sich dann trotz stärkstem Ermutigens nicht damit befassen wollen, wäre es halt nett, dass es zumindest bis zu einem gewissen Grad automatisch funktioniert.

Übrigens bist Du letztendlich irgendwie doch meiner Meinung das das Verhalten von Python 3 ein Fehler ist, denn meine bevorzugte Lösung wäre da nämlich das Standard UTF-8 wäre, genau wie bei den Quelltexten selber. UTF-8 auf jedem System und in jeder Umgebung und nicht überall etwas anderes. Das würde garantieren dass es keine `Unicode(En|De)codeError` geben könnte und dass die Daten zumindest von dem gleichen Python-Programm überall sowohl geschrieben, als auch gelesen werden können, auch wenn man Daten zwischen den Systemen/Umgebungen überträgt.

Ja, das stimmt. Überall UTF-8.

Das Privatpersonen ein halbwegs aktuelles Betriebssystem haben würde ich nicht als gegeben ansehen. Viele haben das System was beim Rechner dabei war und bleiben dabei bis die Unterstützung ausläuft oder noch länger. Ich weiss nicht mehr die genaue Prozentzahl, aber selbst ich war überrascht wie viele Privatanwender noch Windows XP einsetzen. Ich glaube das so jeder Dritte private Windowsrechner in Deutschland.

Naja, das stimmt, aber bei Privatanwendern hat man in vielen Fällen (wenn man es nur zum Spaß macht) nicht das Problem, dass man auf uralte Systeme Rücksicht nehmen muss. Bei speziell für Unternehmen entwickelten Programmen ist das natürlich wieder was anderes, da muss man sich damit beschäftigen (sonst gibt es kein Geld), aber bei Privatanwendern kann man doch noch zu einem gewissen Punkt Druck ausüben, mal auf ein aktuelles Betriebssystem umzusteigen