Eine Frage zu mysqldump Daten ...

Liebe Alle,


ich habe einen mysql Dumpfile "geerbt", dessen erste Zeilen so
aussehen:

-- MySQL dump 10.9
--
-- Host: localhost Database: xxxxx
-- ------------------------------------------------------
-- Server version 4.1.11-Debian_4sarge2-log

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;


Die Tabellendefinitionen verwenden alle latin1 als charset:

CREATE TABLE `tt_content` (

.....

) ENGINE=MyISAM DEFAULT CHARSET=latin1;


In einigen Tabellen gibt es diverse (deutsche, cyrillische, türkische)
Zeichen, die mit 4 Bytes Länge codiert sind. Ein Umlaut a wird mit Hex

0xC3 0x83 0xC2 0xA4

kodiert, ein Umlaut o mit Hex

0xC3 0x83 0xC2 0xB6

Das erste und das letzte Byte der Vierersequenz entsprechen also
zusammengenommen der UTF-8 Kodierung der Umlaute, aber woher kommen
die mittleren beiden Bytes? Ist das eine Mysql-spezifische Kodierung?

Vielen Dank im voraus,


--

Joerg Lenneis

email: lenneis@wu-wien.ac.at

Re: Eine Frage zu mysqldump Daten ...

lenneis@wu-wien.ac.at wrote:

> Die Tabellendefinitionen verwenden alle latin1 als charset:
>
> CREATE TABLE `tt_content` (
>
> ....
>
> ) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Hm...


> In einigen Tabellen gibt es diverse (deutsche, cyrillische, türkische)
> Zeichen, die mit 4 Bytes Länge codiert sind. Ein Umlaut a wird mit Hex
>
> 0xC3 0x83 0xC2 0xA4
>
> kodiert, ein Umlaut o mit Hex
>
> 0xC3 0x83 0xC2 0xB6

Das sieht mir stark danach aus, als sei diese UTF8-Wandlung 2x erfolgt:

ein ä in latin1 ist e4

1x UTF8 -> c3 a4
das als latin1 behandelt und utf8gewandelt: -> c3 83 c2 a4


Ein Fehler ist schon mal, daß die Tabellen CHARSET=latin1 haben, jedoch
offenbar utf8-Daten beinhalten. Da wurde dann wohl beim Export nochmal
konvertiert...


Lösung: am besten importieren, CHARSET der Tabelle ändern, nochmal dumpen
-> müßte eigentlich dann stimmen.


Thomas

Re: Eine Frage zu mysqldump Daten ...

Thomas Rachel:

[...]

> Hm...


>> In einigen Tabellen gibt es diverse (deutsche, cyrillische, türkische)
>> Zeichen, die mit 4 Bytes Länge codiert sind. Ein Umlaut a wird mit Hex
>>
>> 0xC3 0x83 0xC2 0xA4
>>
>> kodiert, ein Umlaut o mit Hex
>>
>> 0xC3 0x83 0xC2 0xB6

> Das sieht mir stark danach aus, als sei diese UTF8-Wandlung 2x erfolgt:

> ein ä in latin1 ist e4

> 1x UTF8 -> c3 a4
> das als latin1 behandelt und utf8gewandelt: -> c3 83 c2 a4

Vielen Dank, Thomas, das dürfte es sein. Ich habe es jetzt für ä und ö
nachgerechnet.

> Ein Fehler ist schon mal, daß die Tabellen CHARSET=latin1 haben, jedoch
> offenbar utf8-Daten beinhalten. Da wurde dann wohl beim Export nochmal
> konvertiert...


> Lösung: am besten importieren, CHARSET der Tabelle ändern, nochmal dumpen
-> müßte eigentlich dann stimmen.

Nur zum Verständis: Meinst zu 1x importieren mit charset utf8, dann
dump mit charset latin1, damit wird ein "Level" von utf8 Codierung
entfernt?


> Thomas

--

Joerg Lenneis

email: lenneis@wu-wien.ac.at

Re: Eine Frage zu mysqldump Daten ...

lenneis@wu-wien.ac.at wrote:

>> Ein Fehler ist schon mal, daß die Tabellen CHARSET=latin1 haben, jedoch
>> offenbar utf8-Daten beinhalten. Da wurde dann wohl beim Export nochmal
>> konvertiert...
>
>> Lösung: am besten importieren, CHARSET der Tabelle ändern, nochmal dumpen
> -> müßte eigentlich dann stimmen.
>
> Nur zum Verständis: Meinst zu 1x importieren mit charset utf8, dann
> dump mit charset latin1, damit wird ein "Level" von utf8 Codierung
> entfernt?

Genau. Nur - bei diesem neuen Dump sind die Tabellen immer noch mit latin1
markiert, und vermutlich steht auch ein /*!40101 SET NAMES latin1 */; oder
so was drin, obwohl die Daten untendrunter utf8 sind. Aber das liegt am
falschen ursprünglichen Format der Datenbank.

Nach dem Importieren solltest Du mit ALTER TABLE DEFAULT
CHARSET=latin1 die Charset-Deklaration der Tabelle ändern.

Ein darauffolgendes Dumpen sollte dann konsistente Daten produzieren - wobei
es unerheblich sein sollte, welches Charset für den Export angegeben wird.


Thomas
--
Macs sind für die, die nicht wissen wollen, warum ihr Rechner funktioniert.
Linux ist für die, die wissen wollen, warum er funktioniert.
DOS ist für die, die wissen wollen, warum er nicht funktioniert, und
Windows ist für die, die nicht wissen wollen, warum er nicht funktioniert.

Re: Eine Frage zu mysqldump Daten ...

Thomas Rachel:

> lenneis@wu-wien.ac.at wrote:

[...]

> Genau. Nur - bei diesem neuen Dump sind die Tabellen immer noch mit latin1
> markiert, und vermutlich steht auch ein /*!40101 SET NAMES latin1 */; oder
> so was drin, obwohl die Daten untendrunter utf8 sind. Aber das liegt am
> falschen ursprünglichen Format der Datenbank.

> Nach dem Importieren solltest Du mit ALTER TABLE DEFAULT
> CHARSET=latin1 die Charset-Deklaration der Tabelle ändern.

> Ein darauffolgendes Dumpen sollte dann konsistente Daten produzieren - wobei
> es unerheblich sein sollte, welches Charset für den Export angegeben wird.

[...]

Danke nochmals. Was ich auch noch probieren werde (weil ich das Tool
noch nicht kenne und das sowieso auch einmal fällig ist) ist, den dump
direkt mit recode auf latin1 zurückzukodieren und die Deklarationen
bei den Tabellen auf UTF8 abzuändern. Das sollte eigentlich auch
gehen, weil das Mapping ja eigentlich 1<->1 reversibel sein sollte.

lg,

--

Joerg Lenneis

email: lenneis@wu-wien.ac.at

Re: Eine Frage zu mysqldump Daten ...

lenneis@wu-wien.ac.at wrote:
>
> ich habe einen mysql Dumpfile "geerbt", dessen erste Zeilen so
> aussehen:
>
> -- MySQL dump 10.9
[snip]
> /*!40101 SET NAMES utf8 */;

Der Dump enthält alle Daten in UTF-8 Codierung. Die Daten werden aus
dem in der Datenbank spezifizierten Encoding (also bei dir latin1)
explizit nach UTF-8 umgewandelt.

Frühere Versionen von mysqldump schreiben kein SET NAMES Statement
in das dumpfile und exportieren alle Daten, wie sie sind.

> Die Tabellendefinitionen verwenden alle latin1 als charset:
>
> CREATE TABLE `tt_content` (
....
> ) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Aber anscheinend stimmen die enthaltenen Daten nicht zur Deklaration
sondern sind UTF-8 codiert. Beheben kannst du das durch die korrekte
Deklaration der Daten in der Datenbank. Dazu importierst du einfach
den Dump und folgst dann der Anleitung hier:

http://dev.mysql.com/doc/refman/4.1/en/charset-conversion.ht ml


XL

Re: Eine Frage zu mysqldump Daten ...

Axel Schwenke:

> lenneis@wu-wien.ac.at wrote:
>>
>> ich habe einen mysql Dumpfile "geerbt", dessen erste Zeilen so
>> aussehen:
>>
>> -- MySQL dump 10.9
> [snip]
>> /*!40101 SET NAMES utf8 */;

> Der Dump enthält alle Daten in UTF-8 Codierung. Die Daten werden aus
> dem in der Datenbank spezifizierten Encoding (also bei dir latin1)
> explizit nach UTF-8 umgewandelt.

> Frühere Versionen von mysqldump schreiben kein SET NAMES Statement
> in das dumpfile und exportieren alle Daten, wie sie sind.

>> Die Tabellendefinitionen verwenden alle latin1 als charset:
>>
>> CREATE TABLE `tt_content` (
> ...
>> ) ENGINE=MyISAM DEFAULT CHARSET=latin1;

> Aber anscheinend stimmen die enthaltenen Daten nicht zur Deklaration
> sondern sind UTF-8 codiert. Beheben kannst du das durch die korrekte
> Deklaration der Daten in der Datenbank. Dazu importierst du einfach
> den Dump und folgst dann der Anleitung hier:

> http://dev.mysql.com/doc/refman/4.1/en/charset-conversion.ht ml

Danke Axel. Nachdem die Ursache klar war, habe ich es so ähnlich
gemacht. Ein Punkt, der noch dazukam: Es gab in dem Dump noch zwei
Chars, die überhaupt ungültig codiert waren (also nicht nur UTF
"verdoppelt"). Für die war dann noch ein kleines Script
notwendig. Keine Ahnung, wie das passiert ist ...

lg,

--

Joerg Lenneis

email: lenneis@wu-wien.ac.at