Ilona wünschte sich von mir ein Ostergeschenk. Eine Erklärung wie man die Tabellen von WordPress auf UTF8 umstellen kann.
Grund für so eine Umstellung ist oft, weil man sonst die konfusesten Zeichen in seinem Blog wieder findet, wenn die Datenbank UTF8 ist, WordPress selbst unter UTF8 läuft, die Tabellen aber noch CHARSET=latin1.
Nun ich nutzte dafür einen Editor, der suchen und ersetzen kann.
Datenbankbackup machen
Zuerst holte ich mir ein Datenbankbackup. MySqlDumper ist da sehr hilfreich, weil es unkompliziert ist große Datenbanken in kleine Dateien zu zerlegen.
Editor der suchen und ersetzen kann
Dann öffnete ich so eine “Portion Datenbank” und ließ meinen Editor nach:
CHARSET=latin1
suchen und gab gleich den Befehl er möge dies mit
CHARSET=utf8
ersetzen. Speichern.
Datenbank importieren
So tat ich mit allen “Portionen”. Danach importierte ich die Datenbank mit Hilfe des oben erwähnten Tools.
Ilona
19.03.08 um 13:30Ohhhh… So leicht geht das? Und ich hatte nach ner Anleitung, nach der irgendwas auf blob gesetzt werden musste und dann … weiß der Geier, warum, jedenfalls hat es nie funktioniert. Dann habe ich Tabelle für Tabelle bearbeitet, was auch nicht vollständig war, weil in den einzelnen Tabellenspalten immer noch was Latin-artiges hängenblieb.
Dann habe ich ja bei dem angekündigten Ostersauwetter was zu basteln.
Jedenfalls tausend Dank für dieses schöne Osterei und Dir ein wunderschönes Osterfest!!
Liebe Grüße
Ilona
Uwe
06.04.08 um 16:02Hmm, ist diese Vorgehensweise identisch mit der Option in phpmyadmin? Da gibt es unter “Operationen” ja auch den Punkt Kollation, wo man dann utf8_unicode_ci auswählen kann?
)
(Ich glaub ich muss meinen Hoster mal nerven, ich dümpel wohl auch seit Anbeginn der Zeit mit Latin1 in der DB und UTF-8 an allen anderen Ecken rum
texto
06.04.08 um 18:54Hi das eine ist die Datenbank prinzipiell auf UTF-8 stellen, das andere- das was ich hier beschrieb-sind die Tabellen von WP
lg
Uwe
06.04.08 um 19:21Ah okay, meine Datenbank an sich scheint schon auf UTF-8 zu laufen
Dann versuch ich doch auch mal den Dumper und deine Vorgehensweise
Damit dürften dann auch die falsch dargestellten Sonderzeichen im phpmyadmin verschwinden oder?
Vielen lieben Dank!
texto
06.04.08 um 21:12Damit dürften dann auch die falsch dargestellten Sonderzeichen im phpmyadmin verschwinden oder?
ich hoffe es
bei mir war es so
lg
Uwe
06.04.08 um 21:31Das hab ich auch gehofft, leider war dem nicht so
Die Sonderzeichen sind noch der gleiche Wirrwarr wie vorher, angezeigt wird zwar alles richtig, nur Google und phpMyadmin sind anderer Ansicht
Obendrein.. es gibt ja diese neuen Funktionen seit WP 2.5, wenn ich
define(‘DB_CHARSET’, ‘utf8′);
define(‘DB_COLLATE’, ”);
einfüge, dann werden die sogar in den Beiträgen und in der Sidebar falsch angezeigt
Hmm.. ich bin überfragt
texto
06.04.08 um 22:21hmm Google kann ja Deine Änderungen noch gar nicht haben, so schnell ist Google ja nicht mal hier,
wo sind die denn falsch ?
lg
Uwe
06.04.08 um 22:30Blödes Google
Also irgendwie.. blicke ich selber nicht so ganz wann es auftaucht
Manchmal “im Content”, überwiegend aber nur im Titel – bei den neueren Beiträgen seit 2.5 wohl jetzt immer und auch ältere Einträge scheinen betroffen
und die posts-Tabelle in phpmyadmin ist komplett “verhunzt”
Fragt sich nur warum?
ist angegeben
in den WP-Einstellungen steht UTF-8,
Der MySQL-Zeichensatz: UTF-8 Unicode (utf8) dürfte auch ok sein, Zeichensatz / Kollation der MySQL-Verbindun ist auch auf utf8_general_ci und alle Tabellen der Datenbank stehen auch auf utf8_unicode_ci
.. da fehlt doch nix?! Und ich würde mal frech behaupten, dass das Problem vor 2.5 nicht präsent war aber man weiß ja, dass Probleme nie einfach so auftauchen
texto
06.04.08 um 22:45du hast oberhalb der Kommentare einen Text stehen, dazu sandte ich Dir soeben bei Dir am Blog einen Kommentar der nach dem Absenden eine weiße Seite mir zeigte…
ich mag WP 2.5 ich mag WP 2.5 wird mein täglich Mantra ….
lg
Uwe
06.04.08 um 22:49:-O
Die Kommentarfunktion funktionierte aber noch, das muss ein unglücklicher Zufall oder schlechtes Karma (nein, kein Spam-Karma) sein
Hm.. ich würde diese Probleme ja zu gerne auf 2.5 oder Google abwälzen
texto
07.04.08 um 10:10Uwe guten Morgen, ich vermut alles wird nicht sicht *abwälzen* lassen
Kaffee rüberreich ….
Uwe
07.04.08 um 15:21Einen schönen guten Mittag Monika,
in der Tat, das vielleicht nicht
Aber ich glaube.. solange das für den Browser beim Direktauruf richtig angezeigt wird kann man diese paar Sonderzeichen im Titel auf einer Googleseite oder in der DB vernachlässigen.. anscheinend werden die eh “falsch” oder verquert in die DB geschrieben..
Danke, lieber Tee statt Kaffee
texto
07.04.08 um 16:30oh Uwe…
ich bin mir sehr sicher, daran liegts!
zum Anderen-ja solange es nicht wirklich stört.
montäglich ernst
lg
Uwe
07.04.08 um 17:01He? Sind Teetrinker schlechtere Menschen oder nach Studien häufiger anfällig für technische Probleme mit WordPress?
Naja, gerade hat Google einen Beitrag von heute gefunden, im Inhalt selbst kommen üs vor und die sind korrekt
Verstehe wer will, ich will erstmal nicht mehr, solang sich nicht mal Probleme an grundlegende Logik und Muster halten
texto
07.04.08 um 20:56Hi Uwe
nein Teetrinker sind niemals schlechtere Menschen, bloß haben sie laut einschlägiger Studien der unabhängigen CF4you (coffeforyou) Gesellschaft eindeutig immer schlechtere Karten
solange die ÜÖÄßkorrekt sind hat Logik Pause zumindest Montags
lg
Uwe
07.04.08 um 22:13Hmm Monika, die Auswertungen und Ergebnisse dieser Studien musst du mir unbedingt zukommen lassen
Nur frage ich mich, ob diese Gesellschaft wirklich so unabhängig ist? Zumindest bei Kaffee könnte das sehr strittig werden
Ja, es ist irgendwie kein System drin, wahrscheinlich verschwindet es zu dem Tag, wo der Vollmond auf eine prominente Steinformation scheint
texto
07.04.08 um 23:31och Uwe die Studie ist genauso unabhängig wie De und At nach dem Beitritt zur EU.
Ich vermute, wenn der Vollmond auf eine prominente Steinformation scheint und Österreich Deutschland bei der Europameisterschaft schlägt.
Uwe
08.04.08 um 00:16Da hilft wohl nur eins: Abwarten und Tee trinken?
Uwe
08.04.08 um 17:04Monika, Tee löst aber anscheinend Probleme!
Ich habe deinem Hinweis oben entnommen, dass du was zu dem Text über dem Kommentarfeld sagen wolltest (hab ich doch richtig verstanden, oder?)
und da spuckte der Validator tatsächlich rum, dass da ein oder mehr Zeichen nicht richtig kodiert wären
Und was war es? Ein ä stand als ä und nicht als Entity da
Das habe ich gerade mal geändert, jetzt spuckt der Validator nur noch über blöde andere Verschachtelungsfehler aber.. ich würde behaupten, dass Tante G gerade wieder sowohl öäü vom Titel als auch anderswo darstellt!
Vielen Dank für diesen Fingerzeig!
Ilona
11.12.08 um 16:52Tja, nachdem ich das Problem den ganzen Sommer über verschoben habe, kann ich jetzt mal wieder sagen: Ich kriegs nicht hin. Menno!
texto
11.12.08 um 18:17Ilona wo hakts?
lg
Ilona
11.12.08 um 22:05Klar, ich hätte mich ja mal deutlicher ausdrücken können. Also erstmal kam nach der Suchen und Ersetzen Aktion beim Reimport immer ne Fehlermeldung, dass er die Kollation latin1_german2_ci nicht mit utf-8 vertragen. (Oder so ähnlich)
Hab ich also mit Suchen und Ersetzen diese Sachen in utf8_unicode_ci umgewandelt, dann war die Fehlermeldung wech und ich konnte die Datenbank importieren. Aber die grusslichen Sonderzeichen statt ä, ü oder ß waren nach wie vor zu sehen.
Aaaaber, wie ich dann festgestellt habe, nur in den alten bestehenden Beiträgen, wenn ich einen neuen Eintrag verfasst habe, sah alles i. O. aus.
Ich habe das nun so gelöst, dass ich mit dem Searchandreplace-Plugin die Sonderzeichen aus den alten Einträgen rausgeext habe. Nu isses gut und ich hab mein erstes Blog auf 2.7 hochgezogen.
Wenn nu dieses Multimedia-Gekruschtel in 2.7 so funktionieren würde, dass man damit vernünftige Galerien u. ä. machen kann, würde ich die anderen Blogs auch… aber…. Na ja, ich arbeite dran.
Wasn Roman hier… Hätt ich auch nen eigenen Artikel schreiben können. Mach ich vielleicht auch noch.
Aber ne Idee haste nicht zufällig, woran das liegen könnte mit den Sonderzeichen?
texto
11.12.08 um 23:30eventuell doch…
die neue wp-config.php zwingt zu UTF8 und als ich das zb hier auskommentierte, ward alles gut,
manche Datenbanken lassen sich nicht zu was zwingen was schon da ist,
es kann ja sein, dass html mäßig, das eine in entities das andere in ascii Zeichen abgespeichert war, – die einen, die neuen wurden korrekt übersetzt, die anderen die alten nicht,
ob aber jetzt die neuen als ascii oder die alten- da bin ich kurz auch überfragt.
lg
KRiZZi
13.01.09 um 16:35Wollte mich nur noch mal fix für die Anleitung & Unterstützung bei meiner persönlichen, kleinen UTF-8 Umstellung bedanken. =)
Lieben Gruss von der Küste
Sascha
nepf
05.02.09 um 19:03Liebe Monika, hab dazu noch ne Nachfrage:
In meinem Dump wimmelts aber auch noch von sowas:
“collate latin1_general_ci”
muss ich das auch irgendwie ersetzen?
Roland
21.03.09 um 23:31Hi Texto,
das alles hat bei mir überhaupt nicht funktioniert. Die Datenbanken waren alle schon auf utf-8 geschaltet. Trotzdem hatte mein Blog mit dem neuesten Update auf 2.7.1 plötzlich die komischen Zeichen.
Stattdessen habe ich nun in der wp-config.php “latin1″ eingetragen, statt “utf-8″ und jetzt sind die Umlaute wieder korrekt dargestellt.
Warum das alles so ist, weiss ich nicht. Und ob eine gesamte Umstellung auf utf-8 besser wäre, weiss ich auch nicht. Aber wenn, dann würde ich gerne genauer wissen, wo man das überall umstellen muss, damit es richtig funzt…
texto
22.03.09 um 17:12Hi Roland
im Blog
die Datenbank
die Tabellen der Datenbanl
wp-config.php
kann es dann sein, dass man dies mit 2 Schrägstrichen vorne auskommentieren muss
also so
//define(’DB_COLLATE’, ”);Thilo
16.05.09 um 09:38Ich hatte vor einigen Monaten mal das Problem mit UTF-8 und latin1. Damals habe ich zig Stunden damit verbracht WordPress andere Charsets aufzuzwingen, und nun stoß ich auf deinen Beitrag…so einfach hätte es also sein können
Ich hab den beitrag mal gebookmarked, vielleicht stoße ich ja nochmals auf das Problem. Danke für die einfache Anleitung
Eric
10.04.10 um 11:12Wieso sollte man überhaupt auf UTF8 umstellen wollen? Macht doch fast nur Sinn, wenn man Besucher aus fernost erwartet oder?
In der Regel reicht doch für deutsche Besucher auch latin1 aus.
Das einzige wo nervt ist wenn man noch Javascript und AJAX im Einsatz hat, weil da ja standardmäßig alles UTF8 kodiert ist, was man aber auch recht gut mit utf8_decode() in den Griff bekommt.