Diskussion zu: Die Umlautproblematik - was, wieso, was tun?

Posted: 2009-05-17, 09:16 (No subject)

Wenn Du einen lokalen Server laufen hast (Xampp z.B.) kannst Du das Backup lokal einspielen und anschließend mit dem Feature Multipart wieder exportieren. Die Dateigröße der einzelnen Dateien kannst Du einstellen. Dann bekommst Du handliche Häppchen, die Du mit einem Texteditor bearbeiten kannst. Das dauert bei der Datenmenge zwar ganz schön, funktioniert dafür aber. Smile

**uses MSD regulary** Joined: 01 May 2009 Posts: 24

Das ist ja das Problem... Ich bin ja durch die Umlaut Problematik erst auf MySQL-Dumper gestoßen...

Ich hab eine TXT-Datei mit einem 2GB-Backup. Diese hatte ich so wie sie war hochgeladen und eingespielt. Hat alles funktioniert. Nur war dort natürlich auch das Backup vom Forum drin, welches seitdem weiter gelaufen ist.
Ich brauche aus DIESER Datei jetzt eben nur die Tabellen wo die Umlaute zerhauen sind.
Ich komme da einfach nicht dran. Weil WinVi da an seine Grenzen kommt. Und die Experimente sind da echt Nervenaufreibend. Weil das Öffnen mal eben 20 Minuten dauert (um dann festzustellen, dass es nicht funktioniert hat)...

Wenn ich es erst in die lokale DB kopiere (um dann ein neues Backup zu ziehen) sind die Umlautdaten verloren, das funzt nicht (keine Ahnung warum). Wenn ich es allerdings neu öffne und dann als UTF8 speichere scheint es zu gehen (hab das mal mit zwei Datensätzen getestet).

Achja, hab nen neuen Thread aufgemacht:
http://forum.mysqldumper.de/post31365.html#31365

**knows MySQLDumper** Joined: 24 Jun 2009 Posts: 6

Ich weiß nicht, ob es hilfreich ist oder gar in den FAQ erwähnt werden sollte:

php.net empfiehlt die Benutzung von mysql_set_charset() anstelle SET NAMES zu senden.

Voraussetzung dafür ist allerdings PHP5 >= v5.2.3 und MySQL >= v5.0.7.

Posted: 2009-08-17, 12:45 (No subject)

Zuerst einmal musste ich herzlich lachen, als ich gerade sah, dass die deutsche php.net-Seite selbst unter einem falsch kodierten Datenbestand leidet (dort sollte mal DUK über die DB laufen *fg*). Oder wurde dort mysql_set_charset () statt "SET NAMES" eingesetzt? Wink

Zum anderen steht dort leider keine technische Begründung warum dies effektiver sein soll, als das Senden des Queries "SET NAMES". In den User-Antworten wird gemutmaßt, dass PHP eine Konvertierung der Zeichen vornimmt, was mir aber unlogisch erscheint, da PHP beim Verarbeiten einer Text-Datei nicht wissen kann, in welcher Kodierung dort Zeichen vorliegen.

Ich gehe bis zum jetzigen Zeitpunkt davon aus, dass der PHP-Befehl intern nichts anderes als das Senden von "SET NAMES" macht, zumal als Fallback in den User-Antworten ebenfalls genau das gemacht wird. Es geht ja darum dem Server "am anderen Ende" mitzuteilen, welcher Zeichensatz kommt und dieser Server versteht nunmal nur Queries.
Ferner habe ich bisher auch noch nie den Effekt gehabt, dass ein MySQL-Server ab Version 4.1.2 den "SET NAMES"-Query nicht korrekt interpretiert und ausgeführt hat.

Solange ich keine anderslautenden technischen Erkenntnisse lese oder habe, bleibe ich bei meiner bisher bewährten Vorgehensweise.

**knows MySQLDumper** Joined: 24 Jun 2009 Posts: 6

Hehe, darüber musste ich auch herzlich schmulzeln :-)

Der Hintergrund für diese Empfehlung ist mir leider auchnicht gekannt. Vielleicht geht es aber auf folgendes zurück:
Link 1
Link 2

Dort wird berichtet, dass mysql_real_escape_string() in Verbindung mit SET NAMES bei bestimmten MultiByte Zeichenkodierungswechseln SQL-Injections ermöglichen würde (mysql_set_charset() scheint dort enger mit mysql_real_escape_string() zusammen gearbeitet zu haben, denn diese Funktion war scheinbar nicht davon betroffen. Dementsprechend muss zwischen SET NAMES und mysql_set_charset() irgendein Unterschied bestehen).

Da der Beitrag auf den sich dort bezogen wird allerdings 3 1/2 Jahre alt ist, weiß ich nicht inwieweit dies noch aktuell ist. Zumindest auf MySQL Seite scheint dieser Missstand seit v.5.0.22 gefixt worden zu sein.
Fix Report.

**first backups** Joined: 26 Aug 2009 Posts: 1

Ich hab den MySQLDumper 1.24 und habe Backup gemacht in utf8 und wieder eingespielt mit Wiederherstellen...

Meine Datenbank war latin1_swedish_ci und jetzt soll sie eine UTF8 werden.

Die Umlautfehler bekomme ich einfach nicht weg Traurig

Die Datenbank bleibt eine latin1 ...

[edit]
mit dieser duk.exe konnte ich auch nichts ändern...
[/edit]

**first backups** Joined: 11 Jan 2011 Posts: 1

Hallo DSB,

ich bin begeistert wie ausführlich und verständlich das Thema Umlaute hier beschrieben wurde. Wieso habe ich den Thread nicht schon viel früher gefunden.

Dennoch...

Ich habe nun den mysqldumper Version 1.24.2 in unterschiedlichen Verzeichnissen 2x auf meinem Webspace und möchte Daten von einer MySQL Quell-DB Version 4.0.27 auf einen MySQL Ziel-DB Version 5.0.91 umziehen.

In den SQL Variablen zeig mir der MSD für die alte Quell-DB Version 4:

character_set
german1

character_sets
latin1 big5 czech euc_kr gb2312 gbk latin1_de sjis tis620 ujis dec8 dos german1 hp8 koi8_ru latin2 swe7 usa7 cp1251 danish hebrew win1251 estonia hungarian koi8_ukr win1251ukr greek win1250 croat cp1257 latin5

Für die Zeil-DB mit SQL 5 steht dort:

character_set_client utf8
character_set_connection utf8
character_set_database latin1
character_set_filesystem binary
character_set_results utf8
character_set_server latin1
character_set_system utf8

Wenn ich Deine Ausführungen verstanden habe muß ich einen Export in UTF8 erstellen, aber die Möglichkeit wird mir im MSD nicht angeboten.

Ein Workaround mit z.B. cp1251, latin1 und latin1_de hat auch nur zu den berühmten Fragezeichen statt Umlauten geführt.

Was mache ich falsch?

Viele Grüße

Ralf

Posted: 2011-01-11, 15:41 Re: kein UTF8 Backup möglich

**knows MySQLDumper** Age: 38 Joined: 13 Oct 2011 Posts: 2

so ihr lieben jetzt muß ich mal was hierzu fragen....
ich hatte einen server bei strao der war latin1... der neue bei 161 ist auf utf8...
ich hab schon 10000000000 versuche (oder auch weniger weil ich seit ca. 2 monaten dran sitz) gestartet das ganze von latin1_schwedisch_ci (latin1) auf utf8_general_ci, utf8_unicode_ci gewandelt, hab auch alle einzelnen tabellen genaustens geprüft (dank msd nich schwer).... trotz dem dass ich alles geändert hab, auch extra in die maincore (phpfusion) header("Content-type: text/html; charset=iso-8859-1"); und auch schon header("Content-type: text/html; charset=utf8"); mit und ohne zusatz (unicode oder general) hab auch wie empfohlen in die globale.php utf8 und iso-8859-1 und so weiter..... ich hab mir echt schon die finger wund gesucht und auch alle varianten versucht......

der witz ist aber, das 2 weiter seiten problemlos laufen auf der selben DB und dem selben server, auch die selben alt eingespieletn dbeinträge (alles dank msd echt simpel) umgeändert auf utf8 passt.....

nur eben die eine seite will einfach nicht funktionieren......

der witz ist aber, eine neuinstallation wäre fehlerlos mit utf8_unicode_ci..... sobald ich aber dann die einzelnen tabellen update geht nix mehr.....