UTF8 Dump erzeugt nach import in UTF8 kod DB falsche Umlaute

[Forumsgast]

Halli Hallo,

für meinen ersten Thread habe ich eine Frage, die micht seit zwei Tagen belastet und ich verzweifle langsam daran.

Ich möchte ein Forum auf UTF8 umstellen.
Sprachfiles und Templates sind vorbereitet nun gehts noch um die Datenbank selbst.

Ich habe mit sämtlichen Tools (Notepad++, Ultraedit, Notepad2) gearbeitet und die Datei auf UTF8 umgestellt. Das ging eigentlich problemlos und es wird auch UNIX UTF-8 im Status (von Notepad++). Die Umlaute sind alles bereits geändert (Enities > unicode Umlaute) und eben alles in UTF8 kodiert.

Sobald ich diese Datei (auf Console und über DumpTimer) zurückspiele, werden die Umlaute falsch ausgegeben.

Ich habe zuvor die Datenbank über phpmyadmin auf UTF8 umgestellt und die Sql datei auch entsprechend angepasst

CREATE TABLE `*******` (
  `userid` int(11) unsigned NOT NULL default '0',
  `itemid` smallint(5) unsigned NOT NULL default '0',
  `count` int(11) unsigned NOT NULL default '0',
  `lastaccesstime` int(11) unsigned NOT NULL default '0',
  PRIMARY KEY  (`userid`,`itemid`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Mysql gibt auch alles korrekt wieder, nur die Inhalte sind nicht zufriedenstellend.

Jemand eine Idee was ich falsch mache?

Danke für jeden Tip !!!

[Forumsgast]

welche mysql version verwendest du denn?

eventuell kannst du dir aus diesem thread hier die nötigen infos herausziehen die du für dein problem brauchst: http://www.mysqldumper.de/board/viewtopic.php?t=2313

[Forumsgast]

Hallo Carino,

erstmal Herzlich Willkommen im Forum. Ich würde dich jedoch bitten, deine Threads ein bischen treffender zu formulieren, das hilft den Mitgliedern hier sehr.

Zu deiner Frage:
Wichtig ist nicht nur, dass die Inhalte auf UTF-8 umgestellt sind, sondern auch die Header in den ausgelieferten HTML-Dateien. Erscheinen statt den Sonder-Zeichen zwei "verwirrte" Zeichen, so ist das ein eindeutiges Indiz, dass ein Mehrbyte-Zeichensatz versucht wird in einem Einbyte-Zeichensatz auszugeben (z.B. UTF-8 als ISO-8859-1 ausgeben).

[Forumsgast]

Es handelt sich um mysql 5.0.33

Danke für den Link, sehr informativ! Und ein zweites Danke dazu, denn endlich habe ich meinen heißgelieben mysqldumper wiedergefunden. ist irgendwie in meinen bookmarks abhanden gekommen.

Nun denn, ich habe ja nicht dieses klassische Problem "welche kodierung hat meine DB" und "welche kodierung hat mein file"...

Das File stammt aus einem Backup, welches schon etwas älter war und vor allem total durcheinander (typische UTF8 > Latin Problematik á la äöü). Nun, ich habe in mühevoller Arbeit sämtliche kryptischen INSERTS umgeschrieben in die korrekten Umlaute und diese mit verschiedenen Editoren in UTF-8 gespeichert, konvertiert und was sonst noch.

Meine Datenbank ist wie auch hier UTF-8 und die Datei auch.


Aber ein Import zeigt wieder die kryptischen Zeichen....*haareausreiss*

Gruß Carino

@Dr.e.

hoffe so ist es besser

[Forumsgast]

Hallo Carino,

@Dr.e.

hoffe so ist es besser

Kann mich nicht beklagen - hervorragend.

Welches Tool erzeugt dir diese Auflistung? "latin1" ist kein UTF-8. Hast du die Meta-Tags im Quelltext schon umgestellt?

[Forumsgast]

es geht ja momentan um den dump und der datenbank.
im quelltext ist alles schon fertig aber das ist net das thema.
wenn ich nen utf8 dump in die utf8 db importiere kommt blödsinn raus und laut http://www.mysqldumper.de/board/viewtopic.php?t=2313 ist nur character_set_client und character_set_connection wichtig. Das habe ich ja auch so.

[Forumsgast]

Hallo Carino,

dann geht entweder der Import schief, oder der Export. Ich würde mir mal den Export ansehen - insbesondere die "CREATE TABLE"-Statements und dort analysieren, welcher Zeichen beim exportieren verwendet wurde. Stimmt das alles, muss du etwas mehr Code posten, sonst bräuchte ich eine Glaskugel...

[Forumsgast]

Ja, beim Export ist ganz gewaltig was schief gegangen, aber ich kanns leider nimmer ändern und muss schauen dass ich das format so hinkriege dass es wieder im import passt.

ich versteh nur nicht, wieso das nicht übereinanderpasst, irgendwo kann es ja kein utf8 sein, oder sehe ich das falsch?

[Forumsgast]

Hallo Carino,

Ja, beim Export ist ganz gewaltig was schief gegangen, aber ich kanns leider nimmer ändern und muss schauen dass ich das format so hinkriege dass es wieder im import passt.

Das ist die falsche Vorgehensweise. Du musst den Import so ändern, dass er dir die Inhalte ausspuckt, die du brauchst und vor allem in der Art und Weise, wie du sie brauchst.

ich versteh nur nicht, wieso das nicht übereinanderpasst, irgendwo kann es ja kein utf8 sein, oder sehe ich das falsch?

Richtig. Irgendwo gibt es eine Zeichensatz-(collation)-Schwulität. Am besten hangelst du dich an den CREATE TABLE-Statements entlang und untersuchst, ob die Tabellen im Export auch den gewünschten Zeichensatz deklarieren. Anschließend muss natürlich auch die Export-Datei in UTF-8 codiert sein.

[Forumsgast]

Es gibt ja keinen Export mehr. Die Datei liegt lokal, ist bearbeitet und von sämtlichen Programmen als UTF8 deklariert und möchte in die Datenbank rein

Wenn ich jetzt nach einem Wort mit Umlaut suche (%Vorschl% von Vorschläge) bekomme ich das:

SELECT *
FROM `wbb`.`bb1_boards`
WHERE `boardid` LIKE '%%Vorschl%%'
OR `styleid` LIKE '%%Vorschl%%'
OR `parentid` LIKE '%%Vorschl%%'
OR `parentlist` LIKE CONVERT( _utf8 '%%Vorschl%%'
USING utf8 )
COLLATE utf8_general_ci
OR `childlist` LIKE CONVERT( _utf8 '%%Vorschl%%'
USING utf8 )
COLLATE utf8_general_ci
OR `boardorder` LIKE '%%Vorschl%%'
OR `title` LIKE CONVERT( _utf8 '%%Vorschl%%'
USING utf8 )
COLLATE utf8_general_ci
OR `password` LIKE CONVERT( _utf8 '%%Vorschl%%'
USING utf8 )
COLLATE utf8_general_ci
OR `description` LIKE CONVERT( _utf8 '%%Vorschl%%'
USING utf8 )
COLLATE utf8_general_ci
OR `prefixuse` LIKE '%%Vorschl%%'
OR `prefixrequired` LIKE '%%Vorschl%%'
OR `prefix` LIKE CONVERT( _utf8 '%%Vorschl%%'
USING utf8 )
COLLATE utf8_general_ci
OR `threadtemplateuse` LIKE '%%Vorschl%%'
OR `threadtemplate` LIKE CONVERT( _utf8 '%%Vorschl%%'
USING utf8 )
COLLATE utf8_general_ci
OR `posttemplateuse` LIKE '%%Vorschl%%'
OR `posttemplate` LIKE CONVERT( _utf8 '%%Vorschl%%'
USING utf8 )
COLLATE utf8_general_ci
OR `threadcount` LIKE '%%Vorschl%%'
OR `postcount` LIKE '%%Vorschl%%'
OR `lastthreadid` LIKE '%%Vorschl%%'
OR `lastposttime` LIKE '%%Vorschl%%'
OR `lastposterid` LIKE '%%Vorschl%%'
OR `lastposter` LIKE CONVERT( _utf8 '%%Vorschl%%'
USING utf8 )
COLLATE utf8_general_ci
OR `allowratings` LIKE '%%Vorschl%%'
OR `daysprune` LIKE '%%Vorschl%%'
OR `sortfield` LIKE CONVERT( _utf8 '%%Vorschl%%'
USING utf8 )
COLLATE utf8_general_ci
OR `sortorder` LIKE CONVERT( _utf8 '%%Vorschl%%'
USING utf8 )
COLLATE utf8_general_ci
OR `threadsperpage` LIKE '%%Vorschl%%'
OR `postsperpage` LIKE '%%Vorschl%%'
OR `postorder` LIKE '%%Vorschl%%'
OR `countuserposts` LIKE '%%Vorschl%%'
OR `hotthread_reply` LIKE '%%Vorschl%%'
OR `hotthread_view` LIKE '%%Vorschl%%'
OR `moderatenew` LIKE '%%Vorschl%%'
OR `enforcestyle` LIKE '%%Vorschl%%'
OR `closed` LIKE '%%Vorschl%%'
OR `isboard` LIKE '%%Vorschl%%'
OR `invisible` LIKE '%%Vorschl%%'
OR `showinarchive` LIKE '%%Vorschl%%'
OR `externalurl` LIKE CONVERT( _utf8 '%%Vorschl%%'
USING utf8 )
COLLATE utf8_general_ci
LIMIT 0 , 30

Und gefunden wird "Vorschläge" ... gebs bald auf

Die Create Tables sehen so aus:

CREATE TABLE `bb1_access` (
  `boardid` int(11) unsigned NOT NULL default '0',
  `userid` int(11) unsigned NOT NULL default '0',
  `can_view_board` tinyint(1) NOT NULL default '-1',
  `can_enter_board` tinyint(1) NOT NULL default '-1',
  `can_read_thread` tinyint(1) NOT NULL default '-1',
  `can_start_topic` tinyint(1) NOT NULL default '-1',
  `can_reply_topic` tinyint(1) NOT NULL default '-1',
  `can_post_poll` tinyint(1) NOT NULL default '-1',
  `can_upload_attachments` tinyint(1) NOT NULL default '-1',
  `can_download_attachments` tinyint(1) NOT NULL default '-1',
  `can_post_without_moderation` tinyint(1) NOT NULL default '-1',
  `can_close_own_topic` tinyint(1) NOT NULL default '-1',
  `can_use_search` tinyint(1) NOT NULL default '-1',
  `can_vote_poll` tinyint(1) NOT NULL default '-1',
  `can_rate_thread` tinyint(1) NOT NULL default '-1',
  `can_del_own_post` tinyint(1) NOT NULL default '-1',
  `can_edit_own_post` tinyint(1) NOT NULL default '-1',
  `can_del_own_topic` tinyint(1) NOT NULL default '-1',
  `can_edit_own_topic` tinyint(1) NOT NULL default '-1',
  `can_move_own_topic` tinyint(1) NOT NULL default '-1',
  `can_use_post_html` tinyint(1) NOT NULL default '-1',
  `can_use_post_bbcode` tinyint(1) NOT NULL default '-1',
  `can_use_post_smilies` tinyint(1) NOT NULL default '-1',
  `can_use_post_icons` tinyint(1) NOT NULL default '-1',
  `can_use_post_images` tinyint(1) NOT NULL default '-1',
  PRIMARY KEY  (`userid`,`boardid`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Kann man die INSERTS auch extra mit UTF8 kodieren?

Nachtrag:
Wenn ich eine tabelle exportiere (mit dem sonderzeichenfehler), bekomme ich ein UNIX ANSI as UTF-8 Format. Irgendwas stimmt hier nicht. Entweder ist das Format von mir nicht korrekt oder es liegt an der Datenbank

[Forumsgast]

Hallo Carino,

Es gibt ja keinen Export mehr. Die Datei liegt lokal, ist bearbeitet und von sämtlichen Programmen als UTF8 deklariert und möchte in die Datenbank rein

Heißt das, du hast keinen Zugriff mehr auf die Quell-Datenbank?

Nachtrag:
Wenn ich eine tabelle exportiere (mit dem sonderzeichenfehler), bekomme ich ein UNIX ANSI as UTF-8 Format. Irgendwas stimmt hier nicht. Entweder ist das Format von mir nicht korrekt oder es liegt an der Datenbank :Sad

Ein "ANSI as UTF-8"? Das ist sicher strange... Prinzipiell musst du sicherstellen, dass die Codierung der Export-Datei in sich auch UTF-8-kodiert ist. Ist das nicht der Fall, musst du die Datei entweder konvertieren oder du hast "verloren". Auf LINUX geht das mit einem

iconv -f "MS-ANSI" -t "UTF-8" exportfile.sql

auf Windows mit entsprechenden Editoren oder Hex-Editoren. Grundsätzlich denke ich, dass es an deiner Datei liegt.

[Forumsgast]

Das ist ja das blödsinnige, ich habe keinen Zugriff mehr, weil die Datenbank gehackt wurde und ich mit dem letzten "fehlerhaften" Backup rumdudel

Ich habe die Umlautefehler alle bereinigt und mit dem benannten Editoren (hab mehrere probiert) auch als UTF8 gespeichert. Aber irgendwie doch nicht oder die Datenbank macht das Problem. Ich suche mal generatoren die mittels iconv (glaub über php kann ich das auf dem server ausführen, habe hier nur ne windowskiste).

[Forumsgast]

Hallo Carino,

hast du wenigstens die Orginal-Sicherungs-Datei noch? Wenn ja, kann ich dir evtl. helfen, die Datei zu konvertieren, ich hab hier zig LINUX-Kisten stehen

[Forumsgast]

Also ich habe den originalen dump, der aber fehlerhaft ist (umlaute) und die bearbeitete von mir. kann sie dir gerne beide schicken.

An welche Mailadresse darf ich sie richten? Kannst du mir ja als PM schicken.

Riesen Dank schonmal im Voraus!!!

[Forumsgast]

Hallo Carino,

ich habe deine E-Mail erhalten und mir gerade den Dump angesehen. Das File an sich ist bereits UTF-8 codiert, zumindest sagt das file:

[christian@wikiserver phpfriend_encoding]$ file -i original_dump.sql
original_dump.sql: text/plain; charset=utf-8

Die "CREATE TABLE"-Statements haben aber ein

CREATE TABLE `4images_categories` (
[..]
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=2 ;

was bedeutet, dass eine Tabelle mit Collation latin1 erzeugt wird und da hinein spielst du UTF-8-Daten. Das geht schief . Wenn du die Collation auf einen UTF-8-verträglichen Wert änderst (z.B. "utf8_general_ci"), sollte das gehen. Ist das nicht der Fall muss ich mir das nochmal genauer ansehen.