Probleme mit Zeichensatz nach Rücksicherung

Maik · 11.04.2007, 22:24

Ich habe mir zum rumtüfteln eine lokale Kopie meines Weblogs in einer Xampp-Installation angelegt. Per Cronjob haut mir die das "Wordpress Database Backup Version 2.0.1 wöchentlich ein Backup raus und schickt es mir per Email.

Wenn ich nun versuche per phpmyadmin mit dem Importbefehl diese Sicherung in meine Xampp Installation reinzuholen bekomme ich im Weblog für Umlaute etc. irgendwelche ASCII Zeichen. Ich habe dann die MySQL Datenbank beim Webhoster mit der Lokalen bis auf´s kleinste Verglichen. Ich kann keinen Unterschied in den Zeichensätzen oder ähnliches feststellen.

ABER: Wenn ich anstatt der Sicherung des Backup Plugins einen Datenbankexport per phpmyadmin beim Webhoster mache, und diese Ausgabe dann lokal importiere ist alles ok.

Das heisst doch eigentlich dass das Plugin beim Datenbankexport irgendwas verdreht, oder?

Hier laufen doch bestimmt ein paar Experten rum die wissen was los ist.

Ich tüftel da jetzt schon seid Stunden dran rum.

Gruß
Maik

DEV107 · 11.04.2007, 23:13

Hallo!

Du arbeitest auf einer Windows-Plattform und daran liegt es in den meisten Fällen. Von daher solltest Du auf phpmyadmin verzichten und stattdessen ein MySQL-Front-End nutzen (MySQL Client etc. pp.).

Gruß,
SOL

Maik · 12.04.2007, 19:28

Hm. Aber warum habe ich den selben Fehler bei einer Rücksicherung beim Provider?

Ich habe insgesamt 3 Datenbanken bei 1und1.

- DB-Sicherung per Wordpress plugin von der "live" Datenbank
- DB-Import über phpmyadmin von 1und1 in eine 2. Datenbank
- Kurz mal drübergucken ob die Zeichensätze noch die selben sind... mal in wp-posts reingucken, ob umlaute ok sind... aha... alles ok.
-wp-config frisieren und mit der 2. Datenbank verbinden.
-Das ist das Ergebnis als Auszug: ....Begriff im Interface w�rtlich �bersetzt...

...über mysqldumper das selbe

Das einzige was geht ist zu Fuß über phpmyadmin exportieren und wieder importieren. Das kanns ja nicht sein. Ich mach ja nix besonderes... Raus mit dem Prüll und wieder rein damit. Vor allem solls ja mit wachsender Datenbank Probleme geben wegen den zulässigen Scriptzeiten.

Ich kann mir auch nicht vorstellen dass ich der Einzige bin der das Prob hat. Könnt mir vorstellen dass da so einige sind die noch nie probiert haben ihre Sicherung mal wieder einzulesen um zu gucken ob das alles überhaupt funktioniert wie es soll, so wie ich das jetzt mal gemacht habe...

Geht mir auch nicht in den Schädel warum der Datenbankinhalt mir die Umlaute anzeigt wenn ich mir das ganze mit MySQLDumper oder phpmyadmin angucke, aber in Wordpress dann nicht.

Gruß Maik

Maik · 13.04.2007, 10:12

So, Problem gelöst... Eigentlich simpel... wie immer.

Beim Export aus phpmyadmin werden vollwertige UTF-8 Dateien erzeugt. Wenn ich diese Dateien mit phpmyadmin importiere muss die Einstellung des erwarteten Zeichensatzes entsprechend UTF-8 bleiben.

Wenn die Dateien mit MySQLDumper oder dem Wordpress Plugin erzeugt wurden muss bei einem Import per phpmyadmin der Zeichensatz auf latin-1 gesetzt werden.
Und das obwohl die Umlaute nur lesbar sind wenn ich mir die SQL-Datei mit Notepad++ ansehe wenn der Zeichensatz auf UTF-8 gesetzt ist. Deswegen habe ich auch die ganze Zeit mit UTF-8 rumgefummelt.

Is' aber auch wurscht. Hauptsache ich kann die Cronjobs laufen lassen und weiss wie ich die Sicherungen wieder sauber importieren kann und muss nicht dumm gucken wenn ich mir mal die Datenbank zerknallt habe und keine Ahnung habe wie ich meine Arbeit zurückbekomme.

Maik

newsted · 03.02.2008, 19:44

Ich habe bei insgesammt 3 Blogs das selbe Problem, jedoch ist es bei mir nicht durch importieren mit latin 1 zu beheben auch wenn ich es auf utf-8 importiere lässt es sich nicht umgehen. Hätte es auch mal probehalber mit ASCI getestet leider keine chance... was kann ich noch tun?

Monika · 03.02.2008, 20:23

Zitat:

Zitat von newsted

Ich habe bei insgesammt 3 Blogs das selbe Problem, jedoch ist es bei mir nicht durch importieren mit latin 1 zu beheben auch wenn ich es auf utf-8 importiere lässt es sich nicht umgehen. Hätte es auch mal probehalber mit ASCI getestet leider keine chance... was kann ich noch tun?

leidensgenosse

bueltge.de search and replace plugin

kategorie description und benutzerdefinierte felder werden aber nicht ersetzt,

ich habe es glaube ich 10 mal mit den diversesten einstellungen probiert

lg