Datenbanken unterschiedliche Zeichensätze

[warhammer73]

Hallo,

ich bin gerade dabei ein Forum auf einen anderen Webserver umzuziehen. Probleme macht dabei die Zeichencodierung in mysql.
In der Quelldatenbank steht z.B. H?fe (wenn ich ein select mache) in der Zieldatenbank korrekt Höfe.
Soweit, so gut.

Leider ists im Forum genau andersherum.
Da steht im Quellforum richtig Höfe, im Zielforum irgendwelcher Sonderzeichenmüll.

Wie bekomme ich das wieder geradegezogen?

Danke!


P.S. Da auf dem Zielsystem auch andere Datenbanken im mysql laufen wäre eine Anpassung der globalen mysql Einstellungen so ziemlich das Schlechteste.

[Mahony]

Hallo
Lies mal hier Die Umlautproblematik. Da wird dir alles wichtige zum Thema erklärt.


Grüße: Mahony

[warhammer73]

Theoretisch ist mir das schon klar.

Die Frage ist nur wie ich praktisch mein Problem gelöst bekomme. Extra deswegen mysqldumper zu installieren sehe ich nicht als Möglichkeit.

Was ich nicht verstehe:
Das sqldump erzeugt Statements wie:
CREATE TABLE `phpbb3_acl_groups` (
`group_id` mediumint(8) unsigned NOT NULL default '0',
`forum_id` mediumint(8) unsigned NOT NULL default '0',
`auth_option_id` mediumint(8) unsigned NOT NULL default '0',
`auth_role_id` mediumint(8) unsigned NOT NULL default '0',
`auth_setting` tinyint(2) NOT NULL default '0',
KEY `group_id` (`group_id`),
KEY `auth_opt_id` (`auth_option_id`),
KEY `auth_role_id` (`auth_role_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

-> Ok, Quelltabelle ist utf8.

Show table status auf der Ziel-DB (ist V5 deswegen geht das da, Quelle ist V4):
| phpbb3_acl_groups | MyISAM | 10 | Fixed | 301 | 14 | 4214 | 3940649673949183 | 13312 | 0 | NULL | 2010-01-29 05:31:29 | 2010-01-29 05:31:29 | 2010-01-29 05:31:30 | latin1_swedish_ci | NULL | | |

-> Wo hier ein latin1_swedish_ci herkommt verstehe ich überhaupt nicht. Lt. create Statement sollte da utf8_bin drinstehen...

Lt. status verwendet die Ziel-DB als characterset latin1.


... wenn ich eine Tabelle doch aber explizit mit utf8 anlege, verstehe ich einfach nicht wieso die Tabelle dann doch wieder latin1 ist...

Was ich nicht weiss: Wie ich heraus bekomme was eigentlich der Zeichensatz der Quell-DB ist.

Ich habe versucht mit iconv die Zeichensätze zu konvertieren. Aber mit Parameter -f utf8 meldet iconv "illegale input sequence" -> Scheint also nicht utf8 codiert zu sein...

[warhammer73]

... über die Beantwortung meiner Fragen bzw. Aufklärung meines Nichtwissens wäre ich zwar immer noch dankbar, aber die Lösung ist eigentlich ganz einfach:
Bei dump erzeugen einfach angeben in welchen Zeichensatz er das erzeugen soll (In meinem Fall also latin1, da das Ziel mysql ja darauf eingestellt ist):

mysqldump --default_character_set=latin1

[bantu]

Nein, das ist nicht die korrekte Lösung des Problems. Dabei gehen nämlich Zeichen, die zwar in UTF8 sind aber nicht in latin1 sind, verloren. Unter Umständen hat dein Board aber garkeine derartigen Zeichen oder es ist dir nicht aufgefallen. In phpBB sind Beiträge prinzipiell UTF8, die Tabellen müssen also UTF8 sein.

In der Regel ist das Problem durch Ausführen des MySQL-Upgraders zu beheben. Siehe z.B. KB:no_default.

[warhammer73]

... die Tabellen sind ja auch UTF8, schliesslich werden sie ja per dump aus der alten Quelldatenbank exportiert. Ich hab ja auch kein Problem mit dem DB Schema (die beschriebenen Meldungen in dem Link bekomme ich auch gar nicht) sondern nur mit der Zeichendarstellung.
Ich verstehe einfach nicht wo das Problem herkommt, da würde mir vielleicht eine Lösung einfallen.

[Mahony]

Hallo

Ich verstehe einfach nicht wo das Problem herkommt, da würde mir vielleicht eine Lösung einfallen.

Hattest du dir den verlinkten Artikel auch genau durchgelesen? Da steht doch ganz genau beschrieben, wie so etwas zustande kommt.

Grob gesagt: Du musst die Tabellen in dem Zeichensatz einspielen, den die Datenbank erwartet..
Wichtig sind die Parameter character_set_client und character_set_connection.
Der SQL-Befehl zur Anzeige der benötigten Variablen lautet übrigens: SHOW VARIABLES
Um die Anzeige übersichtlicher zu halten würde aber auch ein

Code: Alles auswählen

SHOW VARIABLES LIKE 'character_set%';

genügen.

Was ich nicht weiss: Wie ich heraus bekomme was eigentlich der Zeichensatz der Quell-DB ist.

Wie gesagt - mit dem oben genannte SQL-Befehl kannst du dir den verwendeten Zeichensatz anzeigen lassen.

Hättest du das Backup mit dem Mysqldumper angefertigt und auch wieder mit dem Mysqldumper eingespielt, dann hättest du damit überhaupt keine Probleme gehabt. Der Mysqldumper macht das nämlich bereits automatisch richtig.


Grüße: Mahony

[warhammer73]

Ja, ich hab mir den Artikel durchgelesen.

Das Problem was ich nicht verstehe:

Die Tabellen sind in beiden Fällen utf8. Damit hätte ich eigentlich auch erwartet das ein export/import das selbe Ergebnis liefert. Jedenfalls kenne ich das bisher von anderen DBMS so.

Die Zeichensätze im mysql sehen auch gleich aus:
Quelle:
mysql> show variables like 'character_set%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
7 rows in set (0.00 sec)
Ziel:
mysql> show variables like 'character_set%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)

... also für mich sieht das alles gleich aus, nur das Ergebnis ist nicht das was ich erwartet hätte.