Python CSV-Dateien / Zeichensatz-Probleme

[dieterz1]

Guten Morgen!
In Python nutze ich für die Verarbeitung von CSV-Dateien das CSV-Modul.
Bisher hatte ich das Problem, dass beim speichern/auslesen der CSV-Datei die Umlaute falsch dargestellt wurden.
Das Problem konnte gelöst werden, indem die Codezeile "with open" um den Code "enconding="utf8" erweitert wurde:

with open(meinDateiname, encoding="utf8") as csv1

Öffne ich die mit Python erstellte CSV-Datei nun mit MS Excel 2016, werden innerhalb von Excel die Umlaute falsch dargestellt, innerhalb von Notepad++ tritt dieses Problem jedoch nicht auf.

Testweise habe ich in Excel ein neues, leeres Blatt geöffnet, dort Umlaute eingetragen, und das Excel Sheet als csv abgespeichert. Anschließend habe ich diese Test-CSV-Datei mit Notepad++ geöffnet und die Kodierung mit der Python-CSV-Datei verglichen. Beide Dateien sind lt. Notepad++ als "UTF-8" kodiert.

Warum hat Excel trotzdem ein Problem mit den Umlauten, wenn die Datei von Python erstellt wurde?

 

[Yuuri]

Und du importierst in Excel auch über Daten -> Aus Text/CSV?

 

[Tornhoof]

Setzt du in Excel auch die Codierung beim Import?
Ansonsten konvertier/schreib deine Datei als UTF 8 mit BOM, dann ist von vorneherein klar welche Enkodierung existiert.
UTF8 sieht für eine Applikation erstmal wie ASCII aus, bis ein UTF8 Symbol gefunden wurde, je nach wieviel Excel prüft kann es sein dass es nicht erkannt wird.
Forcieren wie gesagt mit UTF8 mit BOM oder beim Excel import manuell UTF8 auswählen.

 

[dieterz1]

Setzt du in Excel auch die Codierung beim Import?

Nein, ich mach nur einen Doppelklick auf die csv-Datei und dann öffnet sich Excel automatisch.

Was kann ich nun tun, damit Excel die Umlaute richtig darstellt, ohne dass ich beim öffnen der Datei noch manuell nachhelfen muss?

 

[pizza4ever]

steht bereits oben: utf8 mit bom bzw in python heißt es wohl utf8-sig

p.s.: ist grundsätzlich schlechter Stil und sollte nur dann verwendet werden wenn es zwingend erforderlich ist

 

[dieterz1]

Die Lösung ist also "utf8 mit bom", soll aber nicht verwendet werden??

 

[pizza4ever]

Wie gesagt, es ist die Lösung deines Problems. Man soll es vermeiden aber es geht ja kaum anders (die anderen Lösungen sind erheblich schlimmer).

 

[Tornhoof]

Testweise habe ich in Excel ein neues, leeres Blatt geöffnet, dort Umlaute eingetragen, und das Excel Sheet als csv abgespeichert. Anschließend habe ich diese Test-CSV-Datei mit Notepad++ geöffnet und die Kodierung mit der Python-CSV-Datei verglichen. Beide Dateien sind lt. Notepad++ als "UTF-8" kodiert.

Dein Test ist unvollständig, wenn du in Excel ein Sheet als CSV mit UTF8 speicherst (das ist ein Eintrag in der Liste der Dateiformate), wird es auch als UTF8 mit BOM gespeichert.
Der "richtige" Weg UTF8 zu testen ist immer mit Glyphen (also z.b. chinesische Zeichen, das Eurosymbol etc.), die müssen in UTF8 als Multibyte enkodiert werden ansonsten geht's nicht. Alle Versuche mit Buchstaben die nur ein Byte brauchen (also z.b. Umlaute mit einer Latin1/Westeuropäischen Enkodierung mit passendem Betriebssystem) sind nicht aussagekräftig, da sie abhängig vom OS, Excelversion usw sind.
Excel erwartet UTF8 CSV Dateien mit BOM, also 'utf-8-sig' in python (keine Ahnung wieso das sig dort heißt).

 

[pizza4ever]

Der "richtige" Weg UTF8 zu testen ist immer mit Glyphen (also z.b. chinesische Zeichen, das Eurosymbol etc.), die müssen in UTF8 als Multibyte enkodiert werden ansonsten geht's nicht. Alle Versuche mit Buchstaben die nur ein Byte brauchen (also z.b. Umlaute mit einer Latin1/Westeuropäischen Enkodierung mit passendem Betriebssystem) sind nicht aussagekräftig, da sie abhängig vom OS, Excelversion usw sind.

Umlaute brauchen in UTF-8 mehr als ein Byte und sind daher schon für einen Test geeignet (und sind sicher NICHT vom Betriebssystem abhängig). Entscheidend ist wie du ja selbst gesagt hast das BOM, was aber halt nicht von allen Programmen erkannt wird.

 

[Tornhoof]

Umlaute brauchen in UTF-8 mehr als ein Byte und sind daher schon für einen Test geeignet (und sind sicher NICHT vom Betriebssystem abhängig)

Edith sagt:
Ja, aber die einzelnen Bytes sind immernoch interpretierbar als ASCII Symbole gemäß 7BIt Ascii.
Beispiel: Ä ist c3 84, C3 ist in 8Bit ASCII jedoch valide à und 84 ist irgendein Control byte.

Und genau da rennst du in die idiotschen Codepages von Windows, dem Equivalent von Linux, Macos usw.
die Intepretation von Ä ist im Worst case Aufgabe des Betriebssystem, wenn du also eine ISO8859 codepage eingestellt hast und jedes byte als einzelnes Byte interpretiert hast, genau dann kommen ja die Fehlerzeichen.

Das ist ja der klassiker als Fehler, du kriegst ein UTF8 textdokument und liest es als iso8859-1 ein, die Wahrscheinlichkeit das Fehler auftreten ist gering, weil die Umlaute selten sind. Je nach Umlaut kommt dann ja ein à raus und das wird dann gerne übersehen, eine HAndvoll Umlaute werden dann ein Fehlerzeichen weil nicht valid in UTF8. Das meinte ich mit "richtigem" Weg.