Zeichensalat bei Google – So wird der Fehler behoben

geschrieben am in der Kategorie SEO von

Ab und an stößt man im Netz auf falsch dargestellten Zeichensalat. Umlaute weichen dabei nichtssagenden Zeichen – im Beispiel einer Raute mit Fragezeichen. Grund für dieses Phänomen sind inkonsistente Daten oder fehlerhafte Informationen zum Zeichensatz der Seite, die an den Browser gesendet werden. Für die Indexierung bei Google wirkt sich dieser Fehler sehr nachteilig aus, denn im Gegensatz zu anderen Suchmaschinen wird der Zeichensalat bei Google nicht selten einfach übernommen.

Falsch dargestellte Zeichen bei Google

Ärgerlich für die Außendarstellung: Google übernimmt falsch dargestellte Zeichen einfach in das SERP-Snippet

 

Hintergrund: Was hat es mit dem Zeichensatz auf sich?

Elektronische Datenverarbeitung denkt immer binär. Alle Informationen werden übersetzt und in Form von Einsen und Nullen verarbeitet. Buchstaben sind für diese Systeme letztlich nur Bilder, denen zur Verarbeitung ein Zahlenwert zugeordnet wird. Welche Zahl dabei für welches Zeichen steht, bestimmt der Zeichensatz. Diesen kann man sich als Tabelle vorstellen, die jedem Zeichen eine eindeutige Zahl zuordnet. In den Anfängen der Computertechnik wurde mit sehr kleinen Zeichensätzen gearbeitet, die lediglich Buchstaben, Ziffern, Interpunktionszeichen sowie einige wenige Sonderzeichen umfassten. Da unterschiedliche Sprachen unterschiedliche Zeichensets benötigen, wurden unterschiedlichste Zeichensätze entwickelt und verwendet. Diese verwenden jeweils abweichende Zeichenkodierungen, ordnen also gleichen Zahlencodes verschiedene Zeichen zu. Werden Daten mit dem falschen Zeichensatz interpretiert, kommt es schließlich zur Ausgabe falscher Zeichen, die den Zeichensalat verursachen.

Beispiel:
Im ISO-8859-1-Zeichensatz hat der Buchstabe Ü den Wert 220. Der gleiche Wert steht im EBCDIC Zeichensatz allerdings für eine geschweifte Klammer: }.

Der richtige Zeichensatz für das eigene Projekt

Im Netz hat sich der UTF-8 Zeichensatz mittlerweile als Quasi-Standard etabliert. Dieser Zeichensatz ist mit anderen, früher häufig verwendeten Zeichensätzen in gewissem Umfang kompatibel und erlaubt gleichzeitig auch die Wiedergabe von Zeichen anderer Sprachen. Auch wenn Browser mit unterschiedlichsten Zeichensätzen umgehen können, empfiehlt sich der Einsatz von UTF-8.
Bei der Formatierung einer Website in einem bestimmten Zeichensatz ist es wichtig, dass diese Formatierung konsequent durchgehalten wird. An den folgenden drei Stellen können Angaben zum Zeichensatz hinterlegt sein.

1. Byte-order mark (BOM), sog. UTF Signatur einer Datei
Hierbei handelt es sich um ein einzelnes Zeichen am Dateianfang, dass lediglich bei utf-formatierten Dateien vorkommt. Dieses Zeichen genießt die höchste Priorität und überspielt die Angaben unter Punkt 2 und 3. Ein moderner Browser wird bei Existenz eines UTF-8-BOM die folgenden Daten immer mit dem UTF-8 Zeichensatz interpretieren.
Weiterführende Informationen dazu findet man unter http://www.w3.org/International/questions/qa-byte-order-mark

2. HTTP Header
Jedes Dokument enthält einen sogenannten Header, der Informationen über die folgenden Daten enthält. So auch bei den Dokumenten, die ein Webserver an einen Browser schickt. Im Content-Type kann dabei der Zeichensatz angegeben werden, mit dem die nachfolgenden Daten interpretiert werden sollen.
Die Angaben im HTTP Header überschreiben die Definition im Meta-Tag. (Punkt 3)

HTTP Header im Content-Type

Beispiel eines HTTP Headers von w3.org

3. Meta Angaben im HTML
Seit dem HTML 5 Standard ist für das Meta-Tag ein charset-Attribut vorgesehen, das ebenfalls den Zeichensatz für die Daten im folgenden HTML Dokument definieren kann. Bei schlichten HTML Dokumenten kann die Zeile verwendet werden. Kommt der XHTML Standard zum Einsatz, so muss die Zeile zum Einsatz kommen.

Während sich die Definition des Zeichensatzes in den Meta Angaben leicht aus dem Quelltext lesen lässt, muss man für einen Einblick in den HTTP Header sowie für die Information über die Existenz eines UTF BOM auf diverse Tools zurückgreifen. Sehr nützlich ist hier beispielsweise der Internationalization Checker von w3.org: http://validator.w3.org/i18n-checker/ Dieser zeigt schnell, welcher Zeichensatz an jeder der drei benannten Stellen definiert wird.

Oberfläche W3C Internationalization Checker

Mit dem W3C Internationalization Checker sind die definierten Zeichensätze schnell gefunden.

Es ist nicht wichtig, dass an allen drei Stellen ein Zeichensatz definiert wird. Die Angabe im HTTP Header oder im Meta-Tag ist völlig ausreichend. Auch wenn klare Prioritäten festgelegt sind, sollte man jedoch darauf achten, dass die Zeichensatzdefinition – wenn vorhanden – an allen Stellen konsistent ist, denn manch eine Software (z.B. der leider immer noch nicht ausgestorbene Internet Explorer) entwickelt so ihre Eigenheiten. Sollten sich die Zeichensatz-Definitionen unterscheiden, können folgende Stellen dafür verantwortlich sein:

1. Für das byte-order mark (BOM)
Dieses Zeichen entsteht in der Regel beim Speichern einer Datei. Während ein guter Text- bzw. Codeeditor in den Einstellungen konfiguriert werden kann und sich somit flexibel gibt, existiert diverse Software (u.a. wieder aus dem Hause Microsoft), die dieses BOM immer schreibt.

2. Für den HTTP Header
Der HTTP Header wird vom Webserver geschrieben und kann an verschiedenen Stellen definiert werden. Bei dem recht häufig verwendeten Apache Webserver muss auf die Dateien apache.conf, charset.conv sowie die httpd.conf aus dem config Verzeichnis geachtet werden. Darüber hinaus ist es auch möglich, den Zeichensatz für ein einzelnes Verzeichnis oder ausgewählte Dateiendungen in der Konfigurationsdatei .htaccess zu definieren.

3. Für die Meta Angaben im HTML
Diese Angabe wird direkt im Quellcode vorgenommen und sonst von keiner anderen Instanz beeinflusst. Hat man die entsprechende Codezeile gefunden ist das charset-Attribut im Meta-Tag somit schnell geändert.

Ist der Zeichensatz an allen Stellen richtig definiert, kann es trotzdem weiterhin zum Phänomen des Zeichensalats kommen, denn es genügt nicht, dem Browser nur einen Zeichensatz vorzugeben. Wichtig ist, dass alle Daten auch tatsächlich im definierten Zeichensatz kodiert wurden. In Zeiten dynamischer Webseiten mit hochkomplexen Content Management Systemen im Hintergrund gibt es zahlreiche Fehlerquellen:

1. Konfiguration der Programmiersprache
Jede dynamische Webseite arbeitet mit einer Programmiersprache im Hintergrund. Besonders serverseitige Programmiersprachen müssen häufig richtig konfiguriert sein, damit sie ihre Daten im richtigen Zeichensatz kodieren. Bei der häufig verwendeten Programmiersprache PHP sind die Einstellungen in der php.ini vorzunehmen.

2. Konfiguration der Datenbanken
Auch Datenbanken müssen mit dem richtigen Zeichensatz angelegt und auch mit Daten im korrekten Format beschrieben werden. Andernfalls sind Zeichenfehler – im wahrsten Sinne des Wortes – vorprogrammiert.

3. Code- und Textdateien
Jede Datei, die Quellcode beinhaltet oder Informationen bereitstellt, die später an einer Stelle in die Webseite importiert werden, kann in einem anderen Zeichensatz abgespeichert worden sein. Wird das nicht beachtet, können sich schnell an vielen Stellen Fehler einschleichen, die dazu führen, dass Zeichen mit falscher Kodierung ihren Weg in die Webseite finden. Zur Vermeidung sollte man genau auf die Einstellungen des verwendeten Code Editors achten.

Stolpersteine für Zeichensatzfehler gibt es viele. Wenn bei der Programmierung und dem Setup einer neuen Seite nicht von vornherein auf Konsistenz geachtet wurde, kann die Fehlersuche einiges an Nerven kosten. Hier hilft nur systematisches Vorgehen und Berücksichtigung aller Punkte, die in diesem Beitrag erläutert wurden. Manchmal, wie im Beispiel des Shops, sieht die eigentliche Webseite völlig korrekt aus. Hier scheinen lediglich die Meta Daten aus einer Datenbank oder anderen externen Quelle zu stammen, die ihrerseits nicht im korrekten Zeichensatz angelegt wurden. Der Fehler ist sicher schnell behoben. Der Nachteil für die Außendarstellung und die Klickraten bei Google ist bis zur Korrektur sicher nicht unerheblich.

Hannes war von März 2014 bis Juli 2016 Teil des Projecter Teams.

Einen Kommentar schreiben

* Pflichtfelder

  1. vielen Dank für den spannenden Artikel!

  2. Hallo, 🙂

    erstmal danke für den netten Beitrag.
    Ich hatte lange Zeit das Problem, dass mir von einigen Optimierungs-plattformen ein UTF8 Fehler angezeigt wurde, da ich das „UTF“ im Meta Tag groß geschrieben habe.
    Macht es überhaupt einen Unterschied? sind Meta Tags case sensitive?

    Lg und bis bald.

    • Hallo Chris,

      das Phänomen habe ich bisher noch nicht beobachtet. Wenn ich den Zeichensatz definiert habe, dann allerdings immer klein.
      Auf http://www.edition-w3.de/TR/1999/REC-html401-19991224/references.html#ref-IANA unter [CHARSET] gab es mal eine Liste mit den korrekten Definitionen von offizieller Stelle. Leider führt der ftp Link nicht mehr zum Ziel. Die Definitionen vom w3 Konsortium legen jedenfalls die HTML Standards fest.

      Von den Defintionen kann natürlich jede Client- und Serversoftware abweichen. Manch ein Apache-Derivat unter Windows akzeptiert auch einen Backslash in Pfadangaben. *grusel* 😉
      Und der Internet Explorer nähert sich erst seit den neusten Versionen langsam den definierten Standards an. Wäre auch zu schön um wahr zu sein, wenn sogenannte Standards auch wirklich Standards wären.

      Viele Grüße
      Hannes