Zum Beispiel kann man WordPress problemlos mit beliebigen Schriftzeichen füttern. Hierfür muss nur in Optionen>Lesen als “Zeichensatz für Seiten und Feeds” UTF-8 eingetragen sein. So lange ich WordPress benutze war dies schon beim Einrichten eines neuen Systems so eingestellt.

Die WordPress-Datenbanktabellen werden in MySQL aber standardmäßig als “latin1″ angelegt. Das führt nicht nur dazu, dass PHPMyAdmin unter anderem deutsche Umlaute falsch darstellt. Auch funktionieren Datenbankabfragen, die Unicodezeichen enthalten, nicht wie erwartet.

Nicht nur das. Der Inhalt der Tabellenzellen ist auch noch mehrfach kodiert: die einzelnen Bytes der ein- bis vierbytigen UTF-8 Zeichen sind in ihrer ISO-8859-1-Darstellung nochmals UTF-8 kodiert! Das ist mindestens so kompliziert wie es sich anhört. In diesem Fall ist eine Lösung den Datenbankabzug (SQL-Dump) von UTF-8 nach ISO-8859-1(!) zu konvertieren. Man erhält dann eine Datei die endlich echtes UTF-8 ist.

Ich habe leider schon mehrfach mit solchen Problemen gekämpft. Auch mit Dateinamen, die asiatische Zeichen enthalten. Wie auch in jenem Fall hilft das UNIX-Tool “iconv”:

iconv -f utf-8 -t iso-8859-1 dump.sql > dump-utf8.sql

Nach einer kurzen Websuche bin ich auf einen Script zur Konvertierung gestoßen. Der dortige Script ist aber mit äußerster Vorsicht zu genießen und man sollte wirklich unbedingt ein Backup der ganzen MySQL-Datenbank durchführen. Das Script beschränkt sich nämlich nicht auf die Tabellen des aktuellen WordPress-Blogs. Es konvertiert vielmehr alle Tabellen der aktuellen Datenbank.

Da ich, wie oben erwähnt, schon immer UTF-8 als Kodierung für meine Inhalte verwendet habe, verhackstückelte der erste Durchlauf außerdem alle vorher einwandfreien Umlaute. Ich musste also ein Backup einspielen und den Script modifizieren. Dazu habe ich kurzerhand den Bereich von “//Convert its data” bis “flush(); }” auskommentiert. Der Autor hatte wohl sein zu konvertierendes WordPress ursprünglich auf “ISO-8859-1″ stehen.

Der Skript leistete in meinem Fall nicht nur zu viel Arbeit, sondern vergisst nicht nur die Tabellen, sondern auch die Datenbank selbst auf “utf8_general_ci” umzustellen.

Nach der Umstellung muss ich immer noch Datenbankbackups, die ich mit dem Modul “Datensicherung” gemacht habe, mit der Option “latin1″ importieren. Auf den ersten Blick ist das verwunderlich. Also hat hier wohl wieder ein Programmierer geschludert.

Update: Mittlerweile ist dieses Problem gelöst, nur um vom nächsten ersetzt zu werden (Englischer Beitrag zu diesem Thema).

Anhang
Die Basis für eine solche Dateinamenkonvertierung sieht in Applescript in Ermangelung einer AppleScript-eigenen Funktion in etwa so aus:
set newFileName to do shell script "echo 'ÉsÉìÉNÉLÉâÅ[.txt' | iconv -f UTF8 -t MACROMAN | iconv -f SHIFT_JIS -t UTF8"
Leider gab es hier noch ein Schönheitsfehler. Ich hatte mit der damals aktuellen Version von Mac OS X das Probleme per AppleScript der ursprünglichen Datei auch diesen neuen Namen zu geben. Wieder ein Beispiel für schnodderigen Umgang mit Textkodierungen. Mittlerweile geht zumindest das einwandfrei:
Encoding Conversion Droplet ansehen, downloaden
Für die Konvertierung in HTML habe ich übrigens Convert Applescript to HTML verwendet, dass ich mittlerweile massiv erweitert und XHTML fähig gemacht habe.

Links zum Thema

• sententia fredericiana » WordPress goes Multikulti
• Sébastien Erard » WordPress MySQL database : conversion to UTF-8
• Climb to the Stars (Stephanie Booth) » Converting MySQL Database Contents to UTF-8
• The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) – Joel on Software
• A tutorial on character code issues