• Einführung
• Das Problem
• Unicode
• Die Praxis
• Grundlegendes
• • Zum Seitenanfang
  • Betriebssysteme
  • Vorgaben des W3C
  • Tipps
  • Problemzonen
  • Test Szenarios
• Programmiersprachen
• Server
• Anwendungen
• Links
• Impressum
• Datenschutz

Grundsätzliches zum Umgang mit Encoding

Wer Verständnisschwierigkeiten mit der Encoding-Problematik hat, kann sich vielleicht damit trösten, dass auch die Verantwortlichen nicht immer sofort den besten Ansatz gefunden haben. In Anbetracht sich teilweise widersprechender Informationen und Empfehlungen bleibt festzuhalten, dass der Trend ganz offensichtlich in Richtung UTF-8 geht. War in älteren Dokumenten noch oft von ISO-8859-1 als Defaultwert die Rede, wurde die Überlegenheit des konzeptionellen Ansatzes von Unicode mittlerweile offensichtlich erkannt. Es ist jedoch leider z.T. wirklich schwer herauszubekommen, welche Vorgaben die Standardisierungsgremien denn nun wirklich machen.

Betriebssysteme

Manche Betriebssysteme (z.B. unix-artige) bieten verschiedene Konfigurationsmöglichkeiten zum Einstellen des grundsätzlich verwendeten Encodings an. Diese Einstellung beeinflusst das Verhalten eines Systems in mancherlei Hinsicht:

• Sie legt fest, welche Zeichen in Dateinamen erlaubt sind. Das kann insbesondere für automatisch erzeugte Dateinamen hinderlich sein. Davon sind dann natürlich auch die entsprechenden Schnittstellen in den Programmiersprachen betroffen, z.B. beim Erzeugen von Dateinamen oder beim Auslesen des Inhalts eines Verzeichnisses.
• Sie nimmt Einfluss auf den Ablauf bestimmter Programme. Manche Programmiersprachen (z.B. Java) fallen auf das Default-Encoding des Betriebssystems zurück, wenn der Programmierer keine expliziten Vorgaben macht.

Wenn das Betriebssystem diese Einstellungsmöglichkeit bietet, sollte man auf jeden Fall das Default-Encoding auf eine Unicode-Repräsentation einstellen. Natürlich kann das dazu führen, dass in der Vergangenheit angelegte Dateien mit Umlauten oder Sonderzeichen im Namen nun vom Betriebssystem nicht mehr fehlerfrei angezeigt werden können. Das betrifft dann sowohl die Anzeige der Datei im Filebrowser als auch die Rückgabewerte der entsprechenden Systemroutinen etwa beim Auslesen eines Verzeichnisse. Bei eigenen Dateien kann man diese natürlich einfach umbenennen. Das Aufspüren der Dateien kann im Bedarfsfall programmatisch erfolgen (etwa mit Hilfe eines Perl-Skripts), eventuell sogar die Umkodierung selbst.

Größere Schwierigkeiten entstehen, wenn manche Fremd-Applikationen (sprich: installierte Programme) in ihren Dateinamen etwa Copyright oder andere Sonderzeichen verwenden. Ein Umkodieren könnte in diesem Fall die Funktionstüchtigkeit der Applikation gefährden. Hier gilt: Ausprobieren (Backup nicht vergessen) und gegebenenfalls beim Hersteller der Software beschweren.

Die meisten Linux-Distributionen werden heutzutage mit UTF-8 als Default-Encoding ausgeliefert, hier besteht im allgemeinen kein Handlungsbedarf. Nähere Informationen gibt es etwa in dem leider nicht mehr ganz aktuellen Linux HowTo aus dem Jahre 2001(!) oder dieser FAQ-Sammlung.

Leider kann ich zu anderen Betriebssystemen nur wenig Aussagen machen, es ist aber zu erwarten, dass sowohl Solaris als auch die verschiedenen BSD-Betriebssysteme UTF-8 gut unterstützen. Ähnliches gilt natürlich auch für MacOS X mit seinem BSD-Unterbau. Zum Thema Windows Betriebssysteme liegen mir leider keine Informationen vor.

Vorgaben und Empfehlungen aus dem Umfeld des W3C

Obwohl UTF-8-kodierte Zeichen im Gegensatz etwa zu UTF-16 unabhängig von der Byteordnung (Endianness) sind, erlaubt die XML-Spezifikation explizit einen Byte Order Marker (BOM) auch für UTF-8 kodiertes XML. Es ist jedoch nicht empfehlenswert, diesen für UTF-8 zu verwenden: er wird nicht benötigt und kann allenfalls Probleme verursachen.

Eine URL darf ausschließlich ASCII-Zeichen enthalten. In RFC 2718 wird empfohlen, Sonderzeichen in einer URL, die nicht in ASCII darstellbar sind, mittels %HH byteweise zu kodieren, wobei HH die Hexadezimaldarstellung eines Bytes der UTF-8-Kodierung eines Sonderzeichens ist. Ein ä in UTF-8 müsste somit folgerichtig in einer URL als %C3%A4 (zwei Bytes) kodiert werden. Leider ist in der URI-Spezifikation (die auch URLs umfasst) RFC 2396 aus historischen Gründen nicht explizit festgelegt, in welcher Kodierung die Hexadezimaldarstellung von Nicht-ASCII-Zeichen vorzunehmen ist. Siehe hierzu auch eine Empfehlung des W3C.

In RFC 2396 wird das Nichtspezifizieren der Basis der hexadezimalen %HH Escape-Sequenzen von folgender Bemerkung begleitet:
It is expected that a systematic treatment of character encoding within URI will be developed as a future modification of this specification.

HTTP-GET-Parameter werden in der URL übertragen und dürfen daher auch lediglich ASCII-Zeichen enthalten, Sonderzeichen in den Variablennamen oder -werten sind mittels %HH zu escapen.

HTTP-POST-Parameter können beliebige Zeichen enthalten, auf das verwendete Encoding kann über das Attribut enctype für das <FORM>-Tag Einfluss genommen werden. Laut W3C Recommendation sollten POST-Parameter, die mit enctype="multipart/form-data" verschickt werden, das volle Unicode-Spektrum abdecken können.

Zum Thema GET- und POST-Parameter siehe auch folgendes Dokument.

Im RFC 2616 ist festgelegt, dass bei Nichtspezifizieren des Parameters charset der Wert ISO-8859-1 als Defaultwert für alle Inhalte mit dem Medientyp text angenommen wird. Damit werden also alle HTML-Seiten, in denen das Encoding nicht mit Hilfe des charset-Parameters explizit spezifiziert wird, als ISO-8859-1 kodiert angesehen. Diese Spezifikation stammt aus dem Jahre 1999, ich vermute, dass heutzutage die Wahl auf UTF-8 fallen würde (oder besser gesagt: ich hoffe es).

Grundsätzliche Vorsichtsmaßnahmen zur Vermeidung von Encoding-Problemen

Erster Schritt für den Weg in eine bessere Zukunft mit problemlosem Austausch von Texten zwischen verschiedenen Beteiligten ist eine konsequente Kennzeichnung der Kodierung von Textdateien. Das geschieht heutzutage für High-Level-Dokumente in Textverarbeitungssystemen oder Email-Browsern meist automatisch, gegebenenfalls muss man das Mailprogramm entsprechend konfigurieren. Aber auch bei einfachen Konfigurationsdateien oder kleinen, unformatierten Texten ist es für Leute, die damit arbeiten müssen, immer gut zu wissen, ob man Umlaute oder Sonderzeichen problemlos einfügen könnte. Daher gilt: eine kurze Anmerkung als Kommentar im Kopf der Datei (falls möglich) oder eine kurze Erwähnung der zu verwendenden Kodierung in der Dokumentation ist immer eine gute Idee.

Wenn man Sonderzeichen im Sourcecode verwendet, sollte man sicherstellen, dass niemand beim Editieren versehentlich das Encoding der Source-Datei überschreibt!

Grundsätzlich ist zu bedenken: mit UTF-8 sind theoretisch alle bekannten Zeichen darstellbar, auch alle fernöstlichen Dialekte oder historische Sprachen, wie etwa Keilschrift. Probleme kann es höchstens noch geben, wenn etwa nicht die korrekten Fonts zur Darstellung installiert sind. Entscheidet man sich jedoch für ein ISO-8859-x Encoding, ist das gemeinsame Auftreten bestimmter Zeichen (etwa bestimmter russischer und griechischer Buchstaben) in einem Text nicht möglich. Daher ist UTF-8 zur Datenrepräsentation immer eine gute Wahl!

Manche Sprachen, wie zum Beispiel HTML, haben optionale Tags zur Spezifizierung der verwendeten Kodierung. Es ist eine gute Angewohnheit, diese zu verwenden und explizite Angaben im Quellcode zu machen. Damit erhöht man die Wahrscheinlichkeit, dass die eigene Seite in keinem Browser falsch dargestellt wird, obwohl es an dieser Stelle leider keine hundertprozentige Sicherheit gibt (dazu unten mehr in den Anmerkungen zur Konfiguration eines Webservers).

Bei der Wahl des Texteditors ist es wichtig, darauf zu achten, dass dieser ordentlich mit Unicode-Zeichensätzen umgehen kann. Falls der Editor eine Datei fehlerhaft darstellt, sollte man immer zunächst eine Sicherheitskopie dieser Daten erstellen, bevor man versucht, die Einstellungen im Editor zu ändern oder die Datei nochmals abspeichert. Es kann bei den Umwandlungen von einem Format ins andere (insbesondere bei Interpretation von ISO-8859-1 Zeichen als UTF-8) zu Datenverlust kommen, der nur schwer und von Hand reparabel ist.

Weiterhin ist natürlich eine erhöhte Sensibilität für die angesprochene Problematik vonnöten. Programmiersprachen, die Strings nicht auf einem geeigneten Abstraktionslevel darstellen (können), um dem Programmierer einen Teil der möglichen Probleme abzunehmen, sind besonders fehlerintensiv. Hier hilft nur eiserne Disziplin: wenn man Strings manipuliert, sollte man sich immer der Tatsache bewusst sein, dass ein Zeichen aus mehreren Bytes bestehen kann und entsprechend die speziellen Funktionen bevorzugen. Es gilt: die Darstellung mit einem Byte ist ein Spezialfall eines UTF-8-kodierten Strings und somit funktionieren dann auch die Multibyte Funktionen der Programmiersprache. Das Gleichsetzen von Zeichen (Buchstaben) und Bytes ist hingegen konzeptionell falsch und wird früher oder später zu Problemen führen, wenn man nicht absolut sicher sein kann, dass nur ASCII-Zeichen und bestimmte Sonderzeichen in den Texten vorkommen können.

Eine wesentliche Grundlage für korrektes Handling von Unicode (bei manchen Programmiersprachen sogar die einzige Voraussetzung) ist das korrekte Einlesen der Daten von Festplatte und evtl. das spätere Zurückschreiben. Hier werden von manchen Programmiersprachen (angeblich kluge) Annahmen getroffen, wenn der Benutzer beim Einsatz der IO-Operationen nicht explizit festlegt, in welchem Encoding die Daten vorliegen. Dieses Verhalten erweist sich jedoch nur allzu gerne als Bumerang: viele Programmierer sind sich überhaupt nicht der Tatsache bewusst, dass sie an dieser Stelle besser selber die Entscheidung treffen sollten. Wenn dann dasselbe Programm auf einem anders konfigurierten System seltsame Fehler hervorruft, ist aufwändige Fehlersuche angesagt. So verwendet etwa Java die Heuristik: wenn keine expliziten Angaben gemacht werden, erfolgt das Einlesen einer simplen Textdatei in einem Encoding, das aus den Spracheinstellungen des Betriebssystem geraten wird. Da kann man den Programmierern eigentlich noch nicht mal böse sein, wenn das schiefläuft. In der heutigen Zeit ist ein solches Verhalten einfach nicht mehr angemessen in Anbetracht der zunehmenden Globalisierung von Texten durch das Internet.

Problemzonen

Folgende Fakten tragen meiner Meinung nach besonders zur Provokation von Encoding-Problemen bei:

• Ein Webserver lässt sich über entsprechende Optionen dazu überreden, alle Textdokumente so zu kennzeichnen, dass sie angeblich ein bestimmtes Encoding haben. Als wäre das an sich nicht schon schlimm genug, ist dieses Verhalten unter Umständen auch noch vorkonfiguriert, statt explizit eingeschaltet werden zu müssen.
• Das W3C legt in einer Recommendation zum Thema Encoding einer Seite für das Verhalten eines Browsers fest, dass die Angabe des "charset" Parameters im Feld "Content-Type" des HTTP-Headers Vorrang hat vor eventuellen Angaben im Dokument. Oder zu gut Deutsch: im Zweifelsfall weiß es der Webserver besser als der Ersteller der Seite selbst. Das eröffnet im Zusammenspiel mit dem letzten Punkt ganz neue Möglichkeiten der Benutzerverwirrung.
• Eine PHP-Installation will erst entsprechend konfiguriert sein, um Multibyte Operationen zu unterstützen. Wenn der Internet Service Provider es so will, muss man also in diesem Fall auf ISO-8859-1 zurückgreifen.

Beobachtungen anhand von Test-Szenarios