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.
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.
(habe mir sogar das Buch gekauft!)