![[GREGEL DOT COM]](http://static.gregel.com/themes/mg/images/header1.jpg)
lädt ...Zeichencodierung gehört zu den Dinge, die Kopfschmerzen machen. Definitiv.
Die Tage ist mir zufällig aufgefallen, dass mein Design im Internet Explorer völlig zerrissen war – die Sidebars standen Kopf. Wohlgemerkt in allen Versionen des IE, von Version 6 bis 8.
CSS Fehler?
Also mal auf den Testblog und frickeln… Oh! Der Testblog sieht völlig in Ordnung aus! Schnell die Version des Themes abgleichen… passt.
Was ist es dann? Ein Plugin? Alles Plugins abschalten – Fehler bleibt. Etwas html in einem Beitrag? Alle Beiträge in den Testblog importiert – Desing sieht nach wie vor gut aus.
Ratlosigkeit.
Quelltext rauf und runter… sieht doch gut aus! Quelltext mal im IE angucken… Oh!
Was ist das denn bitte?
Direkt am Anfang des Codes Sonderzeichen?! Ein Diff von Testblog und produktivem Blog. Ja, in der Tat der einzige Unterschied:
UTF-8 mit Byte Order Mark
Was soll das sein? Die header.php sind identisch!
Die Antwort nach gefühltem monatelangem Suchen:
Die Zeichenkodierung der Theme-Dateien war schuld!
Irgendwann kam ich vermutlich auf die Idee, dass es in einem UTF-8 Blog eine gute Idee ist, die jeweiligen Dateien auch unter UTF-8 zu speichern.
Nur leider macht das nicht jeder Editor gleich gut. In meinem Fall wurden die Dateien teilweise unter UTF-8 mit BOM (Byte Order Mark) gespeichert.
Die UTF-8-Kodierung des BOM besteht aus der Bytesequenz EF BB BF, die in nicht UTF-8-fähigen Texteditoren und Browsern meist als ISO-8859-1-Zeichen  erscheinen.
Da war sie, die Lösung… alle Dateien ohne Bommel gespeichert und sogar der IE mag nun wieder das Design! Was für eine Frickelei!
Und stell Dir mal vor, wie gelackmeiert jemand ist, der sich nicht so gut auskennt.
Wenn man Geek ist, kann man deswegen nur raten, dass man sein Blogsystem nicht zuletzt nach der Qualität des potentiellen Support wählt. Eine gut funktionierende Community, die im Zweifelsfalle hilft, ist unbezahlbar.
Ja, da ist was dran…
Eine erste gute Hilfe bei solchen Problemen ist auch immer der W3C Validator – auch bei dem Problem hier, hat er einen Hinweis ausgegeben.
(Habe den bloss ignoriert am Anfang… grins)