This article is not available in English
Sorry, this article hasn’t been translated to English. In case you understand German, read the German version below.
Die Byte Order Mark (BOM)
Was ist die Byte Order Mark?
Die Byte Order Mark (im folgenden mit »BOM« abgekürzt und »Bomm!« ausgesprochen ;-) ) heißt eigentlich »Zero Width No-Break Space«, abgekürzt »ZWNBSP«. Es handelt sich hierbei um ein Leerzeichen (Space), das die Breite 0 hat (Zero Width) und keinen Zeilenumbruch erlaubt (No-Break). Es ist, kurz gesagt, völlig unsichtbar.
Dieses Zeichen existiert nur im Unicode-Standard, nicht in ASCII, in den ANSI-Codepages oder in anderen mehr oder weniger verbreiteten Standards. In Unicode hat es den Codepoint FEFF in Hexadezimal- bzw. 65.279 in Dezimalschreibweise und ist damit das letzte Zeichen im Block »Arabic Presentation Forms-A«.
Tatsächlich war dieses nullbreite Leerzeichen ursprünglich für die Verwendung in arabischen Texten gedacht. Arabisch ist vom Prinzip her eine Schreibschrift, bei der die einzelnen Buchstaben nicht isoliert nebeneinander stehen wie z.B. im Lateinischen, sondern sich miteinander verbinden. Die Verbindung ist aber nicht immer gewünscht, und durch das Einfügen des unsichtbaren ZWNBSP konnte sie verhindert werden, ohne daß dabei ungewollte Effekte wie z.B. ein größerer Abstand zwischen den beiden Buchstaben oder eine ungewollte Umbruchstelle entstanden, wie das mit einem normalen Leerzeichen der Fall gewesen wäre.
Inzwischen ist die BOM für diesen Zweck »deprecated«, d.h. mißbilligt. Diese Rolle (und ähnliche Funktionen in anderen Schriften als Arabisch) übernimmt nun das Zeichen mit dem Codepoint 2060 (hexadezimal) bzw. 8.288 (dezimal), der »Word Joiner«.
Wozu dient die BOM heutzutage?
Im Gegensatz zu den meisten früheren Standards wie ANSI und ASCII enthält der Unicode-Standard zu viele Zeichen, als daß man sie mit nur einem Byte pro Zeichen darstellen könnte. Es gibt für Unicode verschiedene Codierungen, von denen die beiden wichtigsten UTF-8 und UTF-16 heißen (siehe hierzu auch die Wikipedia-Artikel zu UTF-8 und UTF-16).
In UTF-16 werden die ersten 65.536 Zeichen mit jeweils zwei Bytes codiert, die höheren Codepoints benötigen vier Bytes. Daraus ergibt sich ein Problem, das es bei Ein-Byte-Standards nicht gab: Der Computer kann entweder das höherwertige Byte oder das niederwertige Byte zuerst abspeichern. Ein Beispiel: Das lateinische große ›A‹ hat den Codepoint 41 (hexadezimal) bzw. 65 (dezimal). Das höherwertige Byte ist also 00, das niederwertige 41. Dementsprechend kann das ›A‹ in UTF-16 also entweder als 00 41 oder als 41 00 abgespeichert werden. Die erste Variante wird »Big Endian«, die zweite »Little Endian« genannt. Es sind auch tatsächlich beide gebräuchlich: Der Mac speichert seine Zahlen gerade anders herum als der PC.
Um den Text also richtig anzeigen zu können, müßte man nun wissen, für welche der beiden Möglichkeiten sich der Ersteller entschieden hat. Bei falscher Wahl würde anstelle des ›A‹ das chinesische Zeichen ›䄀‹ angezeigt, denn dieses hat die gleichen beiden Bytes, aber in umgekehrter Reihenfolge.
Es muß also für den Computer aus der betreffenden Datei heraus erkennbar sein, ob der Text »Big Endian«- oder »Little Endian«-codiert ist. Und genau hierbei hilft die BOM - daher auch der (neue) Name, denn sie zeigt die Reihenfolge der Bytes (Byte Order) an.
Wie wird die BOM eingesetzt?
Die BOM steht ganz einfach als erstes Zeichen in jeder UTF-16-codierten Datei. Der Computer liest die ersten beiden Bytes ein und kann dann entscheiden: Hat er FE FF gelesen, handelt es sich um »Big Endian«, findet er dagegen FF FE, so liegt die Datei in »Little Endian« vor. In jedem anderen Fall geht er davon aus, daß es sich überhaupt nicht um UTF-16 handelt.
Das bedeutet, daß die BOM in UTF-16 vorgeschrieben ist: Sie muß am Anfang einer jeden UTF-16-Datei stehen. Der Codepoint mit der umgekehrten Bytereihenfolge (also hexadezimal FFFE bzw. dezimal 65.534) ist dagegen »Not A Character«, also überhaupt kein gültiges Zeichen, und darf folglich nirgendwo in einem Unicode-Text auftauchen.
Dies bezog sich nun alles auf UTF-16, aber:
Was ist mit UTF-8?
UTF-8 funktioniert ganz anders als UTF-16 und hat das Problem mit der Bytereihenfolge überhaupt nicht, denn die Codierung ist in jedem Fall eindeutig (ganz einfach deswegen, weil die Reihenfolge der Bytes vorgeschrieben ist). Trotzdem wird grundsätzlich empfohlen, die BOM an den Anfang der Datei zu setzen, um dem Computer den Hinweis zu geben, daß es sich um UTF-8 handelt. Die BOM wird in UTF-8 durch die drei Bytes EF BB BF dargestellt.
Manchmal sieht man am Anfang eines Textes die Zeichenfolge . Dies ist
höchstwahrscheinlich eine UTF-8-BOM, die fälschlicherweise als ANSI
dargestellt wird.
Probleme mit der BOM
In UTF-16 gibt es mit der BOM keine Probleme. Das wäre auch fatal, da sie ja am Anfang stehen muß. Jedes Programm, das überhaupt UTF-16 lesen kann, wird sie korrekt behandeln, d.h. es wird sie benutzen, um die Bytereihenfolge zu erkennen; es wird sie aber nicht anzeigen.
In UTF-8 gibt es im Prinzip nur ein einziges Problem mit der BOM: Manche älteren Programme kennen ihre besondere Bedeutung nicht und behandeln sie folglich nicht richtig. Dies betrifft im Web vor allem den Microsoft Internet Explorer 5 (sowohl auf dem PC als auch auf dem Mac) sowie den Netscape Navigator 4. Beide halten die BOM für ein ganz normales Zeichen, suchen sie in der verwendeten Schriftart, finden sie nicht (wozu sollte eine Schriftart auch ein Zeichen enthalten, das sowieso nicht angezeigt wird?) und zeigen deswegen einen Kasten.
Das Problem wird dadurch verschärft, daß die BOM vor der Dokumenttyp-Deklaration in der HTML-Datei steht, die dann deswegen eventuell nicht mehr richtig interpretiert wird. Dadurch kann es passieren, daß der Browser die Seite nicht nur mit einem häßlichen Kasten-Zeichen am Anfang verschandelt, sondern auch noch das Layout zerfetzt.
Andererseits zeigen diese beiden Uralt-Browser sowieso kaum noch eine moderne Webseite richtig an, und die neueren Versionen aller Browser (inclusive Netscape und Internet Explorer) haben keine Schwierigkeiten mehr mit der BOM.
Leider gibt es im Bereich serverseitiger Scripte ein noch viel größeres Ärgernis:
Die BOM in PHP
Die serverseitige Scriptsprache PHP ist leider auch in der aktuellsten Version nicht Unicode-fähig. Das bedeutet, daß Sie UTF-16 für PHP-Quelltext überhaupt nicht verwenden können, wohl aber UTF-8 – denn letzteres ist rückwärtskompatibel zu ANSI.
Wenn nun Ihr Quelltext aber mit einer UTF-8-BOM beginnt, also mit
EF BB BF,
dann mißversteht der PHP-Interpreter dies als die ANSI-Zeichenfolge  –
und gibt sie aus. Das ist an sich nicht weiter schlimm, denn der (moderne) Browser, der sie
empfängt, versteht sie ja wieder richtig. Aber der Interpreter wird meckern, wenn Sie
nun versuchen, den HTTP-Header zu
verändern. Denn der Aufruf der Funktion header() ist nur dann erlaubt,
wenn noch kein Content ausgegeben wurde – und die bereits ausgegebene BOM zählt
leider als Content.
Fazit
Wenn Sie eine Datei in UTF-16 erstellen, brauchen Sie sich um die BOM keine Gedanken zu machen. Ihr Unicode-fähiger Editor kümmert sich darum und fügt beim Abspeichern die BOM am Anfang der Datei ein, ohne Sie damit zu behelligen. UTF-16 ist empfehlenswert für Texte, die mehrheitlich Zeichen enthalten, die wir Europäer »Sonderzeichen« nennen – also nicht-lateinische Schriften wie Chinesisch, Thai und viele andere. Denn diese Zeichen benötigen in UTF-16 jeweils zwei Byte, in UTF-8 aber drei.
Für Texte, die auf dem lateinischen Alphabet basieren und nur hin und wieder Sonderzeichen enthalten (so wie dieser hier), ist UTF-8 die bessere Wahl, da die lateinischen Standardbuchstaben, die Zahlen und einige andere häufig gebrauchte Zeichen hier nur ein Byte benötigen. Ebenso nimmt man UTF-8, wenn Rückwärtskompatibilität zu ANSI gefragt ist.
Hier sollten Sie darauf achten, den Text möglichst ohne BOM abzuspeichern, wenn die Datei für das Internet gedacht ist, da ansonsten die oben genannten Probleme auftreten können. Andernfalls hat man als Benutzer natürlich die starke Tendenz, die Entscheidung einfach seinem Editor zu überlassen ;-). Einen wirklichen Nutzen bringt die BOM bei UTF-8 nicht.
Social Bookmarks