falsches charset beim dump-Import
falsches charset beim dump-Import
am 14.04.2006 14:51:38 von bibe2001
Hi,
ich habe von einem Freund ein MySQL-Dump bekommen, das er offenbar in
ISO-88591 erstellt hat.
# file -i dump.sql
dump.sql: text/plain; charset=iso-8859-1
Nun wollte ich dieses Dump über die Konsole in eine Datenbank importieren:
mysql -u -p db1 < dump.sql --default-character-set=latin1_de
Leider werden aber (korrekte) utf8-Einträge erzeugt. Wie kann ich mysql
dazu bringen, das charset nicht zu verändern und die Einträge in
ISO-88591 zu erstellen?
Mittlerweile habe ich auch versucht, den die Struktur erzeugenden Teil
des Dumps mittels "CHARACTER SET latin1;" beim Erstellen der Tabellen zu
ergänzen - leider auch ohne Erfolg.
Ich bin für jeden Tipp dankbar,
viele Grüße
Thomas
Re: falsches charset beim dump-Import
am 18.04.2006 09:32:03 von Christian Kirsch
Thomas Müller schrieb:
> Hi,
> ich habe von einem Freund ein MySQL-Dump bekommen, das er offenbar in
> ISO-88591 erstellt hat.
>
> # file -i dump.sql
> dump.sql: text/plain; charset=iso-8859-1
>
> Nun wollte ich dieses Dump über die Konsole in eine Datenbank importieren:
>
> mysql -u -p db1 < dump.sql --default-character-set=latin1_de
>
das könnte deshalb scheitern, weil mysql nichts nach dem '<' mehr zu
sehen bekommt - '<' ist ein Shell-Metacharacter.
Vielleicht wirst Du mit
mysql -u ... --default-character-set=latin1
glücklicher (latin1_de gibt es m.E. nicht - de gehört zur Collation,
nicht zum Characterset).
Außerdem ist dieses Thema in unzähligen Variationen hier behandelt
worden - Google weiß mehr dazu.
Wenn Dir nichts davon hilft, dann melde Dich bitte mit vollständigen
Informationen hier wieder (u.a. gehört dazu die verwendete MySQL-Version!)
Re: falsches charset beim dump-Import
am 19.04.2006 09:15:03 von bibe2001
Hi!
Christian Kirsch wrote:
> Thomas Müller schrieb:
>
>>ich habe von einem Freund ein MySQL-Dump bekommen, das er offenbar in
>>ISO-88591 erstellt hat.
>>
>># file -i dump.sql
>>dump.sql: text/plain; charset=iso-8859-1
>>
>>Nun wollte ich dieses Dump über die Konsole in eine Datenbank importieren:
>>
>>mysql -u -p db1 < dump.sql --default-character-set=latin1_de
>>
> das könnte deshalb scheitern, weil mysql nichts nach dem '<' mehr zu
> sehen bekommt - '<' ist ein Shell-Metacharacter.
>
> Vielleicht wirst Du mit
>
> mysql -u ... --default-character-set=latin1
Leider ändert das auch nichts, das Ergebnis ist nach wie vor das selbe.
Hier noch einige Infos:
Ich importiere ein phpBB-dump in eine etwas betagte 4.0.24 (Debian
stable) MySQL-Datenbank. Es wurde via phpMyAdmin erstellt, von welcher
Version die Quelldatenbank ist, kann ich leider nicht sagen, vermutlich
aber sehr viel höher als die der Ziel-DB.
Nun ist mir aber noch ein anderer Gedanke gekommen: Ich habe behauptet,
dass das dump als utf-8 in die DB eingefügt wurde, weil im phpMyAdmin
der Ziel-DB nur dann die Umlaute bestimmter Testbeiträge korrekt
dargestellt wurden, wenn ich meinen Browser auf utf8 umstellte.
Was passiert denn, wenn verschiedene User das Forum auf der
Quelldatenbank mit unterschiedlichen charsets besucht haben und Beiträge
geschrieben haben? Kann es dann sein, dass trotz standard ISO8859,
verschieden charsets in der Datenbank landen und meine Testbeiträge nur
zufällig alle mit utf8 verfasst wurden?
Somit könnte also ein ISO8859 dump mit unterschiedlich kodierten Zeichen
vorliegen, oder übersehe ich hier etwas?
Vielen Dank, viele Grüße
Thomas
Re: falsches charset beim dump-Import
am 20.04.2006 13:51:44 von Christian Kirsch
Thomas Müller schrieb:
> Hi!
>
> Christian Kirsch wrote:
>> Thomas Müller schrieb:
>>
>>> ich habe von einem Freund ein MySQL-Dump bekommen, das er offenbar in
>>> ISO-88591 erstellt hat.
>>>
>>> # file -i dump.sql
>>> dump.sql: text/plain; charset=iso-8859-1
>>>
>>> Nun wollte ich dieses Dump über die Konsole in eine Datenbank importieren:
>>>
>>> mysql -u -p db1 < dump.sql --default-character-set=latin1_de
>>>
>> das könnte deshalb scheitern, weil mysql nichts nach dem '<' mehr zu
>> sehen bekommt - '<' ist ein Shell-Metacharacter.
>>
>> Vielleicht wirst Du mit
>>
>> mysql -u ... --default-character-set=latin1
>
> Leider ändert das auch nichts, das Ergebnis ist nach wie vor das selbe.
> Hier noch einige Infos:
>
> Ich importiere ein phpBB-dump in eine etwas betagte 4.0.24 (Debian
> stable) MySQL-Datenbank. Es wurde via phpMyAdmin erstellt,
Bitte benutze die von MySQL bereitgestellten Werkzeuge dafür, in
diesem Fall mysqldump. Dafür gibt es eine Dokumentation und diverse
Optionen, die z.B. den Export in einem Mysql-4.0-kompatiblen Format
erlauben.
Mit PHPMyAdmin möchte sich aus guten Gründen hier in der Regel niemand
befassen.
Re: falsches charset beim dump-Import
am 20.04.2006 16:45:02 von bibe2001
Hi!
>>Ich importiere ein phpBB-dump in eine etwas betagte 4.0.24 (Debian
>>stable) MySQL-Datenbank. Es wurde via phpMyAdmin erstellt,
>
> Bitte benutze die von MySQL bereitgestellten Werkzeuge dafür, in
> diesem Fall mysqldump. Dafür gibt es eine Dokumentation und diverse
> Optionen, die z.B. den Export in einem Mysql-4.0-kompatiblen Format
> erlauben.
>
> Mit PHPMyAdmin möchte sich aus guten Gründen hier in der Regel niemand
> befassen.
Leider erlaubt meine Quelle für das Dump keinen Zugriff auf die Shell.
Ich kann auf die Datenbank nur via PHP zugreifen und nutze als interface
dafür phpMyadmin. Wie sollte ich das, deiner Ansicht nach, unter diesen
Umständen denn geschickter exportieren?
PHP-Funktionen wie "shell_exec()" oder "exec()" sind übrigens auf dem
Quellsystem im "disable_functions"-String der PHP-Konfiguration gelistet.
Viele Grüße
Thomas
Re: falsches charset beim dump-Import
am 20.04.2006 17:05:43 von Christian Kirsch
Thomas Müller schrieb:
> Hi!
>
>>> Ich importiere ein phpBB-dump in eine etwas betagte 4.0.24 (Debian
>>> stable) MySQL-Datenbank. Es wurde via phpMyAdmin erstellt,
>> Bitte benutze die von MySQL bereitgestellten Werkzeuge dafür, in
>> diesem Fall mysqldump. Dafür gibt es eine Dokumentation und diverse
>> Optionen, die z.B. den Export in einem Mysql-4.0-kompatiblen Format
>> erlauben.
>>
>> Mit PHPMyAdmin möchte sich aus guten Gründen hier in der Regel niemand
>> befassen.
>
> Leider erlaubt meine Quelle für das Dump keinen Zugriff auf die Shell.
> Ich kann auf die Datenbank nur via PHP zugreifen und nutze als interface
> dafür phpMyadmin. Wie sollte ich das, deiner Ansicht nach, unter diesen
> Umständen denn geschickter exportieren?
>
Keine Ahnung. Ich verstehe wirklich nicht, warum man ein leidlich
professionelles System wie MySQL mit so einem Kröpelkram wie dem
erwähnten Produkt administrieren will.
Das Hoster-Argument ist mir bekannt. Es gibt mW Anbieter, die
SSH-Zugänge bereitstellen. Allerdings muss man bei denen vielleicht
tiefer in die Tasche greifen. Geiz ist eben nicht immer und überall geil.
Konstruktiver: Wenn Du Deinen Dump irgendwie auf einen lokalen Rechner
bekommst, dann guck' ihn (den Dump) Dir dort an. Mit 'angucken' meine
ich jetzt nicht PHPirgendwas, sondern more, vi oder ein Editor Deiner
Wahl im Terminal, und zwar am besten in einem latin1-Locale:
export LANG=de_DE.iso8859-1; more dump.sql
oder
export LANG=de_DE@euro; more dump.sql
Wie das Locale genau heißt, hängt von Deinem System ab.
Wenn die Umlaute dann ok sind, hast Du einen Latin-1-Dump. Wenn für
jeden Umlaut zwei Zeichen dastehen, von denen das erste ein A mit
irgendeinem diakritischen Zeichen drüber ist (Ã z.B.), dann hast Du
einen UTF-8-Dump. Im ersten Fall sollte eigentlich alles OK sein für
ein 4.0er-MySQL. Im zweiten kannst Du iconv oder verwandte Werkzeuge
benutzen, um aus dem UTF-8-Kram Latin-1 zu machen.
Alles andere (Darstellung in PHPMyAdmin oder in einem Browser) ist
kein MySQL-Thema mehr.
Re: falsches charset beim dump-Import
am 21.04.2006 13:29:31 von bibe2001
Hi!
>>>>Ich importiere ein phpBB-dump in eine etwas betagte 4.0.24 (Debian
>>>>stable) MySQL-Datenbank. Es wurde via phpMyAdmin erstellt,
>>>
>>>Bitte benutze die von MySQL bereitgestellten Werkzeuge dafür, in
>>>diesem Fall mysqldump. Dafür gibt es eine Dokumentation und diverse
>>>Optionen, die z.B. den Export in einem Mysql-4.0-kompatiblen Format
>>>erlauben.
>>>
>>>Mit PHPMyAdmin möchte sich aus guten Gründen hier in der Regel niemand
>>>befassen.
>>
>>Leider erlaubt meine Quelle für das Dump keinen Zugriff auf die Shell.
>>Ich kann auf die Datenbank nur via PHP zugreifen und nutze als interface
>>dafür phpMyadmin. Wie sollte ich das, deiner Ansicht nach, unter diesen
>>Umständen denn geschickter exportieren?
>
> [..]
Ich betreibe einen öffentlichen (Web-)Server und selbstverständlich habe
ich auf diesem Apparat vollen root-Zugriff. Es geht hier um das
MySQL-Dump eines Freundes, der seine Domain zu mir umziehen will und
dessen momentaner Provider leider keinen Shell-Zugang anbietet. Er hat
eben lediglich die Möglichkeit, das Dump per PHP zu erstellen.
> Konstruktiver:
*puh* Ich dachte schon, das ginge so weiter... ;)
> Wenn Du Deinen Dump irgendwie auf einen lokalen Rechner
> bekommst, dann guck' ihn (den Dump) Dir dort an. Mit 'angucken' meine
> ich jetzt nicht PHPirgendwas, sondern more, vi oder ein Editor Deiner
> Wahl im Terminal, und zwar am besten in einem latin1-Locale:
> export LANG=de_DE.iso8859-1; more dump.sql
> oder
> export LANG=de_DE@euro; more dump.sql
Das habe ich so ähnlich auf meinem System bereits getan. vim kann man
das charset direkt vorgeben, mit dem er die Datei enkodieren soll. Hier
habe ich interessanterweise sowohl korrekte Umlaute (vermutlich in
ISO8859-1 gespeichert), als auch falsche (vermutlich utf-8).
Mittlerweile läuft auch ein phpBB mit den Daten des Dumps. Hier werden
in der HTML-Ausgabe (header auf ISO8859-1 definiert) ebenfalls sowohl
korrekte, als auch falsche Umlaute angezeigt. Übrigens ist das in der
Quelle bei seinem alten Provider genauso.
Ich nehmen also an, dass verschiedene User mit verschiedenen charsets
ihre Posts erstellt haben und das charset beim Speichern in die
Datenbank nicht geprüft und ggf. konvertiert wurde.
Alle falsch kodierten Umlaute umzukodieren und nur die richten zu
erhalten, dürfte automatisiert aber so gut wie unmöglich sein oder sieht
du hier eine Chance?
> Alles andere (Darstellung in PHPMyAdmin oder in einem Browser) ist
> kein MySQL-Thema mehr.
Naja, es weist aber auf genau das hin, was ich oben beschrieben hab'. ;)
Viele Grüße
Thomas