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
Kurze Antwort: es gibt keinen verlässlichen Weg das Encoding von Dateien zu bestimmen. Genau wie 'chardet' ist man auf Heuristiken angewiesen, um eine verlässliche Entscheidung treffen zu können. Es gibt keinen Algorithmus, um das Encoding 100%-ig bestimmen zu können. Die einzig halbwegs verlässige Methode beim Umgang mit UTF kodierten Dateien ist die *Verwendung* und *Auswertung* des BOM. Ob eine Datei in ISO-8859-1 (alter Standard) vs. ISO-8859-15 (neu, mit EUR Zeichen) - ist nur durch eine (statistische Analyse) möglich. Insofern ist es besser wenn man weiss mit welchen Encodings die Dateien geschrieben wurden. Raten von Encodings bringt i.A. nur Ärger
-aj
Am 10. April 2012 08:49 schrieb Michael Weber <michael.weber@fh-stralsund.de
:
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 ______________________________**_________________ python-de maillist - python-de@python.org http://mail.python.org/**mailman/listinfo/python-dehttp://mail.python.org/mailman/listinfo/python-de
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
Mahlzeit,
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.
Grüße Michael
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.
Mahlzeit,
Es geht einfach nicht wirklich automatisiert. Es gibt letztlich nur zwei Möglichkeiten:
In der Schnittstelle (konfigurierbar) das Encoding der Eingabedaten festlegen.
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.).
Okay. Das muss ich dann halt so hinnehmen.
Ciao, Michael.
Ebenfalls 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))
Hallo Thomas,
das werde ich mir doch glatt mal zu Gemüte führen.
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))
Grüße und Danke Michael
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
Ebenfalls hallochen,
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.
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)
Gruß und Danke 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
participants (7)
-
Andreas Jung -
Bernd Nawothnig -
Matthias Felsche -
Michael Ströder -
Michael Weber -
Thomas Guettler -
Thomas Waldmann