Na, sowas schon mal gesehen?
Und zwar ist das ein Kodierungsproblem. Hier findest du alles Weitere dazu, ich erkläre es dir aber in Kürze (naja, nicht ganz so kurz 😉 ) in diesem Artikel.
Was ist da los?
Bis vor einiger Zeit, vor der Internationalisierung, wurde für jedes Land eine eigene Kodierung (also ein eigener Zeichensatz / Zeichentabelle) verwendet, auch „Charset“ genannt. Dadurch versuchte man Speicher zu sparen, da in diesen Kodierungen nur die Buchstaben vorhanden waren, die in der jeweiligen Sprache überhaupt vorkommen.
Wenn Frau Meier aus Berlin an Herrn Schmitt in Hamburg eine E-Mail schreibt ist es unwahrscheinlich, dass da chinesische Schriftzeichen drin sind, also muss man die auch nicht laden/speichern. Bei uns war/ist dieses Charset für lateinische Schriftzeichen „ISO-8859-1″ (auch „latin1“ genannt).
Inzwischen sind die wenigen Byte unerheblich geworden und moderne Systeme nutzen einfach UTF-8, auch Unicode genannt. In dieser Tabelle sind (fast) alle Zeichen aller Sprachen enthalten. Das U steht dabei für „Universal Character Set“, frei übersetzt „Allgemeine Zeichentabelle“. Es gibt auch noch UTF-16 und UTF-38 für asiatische Zeichen usw., aber meistens wird UTF-8 eingesetzt.
Wichtig zu wissen ist, dass die Kodierung zweimal „hinterlegt“ wird:
- Die Zeichen im Text werden kodiert bzw. die Kodierung angegeben
- Die Datei selbst wird im entsprechenden Format gespeichert und ausgegeben
Wenn das beides übereinstimmt: Kein Problem.
Wenn aber z.B. die Zeichen in der Datei UTF-8-Zeichen sind und die Datei mit latin1 gespeichert wird, kann der Webserver das nicht richtig auslesen. Weil UTF-8 zur „Markierung“ drei Byte vorwegstellt und latin1 diese nicht „versteht“ entstehen diese drei kryptischen (und gefürchteten) Zeichen  – die Byte Order Mark.
Konkret auf eine Webseiten-Situation bezogen:
- Die Webseite hat im Meta-Tag (im HTML) angegeben, dass sie nach latin1 codiert ist, also dass der Browser latin1-Zeichen erwarten kann:
- Eine der PHP- oder Template-Dateien wurde aber im UTF-8 Format gespeichert. Wenn diese nun eingebunden oder ausgelesen wird, kündigt diese mit dem BOM an: „Hallo, ich bin UTF-8 kodiert“.
- Diese freundliche Ankündigung versteht der Browser aber nicht, sondern er versteht nur: „Hrrrggzl mpppffth harrr!“ und gibt das entsprechend aus, da er denkt, das die Webseite mit dir spricht, statt mit dem Browser.
Was heißt das nun?
Eine der Dateien, die zum Zusammenbauen der Seite verwendet wird, ist eine UTF-8 Datei, und damit nicht mehr kompatibel mit dem Rest des Systems. Dadurch wird der BOM als Text dargestellt, was z.B. PHP aus der Bahn werfen kann, denn manchmal erwarten PHP-Scripte, dass keine Ausgabe erfolgt, bis PHP komplett den Code abgearbeitet hat.
Diese Scripte brechen dann mit dem „Fatal-Error“ ab und die Seite ist quasi kaputt.
Die gesamte Codierung der Webseite über den Meta-Tag auf UTF-8 zu ändern bringt leider auch nichts, da der Browser dann zwar generell UTF-8 erwartet, aber eben auch die als latin1 gespeicherten Dateien als UTF-8 wertet — und keine Umlaute, Sonderzeichen usw. anzeigt. Diese werden dann als Fragezeichen oder kryptische Symbole angezeigt, da sie ja in latin1 so nicht existieren. Lediglich die UTF-8-Datei würde korrekt angezeigt (bzw. der BOM verschwinden), aber das ist ja dann auch Blödsinn, wenn kein „ä“, „ö“, „ü“, „ß“ usw. mehr angezeigt werden.
Also, was tut man da?
Wenn du Zugriff auf den Server und damit die Shell (bei Linux) hast, kann man mit Tools wie „iconv“ eine massenhafte Umkodierung und Neuspeicherung der Dateien anstoßen. Das Tool ruft dann jede Datei einzeln auf, konvertiert sowohl Zeichen als auch Dateiformat in ein Charset deiner Wahl. Meist lässt sich damit der Übeltäter ausmachen und eliminieren — aber leider auch nicht immer.
Wenn das nicht der Fall ist, und du nur über FTP-Zugriff o.ä. verfügst, wird es haarig. Dann sollte man sich überlegen: Welche Dateien habe ich als letztes verändert und gespeichert? Welche Dateien werden auf der Seite überhaupt eingebunden?
Es führt dann nichts daran vorbei, jede dieser Dateien zu öffnen und wieder mit dem korrekten Charset zu speichern (z.B. kann der Windows Editor „Notepad“ das).
Oder man lädt alle Dateien runter, nutzt iconv auf Linux/Mac (oder ein ähnliches Tool für Windows), und lädt alles wieder hoch. Es kann aber sein, dass auch das nicht hilft.
Versuch’s mal mit Notepad…
Wenn du also eine grobe Ahnung hast, welche Datei(en) als letztes vor dem Auftreten des BOM verändert wurden, wäre es nicht schlecht diese mal testweise mit Notepad neu zu speichern.
1. Start > „notepad“ eingeben > Enter
2. Entsprechende Datei öffnen
3. Datei > Speichern unter…
4. Unten findet sich das Feld „Codierung“, dort dann in dem Fall „latin1“ auswählen
5. Datei hochladen und Daumen drücken
…und versuch’s mal generell mit UTF-8!
Generell empfiehlt sich übrigens UTF-8 zu nutzen. Und das einheitlich. Dann gibt es auch keine Probleme mehr – und internationale Besucher freuen sich auch, dass sie z.B. Kommentare mit internationalen Schriftzeichen hinterlassen können 😉
Außerdem kann man sich, wie bei meinen Klienten schon oft geschehen, datenbanktechnisch ins Aus schießen, wenn man irgendwann gezwungen wird, UTF-8 zu nutzen.