Zeichenkodierung (Charset) prüfen
Die Zeichenkodierung legt fest, für welche Buchstaben die Bytes Ihrer Seite stehen. Wird sie falsch oder gar nicht angegeben, zerfällt Text mit Sonderzeichen: Aus "güzel" wird "güzel". Dieses Werkzeug prüft nicht nur, ob die Angabe vorhanden ist, sondern auch, ob sie innerhalb der ersten 1024 Bytes steht, ob sie dem HTTP-Header widerspricht und ob im Seitentext tatsächlich kaputte Zeichenfolgen vorkommen.
Die Angabe zu prüfen genügt nicht, man muss das Ergebnis prüfen
Die meisten Zeichensatz-Prüfer finden ein charset-Tag auf der Seite und geben sich damit zufrieden. Der größte Teil kaputter Zeichen stammt jedoch nicht aus einer falschen Angabe, sondern aus Inhalten, die von vornherein kaputt gespeichert wurden. Wurde der Text einmal in falscher Kodierung in die Datenbank geschrieben, sieht er weiterhin kaputt aus, ganz gleich was Ihre Seite angibt. Deshalb durchsucht dieses Werkzeug neben der Angabe auch den Seitentext und zählt die typischen Zeichenfolgen kaputter Kodierung (ü, ÅŸ, Ä°, ’ und dergleichen). Stimmt die Angabe, ist der Text aber kaputt, liegt das Problem im Inhalt, in der Kodierung der Datenbankverbindung oder in einem Import- bzw. Exportschritt.
Die 1024-Byte-Regel
Die HTML-Spezifikation verlangt, dass die Angabe der Zeichenkodierung innerhalb der ersten 1024 Bytes des Dokuments VOLLSTÄNDIG ist. Der Grund ist einfach: Der Browser liest das Dokument von vorn und kann es ohne Kenntnis der Kodierung nicht auswerten. Kommt die Angabe zu spät, beginnt der Browser mit einer Vermutung; ist die Vermutung falsch, muss er die Auswertung abbrechen und neu beginnen. Das bedeutet vergebliche Arbeit und die Gefahr entstellter Zeichen. Beachten Sie, dass die Grenze in BYTES gemessen wird, nicht in Zeichen: lange Kommentare im <head>, eingebettete Stilblöcke oder ein Stapel Meta-Tags verbrauchen das Budget schnell. Der richtige Platz ist unmittelbar nach dem Öffnen von <head>.
Rangfolge: BOM, HTTP-Header, dann meta
Die Kodierung kann an drei verschiedenen Stellen angegeben werden, und bei Widerspruch steht die Reihenfolge fest. Ganz oben steht die Bytereihenfolge-Markierung (BOM) am Dateianfang. Darunter kommt der vom Server gesendete HTTP-Header Content-Type. Ganz unten steht das meta-Tag auf der Seite. Diese Reihenfolge ist die Quelle einer sehr verbreiteten Verwirrung: Eine Entwicklerin sieht ein UTF-8-Tag im Quelltext, doch wenn der Server etwas anderes angibt, hört der Browser auf den Server, und das Tag bewirkt gar nichts. Dieses Werkzeug vergleicht beide Angaben und sagt Ihnen bei Widerspruch, welche tatsächlich gilt.
Warum UTF-8?
Ältere Kodierungen wie ISO-8859-1, ISO-8859-9 oder windows-1254 können die Buchstaben einer bestimmten Sprache durchaus tragen. Damit endet ihre Reichweite jedoch: Emoji, mathematische Symbole, Zitate in anderen Alphabeten und sehr viele typografische Zeichen lassen sich schlicht nicht darstellen. UTF-8 trägt all das in einer einzigen Kodierung und ist heute die gemeinsame Grundlage des Webs. Beim Wechsel von einer älteren Kodierung zu UTF-8 ist eines zu beachten: Nur das Tag zu ändern repariert den Text nicht, es zerstört ihn. Der Inhalt selbst muss ebenfalls neu kodiert werden.
Wie entstehen kaputte Zeichen (Mojibake)?
Die Bytes werden nicht beschädigt; kaputt geht die Regel, nach der sie gelesen werden. Das häufigste Muster ist, dass als UTF-8 geschriebener Text als Latin-1 gelesen wird. In UTF-8 besteht der Buchstabe "ü" aus zwei Bytes; liest man diese beiden Bytes einzeln als Latin-1, erscheinen sie als "ü". Dieses Werkzeug sucht genau nach solchen Signaturfolgen im Seitentext und meldet, wenn es sie findet, dass das Problem im Inhalt liegt und nicht in der Angabe.
Ihre Fragen
Häufig gestellte Fragen
Wohin gehört das charset-Tag?
Unmittelbar nach dem Öffnen von <head>, am besten in der ersten Zeile. Die Angabe muss innerhalb der ersten 1024 Bytes des Dokuments abgeschlossen sein, und lange Kommentare oder eingebettete Stile im <head> können dieses Budget aufbrauchen und das Tag über die Grenze schieben.
Wenn der HTTP-Header einen Zeichensatz nennt, brauche ich dann noch das meta-Tag?
Technisch nein, der Browser hört auf den Header. Es zu setzen ist trotzdem zu empfehlen: Die Angabe verschwindet, wenn die Seite als Datei gespeichert und lokal geöffnet wird oder wenn der Header auf einer Zwischenschicht verloren geht. Es ist eine Zeile Versicherung. Achten Sie nur darauf, dass beide DENSELBEN Wert angeben.
Meine Seite sagt UTF-8, doch Umlaute sind weiterhin kaputt. Warum?
Die Angabe kann stimmen, während der Inhalt kaputt gespeichert wurde. Wurde der Text einmal in falscher Kodierung in die Datenbank geschrieben, repariert ihn eine UTF-8-Angabe auf der Seite nicht. Die zweite Möglichkeit: Der HTTP-Header gibt eine andere Kodierung an und übergeht Ihr meta-Tag. Dieses Werkzeug unterscheidet beides: Zählt es kaputte Zeichenfolgen im Text, liegt das Problem im Inhalt; meldet es einen Widerspruch, liegt es in der Angabe.
Ich nutze eine ältere Kodierung. Sollte ich auf UTF-8 wechseln?
Ja, aber gehen Sie den Umzug sorgfältig an. Nur das Tag zu ändern zerstört den vorhandenen Text; der Inhalt muss ebenfalls neu kodiert werden. Die Datenbank, die Zeichensätze von Tabellen und Spalten, die Kodierung der Verbindung, die Kodierung der Vorlagendateien selbst und der Server-Header müssen gemeinsam behandelt werden. Nach dem Umzug können Sie mit diesem Werkzeug bestätigen, dass im Text keine kaputten Zeichenfolgen mehr stehen.
Ist eine BOM schädlich?
Für den Browser nicht; im Gegenteil, sie legt die Kodierung endgültig fest und steht in der Rangfolge ganz oben. Probleme entstehen auf der Serverseite: In manchen Sprachen sickert die BOM als unsichtbares Zeichen an den Anfang der Ausgabe und verursacht Fehler wie \"headers already sent\" oder unerwarteten Leerraum am Seitenanfang. Dateien als UTF-8 ohne BOM zu speichern ist die verbreitete Wahl.
Prüft dieses Werkzeug meine ganze Website?
Nein, es prüft die eine Seite, die Sie eingeben. Kodierungsprobleme betreffen meist die ganze Website, können aber auch auf einzelne Inhalte aus der Datenbank beschränkt sein. Um alle Seiten zu prüfen, verwenden Sie unser Werkzeug Deep Crawl.