Donnerstag, 7. Januar 2010
[*]

WordPress, MySQL und unechtes UTF-8

, 22:20

Schonmal eine WordPress-Installation auf eine neue MySQL-Version umgezogen? Gerade wenn man von Version 4.x auf Version 5.x wechselt, dann stehen anschließend oft in den alten Artikeln Worte wie „heißt“ oder „größere“. Das liegt daran, dass WordPress irgendwann in der Vergangenheit (war das Version 2.3?) seine Datenhaltung auf UTF-8 umgestellt hat, ältere MySQL-Versionen aber noch keine saubere Zeichensatzunterstützung auf Tabellen- und Feldebene boten. Will man das reparieren, so muss man der Datenbank „verraten“, mit welcher Zeichencodierung die Daten in den Tabellenspalten gespeichert sind. Dazu habe ich das folgende Skript geschrieben, das von allen betroffenen Feldern die Zeichencodierung erst entfernt, um sie dann korrekt zu setzen:

alter table wp_comments change comment_author comment_author tinyblob;
alter table wp_comments change comment_author comment_author tinytext
            character set utf8;
alter table wp_comments change comment_content comment_content blob;
alter table wp_comments change comment_content comment_content text
            character set utf8;
alter table wp_links change link_name link_name varbinary(255);
alter table wp_links change link_name link_name varchar(255) character set utf8;
alter table wp_links change link_description link_description varbinary(255);
alter table wp_links change link_description link_description varchar(255)
            character set utf8;
alter table wp_links change link_notes link_notes mediumblob;
alter table wp_links change link_notes link_notes mediumtext character set utf8;
alter table wp_options change option_value option_value longblob;
alter table wp_options change option_value option_value longtext character set utf8;
alter table wp_posts change post_content post_content longblob;
alter table wp_posts change post_content post_content longtext character set utf8;
alter table wp_posts change post_title post_title blob;
alter table wp_posts change post_title post_title text character set utf8;
alter table wp_posts change post_excerpt post_excerpt blob;
alter table wp_posts change post_excerpt post_excerpt text character set utf8;
alter table wp_posts change post_content_filtered post_content_filtered blob;
alter table wp_posts change post_content_filtered post_content_filtered text
            character set utf8;
alter table wp_term_taxonomy change description description longblob;
alter table wp_term_taxonomy change description description longtext
            character set utf8;
alter table wp_terms change name name varbinary(200);
alter table wp_terms change name name varchar(200) character set utf8;
alter table wp_usermeta change meta_value meta_value longblob;
alter table wp_usermeta change meta_value meta_value longtext character set utf8;

Vielleicht hilft es ja jemandem…

Donnerstag, 22. Oktober 2009
[*]
[*]
Sonntag, 27. Mai 2007
[*]

Das Orakel (oder: auf dem Weg zu den Originaldaten)

, 13:33

Einer der Haupthinderungsgründe für den Weiterbetrieb der Alertbird-Software war ja immer der Ressourcenbedarf (sowohl Rechner- als auch Geld-) der Oracle-Datenbank. Meine Umbautätigkeiten bestehen deshalb bisher zum größten Teil aus Änderungen, um die Daten in Zukunft in einer PostgreSQL-Datenbank halten zu können. Leider habe ich die alten Daten nur in Form eines exp/imp-Dumpfiles für Oracle 8i, drum mußte ich tricksen:

Aus der Arbyte habe ich mir eine virtuelle VMWare-Maschine mit Oracle 9i drauf ausgeliehen, dort den Dump eingespielt und mit einem JAVA-Programm die Daten in die Postgres rüberkopiert (solche Programme sind schnell geschrieben, das habe ich schließlich im FleetBoard-Projekt lange genug geübt). Leider waren nachher alle Umlaute weg (bzw. es war ein Bit abgeschnitten — die Leute heißen dann z.B. „Jvrg“). Kurz nachgesehen: die Umlaute waren aber auch in der Quelldatenbank schon weg, am Kopierprogramm liegt’s also nicht. imp nochmal ausgeführt: da steht doch tatsächlich, die Daten seien US7ASCII-Kodiert. Ohje, sollten die Umlaute etwa beim Export schon verschwunden sein? Dann wären sie seit 2004 weg und wohl nicht wieder aufzutreiben…

Zum Glück waren die Umlaute in der Datei selbst vorhanden, da stimmte wohl nur die Deklaration nicht (das bedeutet übrigens gleichzeitig, daß Umlaute in Alertbird in der Vergangenheit nur deshalb funktioniert haben, weil Oracle sich vor Version 9 nicht um den Inhalt des achten Bits geschert hat, wenn ein 7-Bit-Zeichensatz eingestellt war). Hier fand ich eine Erklärung, wie die Zeichensatzangabe in die Exportdatei kommt. Ich brauchte also nur einen Hexeditor…

Cygnus Hexedit

… und mußte den Anfang der Datei von „03 00 01 …“ auf „03 00 1F…“ ändern, nochmal in Oracle importieren und die Kopie noch einmal starten.

Das sieht doch schon ganz gut aus (an den Datumsfeldern muß ich aber noch feilen, die verlieren noch alle ihre Uhrzeit):

Echt alte Daten