Umlautproblem:Charset beim Dump einspielen angeben?

Hallo allerseits,

ich eine MysqlDB von meinem Rechner (V 4.1.13) auf den Host meines Providers
(angeblich V 4.0.24 aber --version sagt 3.22.29) spielen. Leider gibt es
immer Probleme mit Umlauten und Sonderzeichen die nicht richtig übernommen
werden (sprich als Schmutzzeichen in der DB landen).

zum Export verwende ich
mysqldump --default-character-set latin1

Ohne die Angabe des Charsets sind die Umlaute bereits im dump file kaputt.

Der Import mit
mysql < dumpfile schlägt erstmal fehl, da die Option "DEFAULT
CHARSET=latin1" im create table Statement by 4.0.x wohl nicht gültig ist.
Nach löschen der Option (sed sei Dank ;-)) klappt zwar der Import aber die
Umlaute sind dann halt hin.

Ich hab auch keine Option gefunden mit der man beim Import ein Charset
angeben kann.

Weiß jemand wie ich das Problem lösen kann?

Vielen Dank

Gruss
Rico

Re: Umlautproblem:Charset beim Dump einspielen angeben?

Rico Speer schrieb:
> Hallo allerseits,
>
> ich eine MysqlDB von meinem Rechner (V 4.1.13) auf den Host meines Providers
> (angeblich V 4.0.24 aber --version sagt 3.22.29) spielen. Leider gibt es
> immer Probleme mit Umlauten und Sonderzeichen die nicht richtig übernommen
> werden (sprich als Schmutzzeichen in der DB landen).
>
> zum Export verwende ich
> mysqldump --default-character-set latin1
>
> Ohne die Angabe des Charsets sind die Umlaute bereits im dump file kaputt.
>
> Der Import mit
> mysql < dumpfile schlägt erstmal fehl, da die Option "DEFAULT
> CHARSET=latin1" im create table Statement by 4.0.x wohl nicht gültig ist.
> Nach löschen der Option (sed sei Dank ;-)) klappt zwar der Import aber die
> Umlaute sind dann halt hin.
>
> Ich hab auch keine Option gefunden mit der man beim Import ein Charset
> angeben kann.
>
> Weiß jemand wie ich das Problem lösen kann?
>
Du kannst beim dump angeben, dass mysqldump den Dump kompatible zu 3.23
erstellen soll. Mach mal mysqldump --help und suche nach compatible oder
ähnlich.


Grüße


Dirk

Re: Umlautproblem:Charset beim Dump einspielen angeben?

Hi,
ich hatte in einem der weiter unten aufgeführten Beiträge ganz ähnliche
Probleme.

Meines Wissens dumpt 4.1 als utf8 in das Dumpfile (auch latin1-Zeichen),
nur schreibt es dann pro Tabelle das korrekte charset dazu, was 4.0
nicht versteht. 4.0 erwartet das Dump als latin1.

Versuche doch 'mal folgendes:
Erstelle den Dump aus deiner 4.1 ohne irgendwelche
charset-Informationen. Dann dürfte `file -i` darüber informieren, dass
das Dump als utf8 vorliegt.
Nun konvertierst du das Dumpfile mit
`iconv -f utf8 -t latin1 dumpfile -o dumpfile-latin1`
und versuchst, dumpfile-latin1 in deine 4.0er zu importieren.

Mich würde sehr interessieren, ob das klappt.

Viele Grüße
Thomas

Re: Umlautproblem:Charset beim Dump einspielen angeben?

Dirk Brosowski wrote:

> Du kannst beim dump angeben, dass mysqldump den Dump kompatible zu 3.23
> erstellen soll. Mach mal mysqldump --help und suche nach compatible oder
> ähnlich.
>

Danke für den Tipp....hab das Problem mittlerweile gelöst...lag an
unterschiedlichen charsets des filesystems....hatte ich übersehen.

Gruss
Rico

Re: Umlautproblem:Charset beim Dump einspielen angeben?

Thomas Müller wrote:


> Nun konvertierst du das Dumpfile mit
> `iconv -f utf8 -t latin1 dumpfile -o dumpfile-latin1`
> und versuchst, dumpfile-latin1 in deine 4.0er zu importieren.
>

Habe es inzwischen auch auf diesen Problem zurückführen können und bin
genauso wie verfahren wie o.a.. Jetzt klappt es prima.

Trotzdem danke für den Tip.

Gruss
Ricardo

Re: Umlautproblem:Charset beim Dump einspielen angeben?

Hi!

>>Nun konvertierst du das Dumpfile mit
>>`iconv -f utf8 -t latin1 dumpfile -o dumpfile-latin1`
>>und versuchst, dumpfile-latin1 in deine 4.0er zu importieren.
>
> Habe es inzwischen auch auf diesen Problem zurückführen können und bin
> genauso wie verfahren wie o.a.. Jetzt klappt es prima.
>
> Trotzdem danke für den Tip.

Leider habe ich nicht verstanden, mittels welchen Verfahrens du das
Problem gelöst hast. Meine charset-Umkodierung hat offenbat nicht geholfen?

Was hat denn --compatible gebracht?

Oben schreibst du von "unterschiedlichen charsets des filesystems", was
meinst du damit?

Mich interessieren die unterschiedlichen Lösungsvefahren für das Problem
weiterhin sehr und ich bin für weiterführende Informationen dankbar.

Viele Grüße
Thomas

Re: Umlautproblem:Charset beim Dump einspielen angeben?

Thomas Müller wrote:

>> Trotzdem danke für den Tip.
>
> Leider habe ich nicht verstanden, mittels welchen Verfahrens du das
> Problem gelöst hast. Meine charset-Umkodierung hat offenbat nicht
> geholfen?

Doch doch...die Umkodierung hat es gebracht. Sorry falls ich mich da etwas
undeutlich ausgedrückt habe.
Ich gehe im Moment wie folgt vor:

Rahmenbedingung
Die Quell- bzw Zieltabellen in haben das Charset ISO 8859-1 eingestellt.
Filesystem (hat dem Filesystem ansich glaub ich nix zu tun ist einfach das
default CharSet) auf der QuellRechner arbeitet mit UTF-8 auf dem
ZielRechner mit ISO8859-1.

Export
user@quelle:mysqldump --default-character-set=latin1 DB > dumpfile

Das erzeugt mir ein file im UTF-8 Format. Denke, daß liegt am CharSet des
Systems und nicht an mysqldump. Das --default-character-set ist nötig da
sonst das konvertieren mit iconv mit Fehler "ungültige Eingabe-Sequenz an
der Stelle 1017" abbricht.

Konvertieren
user@quelle:iconv -f utf8 -t ISO-8859-1 dumpfile dumfile_iso
Damit hab ich jetzt eine file im ISO8859-1 Format.

Jetzt dumfile_iso packen und auf den Zielrechner schieben und wieder
entpacken. (bei mir mit gzip und sftp)

Import
Ich muß jetzt erstmal die charset option die im CREATE TABLE Statement des
dumpfiles steht eliminieren, da die ZielDB-Version das nicht kennt und als
Syntax Error ablehnt. Also wird

CREATE TABLE `test` (
`test` varchar(150) NOT NULL default ''
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

zu

CREATE TABLE `test` (
`test` varchar(150) NOT NULL default ''
) ENGINE=MyISAM;

dann importieren mit

mysql DB < dumfile_iso

und fertig ist es.

> Was hat denn --compatible gebracht?

Tja...so eine Option habe ich leider nicht gefunden..

Viele Grüsse
Rico

Re: Umlautproblem:Charset beim Dump einspielen angeben?

Hi!

>>Meine charset-Umkodierung hat offenbat nicht geholfen?
>
> Doch doch...die Umkodierung hat es gebracht.

Ah, freut mich.

> Export
> user@quelle:mysqldump --default-character-set=latin1 DB > dumpfile

Soll das
"mysqldump --default-character-set=utf8 DB > dumpfile"
heißen? Sonst wäre mir unklar, wieso eine Datei als utf8 rauskommt.

> Das erzeugt mir ein file im UTF-8 Format. Denke, daß liegt am CharSet des
> Systems und nicht an mysqldump. Das --default-character-set ist nötig da
> sonst das konvertieren mit iconv mit Fehler "ungültige Eingabe-Sequenz an
> der Stelle 1017" abbricht.
>
> Konvertieren
> user@quelle:iconv -f utf8 -t ISO-8859-1 dumpfile dumfile_iso
> Damit hab ich jetzt eine file im ISO8859-1 Format.

Viele Grüße
Thomas

Re: Umlautproblem:Charset beim Dump einspielen angeben?

Thomas Müller wrote:


>> Export
>> user@quelle:mysqldump --default-character-set=latin1 DB > dumpfile
>
> Soll das
> "mysqldump --default-character-set=utf8 DB > dumpfile"
> heißen? Sonst wäre mir unklar, wieso eine Datei als utf8 rauskommt.

Nein..es heißt "latin1". Und zumindest das file-command ist der Meinung das
das dumpfile in UTF-8 vorliegt. Ich glaube es entsteht durch das ">", was
ja eine shell-Operation ist und die shell arbeitet bei mir mit UTF-8. Jedes
textfile das ich anlege "echo test > xxx" wird auch in UTF-8 angelegt.


Gruss
Rico

Re: Umlautproblem:Charset beim Dump einspielen angeben?

Rico Speer wrote:
>>
>> Soll das
>> "mysqldump --default-character-set=utf8 DB > dumpfile"
>> heißen? Sonst wäre mir unklar, wieso eine Datei als utf8 rauskommt.
>
> Nein..es heißt "latin1". Und zumindest das file-command ist der Meinung das
> das dumpfile in UTF-8 vorliegt. Ich glaube es entsteht durch das ">", was
> ja eine shell-Operation ist und die shell arbeitet bei mir mit UTF-8. Jedes
> textfile das ich anlege "echo test > xxx" wird auch in UTF-8 angelegt.

Du glaubst falsch. "Die Shell" "arbeitet" nicht mit utf8. Die Shell
stellt standardisierte Umgebungsvariablen a'la $LANG und $LC_* bereit
und diese enthalten die Einstellungen für character encoding, sort
order etc.

Aus der Shell gestartete Applikationen *können* diese Einstellung
beachten (typischerweise tun sie das, aber manche sind halt kaputt
oder auch nur noch nicht uft8-ready).

Wenn du also Ausgaben von Programmen per '>' in ein File umleitest,
kommt es auf das Programm an, was das für ein Encoding verwendet. Für
Eingaben (vulgo: Tasten die du drückst) ist die verwendete Terminal-
Emulation (xterm, kterm, etc.) verantwortlich. Dito für die Inter-
pretation von Ausgaben aus Programmen auf den Bildschirm.

Ein weiterer Punkt ist, daß Textfiles typischerweise *keine*
Deklaration des verwendeten Encodings enthalten, ganz im Gegensatz
zu z.B. XML Files. Wenn Programme wie 'file' oder ein Editor versuchen
das Encoding eines Textfiles zu ermitteln, sind sie darauf angewiesen
zu raten. Wenn ein Textfile Codes mit Werten von 128-255 nur innerhalb
gültiger utf8-Sequenzen enthält, ist es relativ wahrscheinlich, daß
es tatsächlich utf8 ist - absolute Sicherheit gibt es dafür nicht!


Zurück zu mysqldump: mit MySQL 4.1 oder höher, ist die beste Variante,
den mysqldump-Default utf8 zu nutzen. Denn nur utf8 kann *alle* Zeichen
aus *allen* erlaubten Encodings darstellen. Selbst wenn eine Datenbank
ausschließlich latin1-Daten enthält, ist utf8 die bessere Wahl, weil
MySQL auch für Bezeichner (Datenbanken, Tabellen, Spalten) intern utf8
verwendet. Wenn z.B. ein Spaltenname einen Umlaut enhält, kommt der in
einem Dump mit erzwungenem latin1-Encoding kaputt raus.


HTH, XL