Das deutsche Python-Forum

da müsste man sich mal in englischen Foren umschaun... Obwohl-.- Die haben das Problem ja nich und ich denk, denen wird das evtl auch egal sein

Aber dann würd doch was beim CookBook stehen oder so?! Ich mein, Russen oder Tschechen oder Araber haben das Problem ja auch...

Also ich denk, ganz ehrlich gesagt nich, dass Python schon was dabei hat, sonst hätte das sicher schon jemand gefunden und es wär bekannt.
Gibt es noch andere deutschsprachige Pythonforen. Vielleicht haben die ja User, die schon sowas gebaut haben, oder wissen, wie es geht:roll:

Greetz

P.S. Kein Problem für den Test. Kann ich mehrere Pythonversionen laufen lassen? Dann test ichs noch mit anderen Pythonversionen und wenn meine neuen Ubuntu CDs kommen, gibts auch den Test auf (K)Ubuntu 6.04

Nenn mit noch ein paar IDEs mit denen Ich testen soll, dann test ich dir das auch eben noch

CrackPod hat geschrieben:Also ich denk, ganz ehrlich gesagt nich, dass Python schon was dabei hat, sonst hätte das sicher schon jemand gefunden und es wär bekannt.
Gibt es noch andere deutschsprachige Pythonforen. Vielleicht haben die ja User, die schon sowas gebaut haben, oder wissen, wie es geht:roll:

Nein, wir sind das einzige deutschsprachige Webforum, aber es gibt noch die Mailingliste Python-de und die Newsgroup de.comp.lang.python, ebenso den IRC-Channel #python.de auf freenode. Und es gibt Martin von Löwis

Leonidas hat geschrieben:[...]Und es gibt Martin von Löwis

Kenn ich nich, also sowohl Martin als auch Löwis

- scheint aber bekannt zu sein, wenn er so explizit erwähnt wird.
Wenn er so bekannt is, schlies ich daraus, dass er sehr (sehr) gut ist. Wenn er aber so gut ist, dann müsste er sich doch auch mit dem Problem befasst haben, oder irgendwer in der Mailingliste?! Wieso gibt es dann noch keine Lösung?

Greetz

CrackPod hat geschrieben:Kenn ich nich, also sowohl Martin als auch Löwis

MvL ist einer der Mit-Autoren der Unicode-Implemetation in Python 2.0, zusammen mit Marc-André Lemburg (MAL) und weiteren.

CrackPod hat geschrieben:- scheint aber bekannt zu sein, wenn er so explizit erwähnt wird.

Klar, man liest immer wenn es Unicode-Probleme von ihm.

CrackPod hat geschrieben:Wenn er aber so gut ist, dann müsste er sich doch auch mit dem Problem befasst haben,

Hat er doch. Er hat Unicode implementiert.

CrackPod hat geschrieben:Wieso gibt es dann noch keine Lösung?

Wenns nach ihm geht, gibts schon Lösungen für Unicode-Probleme. Frag' ihn einfach mal, dann wirst du verstehen was ich meine

Meine Meinung zum Thema: Es gibt keinen Weg die Kodierungen verlässlich zu raten. Man sollte es einfach lassen. Das raten meine ich. Und stattdessen als Standard ASCII oder UTF-8 benutzen und in seinen Programmen Optionen anbieten mit denen der Anwender explizit sagen kann was er haben möchte.

Dann hat man weniger Überraschungen. Mal angenommen ich benutze so ein "ratendes" Programm und lasse mir etwas auf der Konsole ausgeben und das Programm rät richtig was ich dort für eine Kodierung benutze. Dann denke ich cool, UTF-8 ist nett und leite die Ausgabe mit der Shell in eine Datei um. In dem Glauben das ich jetzt UTF-8 in der Datei habe. Aber leider rät das Programm für die Umleitung etwas anderes weil `sys.stdout.encoding` dann nämlich `None` ist. Das ist eine ziemlich doofe Überraschung. IMHO.

Wie auch immer:

Code: Alles auswählen

Python 2.2 (#1, Feb 17 2003, 21:43:03) [C] on aix4
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.platform
'aix4'
>>>

Das Problem hatte ich auch schonmal, rauszufinden wie der entsprechenden Plattform-Strings heissen. Mac OSX ist ja auch Linux-like, da kommt bei sys.platform irgendwas mit "darwin" raus... (der Name des Kernels.)

BlackJack hat geschrieben:Es gibt keinen Weg die Kodierungen verlässlich zu raten.
[...]
Optionen anbieten mit denen der Anwender explizit sagen kann was er haben möchte.

Hi BlackJack!

Leider ist es so, dass man die Kodierung raten muss. Allerdings kann man das Raten verbessern. Je mehr Informationen ich über die Platform habe, desto eher bekomme ich das korrekte Encoding raus. Ein 90 % richtig geratenes Encoding ist ja auch nicht schlecht, oder? Außerdem könnte ich ja prüfen, ob es eine Konfigurationsdatei gibt, die ein Encoding vorgibt, oder das Umleiten über den Stream-Writer unterbindet.

encoding.ini (alles automatisch):

Code: Alles auswählen

[stdout]
encoding = Auto

encoding.ini (utf-8 vorgegeben):

Code: Alles auswählen

[stdout]
encoding = utf-8

encoding.ini (nicht verwenden):

Code: Alles auswählen

[stdout]
encoding = None

Wenn die INI-Datei nicht im Projektordner existiert, dann wird der Encodinghelper für STDOUT verwendet und es wird versucht, das Encoding automatisch raus zu bekommen. Wenn ich ihn als Programmierer nicht verwenden möchte, dann muss ich ihn ja nicht importieren.

Und? Klingt das für dich besser?

lg
Gerold

Hi!

Ich habe mal wieder etwas am Encodinghelper geändert.
Wenn erkannt wird, dass IDLE mit im Spiel ist, dann leitet
der Encodinghelper STDOUT nicht um.

Trac: http://gelb.bcom.at/trac/misc/wiki/Encodinghelper
Quellcode: http://gelb.bcom.at/trac/misc/browser/e ... ghelper.py

Damit der Zweck dieses Moduls nicht vergessen wird:
Importiert man das Modul ``encodinghelper.py``, dann wird geprüft, welches Encoding für STDOUT eingestellt ist. Gibt ``sys.stdout.encoding`` diese Information nicht her, wird herausgefunden, welches Betriebssystem verwendet wird und auf Grund dieser Information noch einmal versucht, das Encoding herauszufinden.

Danach wird STDOUT über den StreamWriter des Moduls "codecs" umgeleitet und damit automatisch von **Unicode** in das Zielplattform-Encoding umgewandelt.

Falls dieser Automatismus das korrekte Encoding nicht herausfinden kann, kann man das Encoding in eine INI-Datei schreiben, die vom ``encodinghelper.py`` ausgelesen wird. So kann man auch Sonderfälle abdecken.

Verbesserungsvorschläge sind erwünscht.

lg
Gerold

Ich hab mal Links hier eingefügt:
[wiki]Von Umlauten, Unicode und Encodings[/wiki]

Das deutsche Python-Forum

Allgemeine Lösung für Umlautprobleme?