Das deutsche Python-Forum

@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.

Hellstorm hat geschrieben: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...

@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.

BlackJack hat geschrieben:@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.

BlackJack hat geschrieben: 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.

BlackJack hat geschrieben: 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.

BlackJack hat geschrieben: 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?

BlackJack hat geschrieben: 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?

BlackJack hat geschrieben: 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.

BlackJack hat geschrieben: 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).

BlackJack hat geschrieben: 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.

Hellstorm hat geschrieben: 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

@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.

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

Hyperion hat geschrieben: 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!)

BlackJack hat geschrieben:@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

BlackJack hat geschrieben: 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.

BlackJack hat geschrieben: Ü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.

BlackJack hat geschrieben: 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