WordPress: Kaputte Unlaute mit IE by thosch66 (Lizenz: CC-BY-NC-ND)
Ich habe seit längerem bei mir eine lokale Installation von WordPress laufen, auf der ich neue Plugins oder Änderungen teste, bevor ich sie bei meiner öffentlich erreichbaren Installation einsetze. Bisher hatte ich Probleme mit den Umlauten aus den Datenbankinhalten.
Zum Testen benutze ich meine Datenbankbackups, die ich mit dem Plugin WordPress Database Backup erstelle, oder spezielle Datenbankdumps ohne die Tabelle wp_options, die ich mit phpMyAdmin ziehe.
Bis jetzt habe ich micht immer darüber geärgert, dass die Umlaute nicht dargestellt werden. Je nach Browser wurden sie durch ein ? ersetzt (Firefox) oder es fehlten nach dem durch das ? ersetzten Umlaut sogar drei Zeichen (IE, siehe obiges Bild).
Gestern und heute habe ich mich mal hingesetzt, um dem Problem auf den Grund zu gehen. Wenn ich beim Browser die Zeichenkodierung von UTF-8, mit meine WordPress-Installation verwendet, auf ISO-8859-1 umstellte, dann stimmten zumindest die Umlaute aus den Datenbankinhalten. (Schätze mal, dass dann die Umlaute aus den statischen Teilen falsch dargestellt worden wären.)
Also lag die Vermutung nahe, dass die Zeichenkodierung beim Ex- bzw. Import des Datenbankdumps unter phpMyAdmin die Fehlerquelle ist.
Beim Import muss man bei phpMyAdmin eine Zeichensatzkodierung vorgegeben werden. Da der Blog unter UTF-8 läuft, hatte ich dies auch immer vorgegeben. Nachdem ich jetzt Latin-1 (alternative Bezeichnung für ISO-8859-1) vorgegeben habe, kommen die Umlaute auch sauber rüber.
Wobei das Ganze doch merkwürdig ist?! Benutzt Du bei der lokalen Installation auch UTF-8? Also im Quellcode des Templates. Was passiert, wenn Du per htaccess fest auf UTF-8 kodierst.
Ich denke, daß nur UTF-8 der richtige Weg ist – und was nicht mit UTF-8 läuft wird bei mir entweder umgeschrieben oder es fliegt raus.
Ja, beide lokalen Installationen benutzen UTF-8 und die Browser haben dies auch als solches erkannt. Mangels Umlauten im statischen Part konnte ich die Codierung aber nicht auf die Schnelle überprüfen.
Gehe mal davon aus, dass der SQL-Dump in der „falschen“ Kodierung latin-1 geschrieben wurde und daher auch in dieser Formatierung wieder aufgespielt werden wollte. Wenn man weiß, wie es geht, ist es ja kein Problem.
Pingback: green lemon [dot] org