MoinMoin, siehe die Antwort von Andreas Jung. Was man noch hinzufuegen kann, ist, dass wenn die Wahrscheinlichkeit von utf-8 oder iso-8859-1(5) relativ hoch ist (und man keine anderen hilfreichen Hinweise hat), dass man es dann zuerst probieren kann, mit utf-8 zu decodieren. Wenn das tut (also keine Exception wirft), ist es sehr wahrscheinlich auch wirklich utf-8. Wenn nicht, dann eben sein Glueck mit 8bit-Encodings probieren, da wird's dann schwierig. moin2 wird aus diesem Grund den content-type speichern, z.B. "text/plain;charset=utf-8" - dann weiss man, was man hat. mfg Thomas

Michael Weber wrote:

ich bin selber gerade schmerzlicher weise zur Erkenntnis gekommen, dass chardet nicht wirklich sinnvoll ist. Gerade wurde ein ISO-8859-1 als EUC-KR-Encoding angesehen. Da kommt dann natürlich ausgesprochener Müll bei raus. Aber gut.

Zumindest weiß ich jetzt, was ich nicht nehme.

Für Hinweise bin ich jederzeit offen.

Es geht einfach nicht wirklich automatisiert. Es gibt letztlich nur zwei Möglichkeiten: 1. In der Schnittstelle (konfigurierbar) das Encoding der Eingabedaten festlegen. 2. Encoding raten und dann das geratene Encoding dem Benutzer interaktiv zur Korrektur vorlegen (z.B. wie der manuell beeinflussbare CSV-Import in Excel/Libreoffice etc.). Ciao, Michael.

Am 10.04.2012 08:49, schrieb Michael Weber:

Guten Morgen werte Mitstreiter,

ich hab da mal ne Frage. Ich denke, dass dieses Thema bereits vielfach und sehr ausdauernd beredet wurde und vielleicht wird dieses Thema bereits gehasst. Man weiß es nicht, daher jetzt meine Frage.

Hallo, ich verwende folgendes Schnippsel gelegentlich. Für meine Zwecke reicht es (latin1 vs utf8). Hier wird aber mit Zeichenketten gearbeitet, so dass nicht codecs.open() gearbeitet werden kann. # Attention: Order of encoding_guess_list is import. Example: "latin1" always succeeds. encoding_guess_list=['utf8', 'latin1'] def try_unicode(string, errors='strict'): if isinstance(string, unicode): return string assert isinstance(string, str), repr(string) for enc in encoding_guess_list: try: return string.decode(enc, errors) except UnicodeError, exc: continue raise UnicodeError('Failed to convert %r' % string) def test_try_unicode(): for start, should in [ ('\xfc', u'ü'), ('\xc3\xbc', u'ü'), ('\xbb', u'\xbb'), # postgres/psycopg2 latin1: RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK ]: result=try_unicode(start, errors='strict') if not result==should: raise Exception(u'Error: start=%r should=%r result=%r' % ( start, should, result)) -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de

Hallöchen, ich habe es noch nicht probiert, aber unabhängig von der automatisierten Nutzung in einem Python-Programm hat mir auf der Kommandozeile das ``file``-Kommando bisher immer gute Dienste geleistet. Und mit https://github.com/ahupp/python-magic hast du einen schönen Wrapper drum herum an der Hand. Bitte berichte doch, ob es dein Problem lösen konnte. viele Grüße Matthias Am 10.04.2012 08:49, schrieb Michael Weber:

Guten Morgen werte Mitstreiter,

ich hab da mal ne Frage. Ich denke, dass dieses Thema bereits vielfach und sehr ausdauernd beredet wurde und vielleicht wird dieses Thema bereits gehasst. Man weiß es nicht, daher jetzt meine Frage.

Ausgangslage: ich habe Textdateien, die unter Windows bzw. Linux erstellt werden. Nun habe ich durch testen herausbekommen, dass seitens Linux z.b. Dateien mit UTF-8 erstellt werden. Gleichzeitig ist es auch möglich, dass de_DE@euro verwendet wird (Gentoo sei dank). Und Windows macht dann iso-8859-1.

Gut, ich denke mal, die Erkenntnisse haben viele schon gehabt.

Nun folgendes. Ich möchte gerne beim Öffnen der Datei mit codecs.open das korrekte Encoding angeben. Zum Ermitteln des gesuchten Encoding habe ich mich einfach mit chardet auseinandergesetzt und das dann halt auch genommen. Nun habe ich z.B. vernommen, dass das scheinbar nicht so gern gesehen ist und man kann dabei ja auch mal das falsche ermitteln (so ist es mir passiert: bei iso-8859-1 wird iso-8859-2 detektiert).

Und jetzt endlich die Frage: Wie würdet ihr das machen? Ein Shellaufruf und dann mit "file -ib <DATEI>" vielleicht? Oder gibt es da was schöneres, eleganteres und auch sinnvolleres??

Gruß und herzlichsten Dank Michael

On 2012-04-12, Michael Weber wrote:

...

ich habe es noch nicht probiert, aber unabhängig von der automatisierten Nutzung in einem Python-Programm hat mir auf der Kommandozeile das ``file``-Kommando bisher immer gute Dienste geleistet. Und mit

https://github.com/ahupp/python-magic

hast du einen schönen Wrapper drum herum an der Hand.

Bitte berichte doch, ob es dein Problem lösen konnte.

ich hab mir das Teils mal zu Gemüte geführt und kann mit Freude berichten, dass bis jetzt immer die korrekten Encodings ermittelt wurden.

Daher würde ich ja fast mal sagen, dass es geklappt hat und mein Problem damit gelöst ist.

(In der Hoffnung, dass mir auch wirklich immer das korrekte Encoding heraus geworfen wird)

Letzteres, also die Garantie auf "wirklich immer" nur bei Kenntnis der nackten Datei, ist leider prinzipiell nicht möglich. Allerdings hast Du mit file schon einen sehr guten heuristischen Ansatz. Ich glaube kaum, dass Du so was besseres finden wirst. Bernd -- "Die Antisemiten vergeben es den Juden nicht, dass die Juden Geist haben - und Geld." [Friedrich Nietzsche]