Kaputte Zeichen auf der Website

Merkwürdige Probleme mit Sonderzeichen sind ja mein Spezialgebiet. Daher freute ich mich über eine Supportanfrage, die ich vor ein paar Tagen bekam. Merkwürdige Zeichen tauchten in der Website auf. Es waren immer bestimmte Kombinationen von Zeichen, sie tauchten meist morgens früh auf, obwohl angeblich repariert. Also ging ich auf die Suche …

Als erstes schaute ich morgens früh als erstes auf die Kundenwebsite, um das Problem selbst mal anzuschauen. Meine erste Idee bestätigte sich schnell, denn es handelte sich um Zeichen, die mir noch sehr bekannt waren. Statt einem „Ä“ befanden sich überall auf der Website folgende Zeichen „Ä“, ein „ü“ war „ü“, usw. usf.

Ein kurzer Test mit einem UTF-8/Latin-Konverter bestätigte den Verdacht. Es handelte sich um Zeichen im Latin-Zeichensatz (ISO-8859-1), die aber als UTF-8 ausgegeben wurden.

Ein Problem, dass ich lange nicht mehr gesehen habe. Typischerweise tauchte das Problem in einer Zeit auf, wo die Websites im ISO-8859-1-Zeichensatz erstellt wurden und dann zum Beispiel durch eine Migration plötzlich als UTF-8 ausgegeben wurden.

Damals eigentlich ein sehr bekanntes Problem. So bekannt, dass Frank Bültge eigens dafür eine PDF erstellt hat, mit allen möglichen UTF-8-Kodierungen. Es ist eine mühsame, manuelle Suchen&Ersetzen-Arbeit, aber so lassen sich alle kaputten Zeichen einfach reparieren.

WordPress selbst dokumentiert noch einen anderen Weg, den Zeichensatz zu konvertieren. Das dort beschriebene Grundprinzip ist, dass der Zeichensatz der Datenbank zu „Binary“ geändert wird und dann erst in den gewünschten neuen Zeichensatz, also UTF-8. Die Erklärung und Umsetzung ist deutlich komplexer. Wer möchte kann dies in dem Codex-Artikel nachlesen.

Das Problem bei meinem Kunden war jedoch, dass der Support zusätzlich einen völlig falschen Rat gab. Der Hoster schrieb meinem Kunden (noch bevor er zu mir kam), dass einfach der DB_COLLATE-Wert in der wp-config.php geändert werden müsste. Das Problem ist nur, dass DB_COLLATE nur die Sortierung definiert und nicht den Zeichensatz selbst. Außerdem ändert ein geänderter Wert in der wp-config.php nichts in der Datenbank. Es definiert nur, wie hinein geschrieben wird und als was der Inhalt interpretiert wird, aber der genutzte Zeichensatz in der Datenbank ändert sich dadurch nicht.

Ich weiß nicht, ob es ein missglückter Versuch des Support war oder der beherzte Versuch eines der Mitarbeiter beim Kunden, aber es endete in der völlig falschen Änderungen der wp-config.php:

Durch die typographischen Anführungszeichen war DB_CHARSET gar nicht definiert und bei DB_COLLATE, wo in den meisten Fällen ein leerer Wert ausreicht, um WordPress bzw. MySQL hier selbst den Standardwert definieren zu lassen war nun UTF-8 definiert.

Ich reparierte also den DB_CHARSET-Eintrag in der wp-config.php und entschied mich für den manuellen Suchen&Ersetzen-Weg.

Die Frage, die offen blieb ist natürlich wie das entstehen konnte. War die Installation vielleicht so alt, dass sie tatsächlich noch in ISO-8859-1 erstellt wurde? Hätte der Fehler dann nicht schon bei der Migration zum neuen Hoster auftreten müssen? Wieso ist er hierbei niemandem aufgefallen? Oder wurde beim Erstellen der Datenbank Mist gebaut? Oder gab es durch nicht unterstützte Zeichensatz-Einstellungen auf dem Zielsystem einen ungünstigen Fallback auf Latin/ISO-8859-1 als Zeichensatz?

Und warum gibt der Hoster einen so schlechten, uninformierten Rat? Verlange ich da zuviel von einem Hoster-Support? Oder wäre der Hoster gerade hier in der Pflicht und Verantwortung dem Kunden nicht einen so falschen Tipp zu geben?

Ich mag kein „public shaming“, daher steht hier nicht der Name des Hosters. Aber ich würde gerne die Frage an meine geschätzten Kolleginnen und Kollegen, insbesondere aus der Hosterwelt, weitergeben. Ist das zuviel verlangt von einem Support oder hätte der Hoster hier dem Kunden besser helfen müssen?

Ich freue mich über eure Meinungen und Kommentare!

3 Antworten auf Kaputte Zeichen auf der Website

  1. Die vorhandene technische Wissenstiefe und/oder der Willen, diese auch anzuwenden, ist beim Support bei Hostinganbietern erfahrungsgemäß eher Glückssache.

    Oft hilft es schon, sich bei im Gesprächsverlauf erkennbar nicht so recht zielführenden Antworten brav zu bedanken und einfach etwas später nochmal anzurufen und das Problem einem anderen Mitarbeiter zu schildern.

    Auch ggf. vorhandene Dokumentationen und FAQs sind durch Redaktionssysteme oder falsches Copy&Paste oft fehlerbehaftet, gerade was die Anführungszeichen, Hochkommas oder auch die Wandlung von/in HTML Entities angeht, Beispiel: Codesnippet beginnt dann schon mal mit >?php

    • Kann ich beides bestätigen. Manchmal ist auch ein Wechsel des Mediums hilfreich, wenn der Telefonsupport schlecht ist, dann hilft vielleicht Mail (oder Twitter) besser/schneller weiter. Zumindest wenn da Leute mit echten Kompetenzen und Rechten sitzen und nicht nur Marketer.

      Oh und Dokumentationen/Blogartikel sind tatsächlich ein Graus. Gerade bei den typografischen Anführungszeichen dürfte das in den meisten Fällen mehr Supportaufwand generieren als lösen …

  2. Das Beispiel sollte statt >?php natürlich <?php heissen, aber mit & („und“ Zeichen), dann l, dann t, dann ; dann ?php – Die Kommentarfunktion hier wandelt das auch ungefragt um. :-/

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.