CSV-Import in MySQL mit Umlauten

julia29

Erfahrenes Mitglied
Hallo,

hatte noch nie solche Probleme mit csv-Import. Alle Umlaute werden mit einem "?" dargestellt oder der Text in diesem Feld beim Antreffen eines Umlautes abgschnitten.

Wenn ich mir die CSV-Datei mit einem Texteditor ansehe, also als wenn ich diese importieren würde, werden mit Zeichsatz Westeuropa (Windows-1252/WinLatin) alle Umlaute korrekt dargestellt.

Gleiche Datei in MySQL mit Datei-Zeichensatz utf8, latin1, latin2, latin5, latin7 zeigt keine Veränderungen. Der Text in der Zeile wird ab Umlaut abgeschnitten.

Bei folgenden MySQL-Einstellung
Datei-Zeichensatz utf8
Text-Beispiel: Müller;Willi;Müllerweg 77;99999;Müllhausen

Kollation utf8_general_ci (ab Umlaut wird Text abgeschnitten "M ")
Kollation utf8_unicode_ci (ab Umlaut wird Text abgeschnitten "M ")
Kollation latin1_general_ci (Text wird NICHT abgeschnitten aber "M?ller;Willi;M?llerweg 77;99999;M?llhausen")
Kollation latin1_general_cs (Text wird NICHT abgeschnitten aber "M?ller;Willi;M?llerweg 77;99999;M?llhausen")
Kollation latin1_german1_ci (Text wird NICHT abgeschnitten aber "M?ller;Willi;M?llerweg 77;99999;M?llhausen")
Kollation latin1_german2_ci (Text wird NICHT abgeschnitten aber "M?ller;Willi;M?llerweg 77;99999;M?llhausen")

Kollation regelt ja eigentlich die Sortierreihenfolge, aber mit den letzten vier Varianten bekomme ich schon mal den ganzen Text eines Feldes rein. Wie muss ich phpMyAdmin einstellen damit nun auch die Umlaute richtig dargestellt werden?
Vielen Dank für die Hilfe
mfg Julia
 
Moin Julia,

du müsstest schon genau wissen, wie diese Datei codiert ist, und das beim Import angeben, MySQL ist da recht pingelig :-)

Der WinLatin1-Zeichensatz(cp1252) steht zumindest in meiner PHPMyAdmin-Version jedoch nicht zur Auswahl
 
Also in meiner, phpMyAdmin - 2.9.1.1-Debian-9, MySQL-Client-Version: 5.0.32, Server Version: 5.0.32-Debian_7etch8-log steht cp1252 schon zur Verfügung

mfg Spikaner
 
hallo sven,

wie kann ich denn genau herausbekommen, welcher Zeichensatz in meiner CSV steckt?
Bisher habe ich es immer mittels eines Texteditors gemacht, beim Import in einem Texteditor kann man verschiedene Zeichensätze auswählen und man sieht auch gleich wie diese auf den Text wirken (siehe auch Excel-Import, OpenOffice und ähnliche).

Bei meiner aktuell CSV habe ich es so auch gemacht und festgestellt, das mit Windows-1252/WinLatin die Umlaute korrekt umgesetzt werden, aber wie gesagt - nur beim Texteditor.
Mit MySQL klappt das nicht. Nun kann es natürlich auch sein das latin1_general_ci aus der MySQL nicht das Gleiche wie Windows-1252/WinLatin des Texteditors ist.
Was kann ich machen?

Anbei eine Beispiel-Datei als CSV und eine SQL-Tabelle mit 7 Datensätzen wo Umlaute in Buchtiteln vorkommen.
 

Anhänge

Zuletzt bearbeitet:
OpenOffice sagt mir, dass es Windows-1252/WinLatin.

Da ich das bei meinem PHPMyAdmin wie erwähnt nicht verfügbar habe, habe ich beim Import mal Latin1 genommen, alles wird normal angezeigt...auch die Umlaute.
 
ich hatte dasselbe Problem und habe es so gelöst, dass ich in einem Texteditor (hier Notepad++) die csv-Datei mit Kodierung 'UTF-8 ohne BOM' abgespeichert habe. In MySQL collation als 'utf8_general_ci'. Danach klappte der Import (über phpmyadmin) problemlos.
 
ich hatte dasselbe Problem und habe es so gelöst, dass ich in einem Texteditor (hier Notepad++) die csv-Datei mit Kodierung 'UTF-8 ohne BOM' abgespeichert habe. In MySQL collation als 'utf8_general_ci'. Danach klappte der Import (über phpmyadmin) problemlos.

Das Thema ist gute drei Jahre "out of date".
 
Deine Lösung macht in deiner Situation vielleicht Sinn, allerdings macht sie keinen Sinn, wenn die CSV von einem anderen Programm automatisiert generiert wird (z.B. stündlich, als Protokoll) und dann per Cronjob importiert wird.
Dass man einfach die Kodierung mittels Editor ändern und dann importieren kann, war dem TE denke ich durchaus klar, aber nicht Ziel seiner Forschung.
 
Deine Lösung macht in deiner Situation vielleicht Sinn, allerdings macht sie keinen Sinn, wenn die CSV von einem anderen Programm automatisiert generiert wird (z.B. stündlich, als Protokoll) und dann per Cronjob importiert wird.
Dass man einfach die Kodierung mittels Editor ändern und dann importieren kann, war dem TE denke ich durchaus klar, aber nicht Ziel seiner Forschung.

Von automatisierter Generierung war nirgendwo die Rede, ganz im Gegenteil, meine Lösung hätte also vermutlich für den TE durchaus Sinn gemacht. Dass ihr (es ist eine sie, kein er) dies klar war, kann man durchaus bezweifeln.
 
Zurück