PHP vs. UTF-8

Seit ich meinen PHP-Webauftritt auf UTF-8 umgestellt habe, spinnt der Internet Explorer – das Layout ist völlig zerschossen. Beherrscht der IE kein Unicode?

Der Internet Explorer kommt sehr wohl mit Unicode zurecht – Probleme können dagegen auftreten, wenn eine UTF-8-kodierte Seite mit dem sogenannten Byte Order Mark (BOM) beginnt. Dieses ist eigentlich dazu gedacht, die Byte-Reihenfolge bei UTF-16 zu regeln, bei dem jedes Zeichen aus mindestens zwei Byte besteht: In der sogenannten Big-Endian-Schreibweise liest sich beispielsweise der Buchstabe A in UTF-16 als 00 41, bei Little-Endian würde 41 00 daraus. Lautet das im Editor unsichtbare Byte Order Mark am Anfang des Dokuments FE FF, handelt es sich um Big-Endian, FF FE wäre die andere Variante.

UTF-8 hat das Problem der zwei Schreibweisen eigentlich nicht, aber hier weist die Byte-Folge EF BB BF am Dateibeginn auf die verwendete Kodierung hin – Verwechslungen mit dem ISO-Format und daraus folgendes Umlaut-Chaos wird dadurch ausgeschlossen. Nur leider spielen manche Anwendungen hier nicht mit: PHP bis einschließlich Version 5 beispielsweise reicht das UTF-8-BOM stets ungefiltert an den Client weiter, was diesen bei zusammengesetzten Dokumenten unter Umständen mächtig durcheinanderbringen kann, denn jede Include-Anweisung schreibt dann die drei Bytes mitten in das Dokument. Bei einem Test konnten Opera und Safari das Problem abfangen, während dies Internet Explorer, Firefox und Chrome nicht gelang; vor allem im Internet Explorer können schwer vorhersehbare Effekte auftreten.

Die meisten UTF-8-tauglichen Editoren bieten die Variante ohne BOM als Ausgabeformat an. Schlimmstenfalls hilft ein Griff zum Hex-Editor, in dem man die drei Bytes entfernt. Der W3C-Validator warnt generell vor der Verwendung von UTF-8 mit BOM in Webseiten, weil manche sehr alte Browser damit gar nicht zurechtkommen sollen. ()