UTF-8 und die Umstellung von Websites auf dieses Encoding

Teil 2: UTF-8 für alle
Kommentare

Wir wollen nun Schritt für Schritt die Punkte durchgehen, die Sie beachten müssen, um ein konsistentes UTF-8-Encoding Ihrer Webprojekte zu erreichen. Dabei ist es unwesentlich, ob Sie ein bestehendes Webprojekt umstellen oder ein neues erstellen möchten.

Dokumente in UTF-8 speichern Für eine durchgängige Verwendung von UTF-8 ist es Voraussetzung, dass alle Dokumente Ihrer Website, die Text enthalten (*.html*.php*.css), UTF-8-kodiert gespeichert werden. Nur so werden alle Sonderzeichen im korrekten Code gespeichert, und kryptische Zeichen werden von Anfang an vermieden. Vorsicht, nicht alle Editoren „sprechen“ UTF-8. Öffnen und bearbeiten Sie Ihre Dokumente nur noch mit Editoren, die es tun. In manchen Editoren lässt sich die Zeichenkodierung beim Speichern auswählen, bei anderen gibt es eine entsprechende Option in den Programmeinstellungen. Bestehenden Dokumente müssen mit einem UTF-8-fähigen Editor geöffnet und in UTF-8 gespeichert werden. Kontrollieren Sie anschließend noch einmal alle Umlaute und Sonderzeichen der Dokumente und korrigieren sie Sie bei Bedarf. Manchmal wird den Dokumenten beim Speichern in UTF-8 ein Byte Order Mark (BOM) vorangestellt. Wenn das in Ihrem Editor optional ist, lassen Sie es weg, denn es ist bei UTF-8 nicht zwingend nötig (siehe Kasten: „UTF-8 und BOM“).
Textlaufrichtung festlegen Auf einer UTF-8-formatierten Website sind internationale Zeichen möglich und werden fehlerfrei angezeigt, solange im Client die erforderlichen Schriftarten installiert sind. Somit ist es bei benutzergeneriertem Content auch möglich, dass Texte fremder Sprachen eingegeben werden, bei denen der Text nicht von links nach rechts, sondern von rechts nach links läuft (z. B. Hebräisch). So kann es passieren, dass der Browser, sobald er ein hebräisches Zeichen im Content entdeckt, geneigt ist, die Textlaufrichtung zu ändern. In (X)HTML lässt sich das durch Setzen des dir-Attributs im HTML-Tag unterbinden. Mit dir=“ltr“ legen Sie fest, dass der Text immer von links nach rechts läuft. In CSS-Dateien fügen Sie eine einzige Zeile ganz am Anfang ein: @charset „utf-8“;.

UTF-8 in (X)HTML und CSS-Dokumenten

Sie sollten den (X)HTML-Dokumenten die Information zur verwendeten Zeichenkodierung in den Metatags im HTML-Header mitgeben. Das entsprechende Metatag lautet für HTML  und für XHTML <meta http-equiv=“content-type“ content=“application/xhtml+xml;charset=utf-8″ //ht;. Zusätzlich kann in XHTML-Dokumenten die Kodierung auch in der XML-Deklaration erwähnt werden. Das ist zwar nicht unbedingt nötig, da XHTML immer UTF-8 kodiert ist, aber es schadet auch nicht: . Im HTML-Tag können Sie dem Client (Browser) Informationen über die auf der Website verwendete Sprache übergeben. Dazu wird der ISO-Code der Spracheangegeben. Für XHTML sieht die Zeile dann so aus: <html xmlns=“http://www.w3.org/1999/xhtml“ xml:lang=“de“ lang=“de“ dir=“ltr“>. Das dir-Attribut am Ende dieses HTML-Tags legt übrigens die Textlaufrichtung fest (ltr = left-to-right, von links nach rechts). Das ist auf UTF-8 kodierten Websites mit benutzergeneriertem Content empfehlenswert (siehe Kasten: „Textlaufrichtung festlegen“).

Webserver und HTTP-Header

Über eine entsprechende Direktive können wir Apache explizit anweisen, unsere Daten und Dokumente nur noch in UTF-8 auszuliefern. Dazu sind folgende Zeilen in der .htaccesseinzufügen: AddCharset utf-8 .css .html .xhtml .php. Ergänzen Sie die Zeile einfach um die Extensions aller weiteren Dateitypen, die Sie von Ihrem Webserver ausliefern und die Text enthalten. Der führende Punkt vor den Extensions ist optional, die Extension-Angabe ist Case-sensitive. Das funktioniert allerdings nur, wenn Ihr Webhoster das Überschreiben des Charsets erlaubt hat. Alternativ können Sie per PHP einen HTTP-Header an den Browser liefern, der diesem bereits vor dem Empfang der eigentlichen HTML-Seite mitteilt, dass die gelieferten Daten in UTF-8 sind: header(‚content-type: text/html; charset=utf-8‘);. Falls Sie Zugriff auf die php.ini haben, können Sie die Einstellung auch dort vornehmen:
default_mimetype = "text/html"
default_charset = "utf-8"

MySQL-Datenbanken

Bei Datenbanken macht die Regel der konsistenten Zeichensatzkodierung eine Ausnahme. Zwar lässt sich eine MySQL-Datenbank (ab Version 4.1.1) auf UTF-8 umstellen, das ist aber in den meisten Fällen nicht notwendig und dann auch nicht empfehlenswert. Während sprachspezifische ISO-Kodierungen pro Zeichen eine Länge von einem Byte umfassen, „frisst“ UTF-8 in MySQL bis zu drei Byte pro Zeichen. Das hat natürlich Auswirkungen auf Speicherplatzbedarf und Performance. MySQL unterscheidet Character Set (Charset) und Kollation. Das Charset ist das Encoding, während die Kollation die Sortierung der Daten regelt. Beide stehen in enger Beziehung, d. h. nicht jedes Charset macht mit jeder Kollation Sinn (die möglichen Kombinationen können Sie INFORMATION_SCHEMA..COLLATION_CHARACTER_SET_APPLICABILITY entnehmen). Für UTF-8 kennt MySQL das Charset ‚utf8‘ und die Kollation ‚utf8_general_ci‘. Sie finden alle Encodings, die MySQL kennt, in INFORMATION_SCHEMA.CHARACTER_SETS. Die Spalte Maxlen gibt übrigens an, wie viele Bytes ein Zeichen dieses Zeichensatzes maximal verbraucht. Die Kollation, und damit das zu verwendende Charset, wird von oben nach unten vererbt. Jede Spalte, die Text-, Char- oder Varchar-Werte enthält, hat automatisch eine Kollation und ein Charset, die sie von ihrer Tabelle erbt, wenn es nicht explizit anders angegeben ist. Diese wiederum erbt standardmäßig die Kollation die Datenbank, und diese wiederum die Default-Kollation. UTF-8 macht in MySQL nur Sinn, wenn eine Spalte Zeichen verschiedener (!) Sprachen enthält. Dann sollten diese – und nur diese – Spalten die Kollation utf8_general_ci zugewiesen bekommen. In allen anderen Fällen ist es günstiger, die passende ISO-Kodierung zu verwenden, da sie wesentlich sparsamer mit den verfügbaren Ressourcen umgeht. Um mit einer ISO-kodierten MySQL-Datenbank und einem UTF-8-Client fehlerfrei zu arbeiten, genügt die Angabe eines einzigen SQL-Statements direkt nach Herstellung der Datenbankverbindung (vor dem ersten Datentransfer): SET names ‚utf8‘. Damit weiß MySQL, dass der Client UTF-8 spricht und wandelt die Daten selbständig um. Wenn Sie dieses Thema vertiefen möchten, sei Ihnen ein Beitrag von Kristian Köhntopp empfohlen.
UTF-8 und BOM Das BOM (Byte Order Mark) ist eine Unicode-Signatur, die UTF-8-kodierten Dateien vorangestellt sein kann. Im Gegensatz zu UTF-16 und UTF-32, wo das BOM für eine korrekte Darstellung der Inhalte notwendig ist, ist es bei UTF-8 jedoch optional, sodass nur einige Editoren es speichern. In manchen lässt sich sogar auswählen, ob eine Unicode-Signatur mitgespeichert werden soll. Nicht alle Anwendungsprogramme interpretieren das BOM in UTF-8 korrekt, in solchen Programmen (auch Browsern) wird am Anfang der Datei eine Leerzeile oder auch die Zeichenfolge  dargestellt. Das liegt daran, dass der verwendete Code U+FEFF ursprünglich für ein Leerzeichen stand. Eine ausführliche Information und Handlungsempfehlungen.

Daten-Upload und Verarbeitung mit PHP

Für eine konsistente Kodierung ist es besonders wichtig, benutzergenerierte Inhalte in UTF-8 umzuwandeln bzw. UTF-8 zu erzwingen. Daten, die aus Formularen an den Webserver gesendet werden, sind in der Regel genauso kodiert wie die Seite, in der das Formular eingebettet ist. Es schadet aber nicht, dem Formular mit dem Attribut accept-charset=“UTF-8″ die Kodierung zusätzlich mitzuteilen. Trotzdem sollten alle eingehenden Daten zusätzlich auf ihre Kodierung überprüft werden. Irgendwas kann schließlich immer schiefgehen. Das gilt insbesondere für Upload-Daten (z. B. CSV-Dateien), die von der Webanwendung weiterverarbeitet werden sollen. Das W3C hat eine Regular Expression veröffentlicht, mit der sich ermitteln lässt, ob ein Text UTF-8-kodiert ist (Listing 1). Alternativ kann die Funktion mb_detect_encoding verwendet werden, die das Encoding des übergebenen Strings ermittelt. Weiter mit: Teil 3 Alle Teile: Teil 1, Teil 2, Teil 3
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -