Tanelorn.net

Medien & Phantastik => Multimedia => Multimedia - Software & Betriebsysteme => Thema gestartet von: Ein am 18.06.2008 | 09:49

Titel: Umlaut etc. beim Import in MySQL zerschossen
Beitrag von: Ein am 18.06.2008 | 09:49
Ich habe einen Dump von einem Webserver, hier lokal in meinen XAMPP/MySQL importiert. Dabei hat er mir die Daten zerschossen, alle Umlaute, Kanji etc. werden nicht richtig angezeigt. Die Ursprungstabellen waren in UTF-8 und die jetztigen sind es daher natürlich auch. Zumindest zeigt mir das PHPmyAdmin das so an.

Gibt es irgendeine Möglichkeit diesen Schlamassel zu reparieren?
Titel: Re: Umlaut etc. beim Import in MySQL zerschossen
Beitrag von: der.hobbit am 18.06.2008 | 10:54
Welches Zeichenformat hat die Dump-Datei? Evtl. wurde das irgendwann zwischendurch eine Latin-1 Kodierung? Die meisten Editoren können das Encoding von Dateien anzeigen / anpassen.
Titel: Re: Umlaut etc. beim Import in MySQL zerschossen
Beitrag von: Ein am 18.06.2008 | 11:28
UTF-8. Sowohl vor, als auch nach dem Entpacken. Im Editor kann ich die Characters im Unicode-Bereich auch lesen. Sobald ich das ganze Importiere ist es hinüber.

Muss ich evtl. irgendetwas an meinem MySQL-Server ändern? Er sagt default-character-set latin1.

Wenn ja, wie?
Titel: Re: Umlaut etc. beim Import in MySQL zerschossen
Beitrag von: Ein am 18.06.2008 | 11:47
So ich habe in der my.cnf
character-set-server = utf8
collation-server = utf8_unicode_ci
gesetzt.
Juckt ihn aber nicht. Immer noch latin1.
Titel: Re: Umlaut etc. beim Import in MySQL zerschossen
Beitrag von: der.hobbit am 18.06.2008 | 12:28
Probier mal die direktive default-character-set=utf8 in der my.ini zu setzen. my.cnf kenne ich nicht, aber vermutlich reden wir vom Gleichen.

Hmm, du kannst auch in der Datenbank information_schema schauen, ob UTF-8 für diese DB überhaupt zur Verfügung steht (Tabelle CHARACTER_SETS). Wenn nicht würde mich das zwar sehr wundern, aber teufel und eichhörnchen.... Welche collations stehen für UTF-8 zur Verfügung (SHOW COLLATION)?

Legt dein Dump die Datenbank neu an, oder nutzt er eine existierende Datenbank? Stehen im Dump vielleicht Information zum zu verwendenden Zeichensatz? Welchen Zeichensatz hat die Zieldatenbank, falls sie im System schon existiert?
Titel: Re: Umlaut etc. beim Import in MySQL zerschossen
Beitrag von: Ein am 18.06.2008 | 12:38
UTF8 ist drin. Auch entsprechende Collations, mehr als ich bräuchte.

Die Datenbank lege ich selbst mit CREATE DATABASE an, der Dump enthält nur die INSERTs. Alle brav mit CHARACTER SET utf8.

Ich habe Datenbank jetzt noch einmal explizit mit CREATE DATABASE bla CHARACTER SET utf8 angelegt, bevor ich den Dump eingespielt habe. Fehler bleibt.  :P
Titel: Re: Umlaut etc. beim Import in MySQL zerschossen
Beitrag von: der.hobbit am 18.06.2008 | 13:03
Vielleicht wäre es langsam einfacher, die Quelldatei nach latin-1 zu konvertieren und dann zu importieren. Falls du sie auf UTF-8 brauchst, könntest du sie erst in eine Temp DB importieren und danach mit SQL-Kommandos kopieren. Keine Ahnung ob das besser funktioniert...

mysqldump hat auch einige options, evtl. kann man dabei das character-set auch explizit definieren. Dann bräuchtest du aber einen neuen Export.
Titel: Re: Umlaut etc. beim Import in MySQL zerschossen
Beitrag von: Ein am 18.06.2008 | 16:42
Das Problem dabei ist, dass da Japanisch mit drin ist. So ein Mist!
Titel: Re: Umlaut etc. beim Import in MySQL zerschossen
Beitrag von: Ein am 18.06.2008 | 16:56
Dumme Windows-Konsole.
Das Shell nutzt standardmäßig auch unter XP Codepage 850 und zerschießt damit den Dump, den ich per mysql bla < dump.sql übergeben habe.

Ein einfaches chcp 1252 und es klappt. Und da soll einer drauf kommen.

:gaga:
Titel: Re: Umlaut etc. beim Import in MySQL zerschossen
Beitrag von: Ein am 18.06.2008 | 17:04
Zu früh gefreut. Anscheinend. Ach erstmal essen.
Titel: Re: Umlaut etc. beim Import in MySQL zerschossen
Beitrag von: Thalamus Grondak am 18.06.2008 | 17:08
Welche Mysql versionen jeweils?
Titel: Re: Umlaut etc. beim Import in MySQL zerschossen
Beitrag von: Ein am 18.06.2008 | 17:17
Ah, geht doch. Musste nur den Cache in der Anwendung löschen.

Juhu.

Dummer Fehler. :P