EF BF BD EF BF BD EF BF BD

Vor einigen Tagen begegneten mir einige Dateien, deren Inhalts größtenteils aus der Zeichenfolge EF BF BD EF BF BD EF BF BD (hexadizimal) bestand. Eigentlich sollte in den entsprechenden Dateien binäre Daten enthalten sein. Damit stellte sich nun die Frage: Was war passiert?

EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD

Auf den ersten Blick sah das ganze so aus, als ob ein Großteil der Datei durch Datenmüll ersetzt wurde. Schaut man sich die Zeichenfolge allerdings genauer an, so wird man feststellen das sich die Folge EF BF BD immer und immer wieder wiederholt. Bei dieser Zeichenfolge handelt es sich um die hexadezimale Schreibweise des Unicode-Zeichens für den Replacement Character welcher meist durch eine Raute mit einem Fragezeichen (�) dargestellt wird.

Eindeutiger wäre das Problem gewesen, wenn die erzeugten Dateien mit der Zeichenfolge EF BB BF begonnen hätte. Dabei handelt es sich um das Byte Order Mark für eine UTF-8 kodierte Datei. Damit wäre gleich klar geworden, das die enthaltenen Daten nicht zu einer Datei mit binären Inhalten passen. Doch wie sind diese Dateien nun entstanden? Der Ursprung der Dateien ist in einer Java-Applikation zu finden, welche diese Dateien erstellt. Diese kopierte die Daten von A nach B, im Quelltext (man ignoriere das fehlende try with resources) könnte das so ausgesehen haben:

FileInputStream fileInputStream  = new FileInputStream("binary.dat");
FileWriter fileWriter = new FileWriter("binary-copied.dat");

int byteData;

while ((byteData = fileInputStream.read()) != -1) {
    fileWriter.write(byteData);
}

fileInputStream.close();
fileWriter.close();

Hier wird ein FileInputStream geöffnet und dieser Stück für Stück mit einem FileWriter in die Zieldatei geschrieben. Genau an dieser Stelle entsteht das Problem – der FileWriter ist nämlich ein zeichenbasierter Writer, das bedeutet das sämtliche Zeichen, die mit diesem geschrieben werden, kodiert werden. Wenn nun bei dieser Kodierung ein Zeichen gefunden wird, welches nicht im Unicode abgebildet werden kann, so erhält dieses Zeichen den Wert EF BF BD – besagter Replacement Character. Damit ist dann auch erklärt warum die binären Dateien hauptsächlich nur noch aus diesen Zeichen bestanden. Die echten Daten wurden beim Kopiervorgang größtenteils schlicht und ergreifend in den Replacement Character konvertiert, da sich für diese Daten keine Entsprechung im Unicode fand.

Java und die Speicherung von Unicode

Der Datentyp char ist unter Java 16 Bit, also zwei Byte groß. Laut dem Buch Java ist auch eine Insel, werden die Daten in 16-Bit-Unicode gespeichert. Doch was genau bedeutet das und ist das eine korrekte Aussage? Die grundlegende Aussage, dass ein char unter Java ein 16-Bit-Unicode Zeichen ist, stimmt. Wobei mittlerweile wird das ganze so betrachtet, dass ein char unter Java eine Unicode code unit repräsentiert. Echte Unicode-Zeichen benötigen mittlerweile bis zu 21 Bit und werden üblicherweise als 32 Bit gespeichert, was einer UCS-4 Kodierung entspricht.

Mit Unicode können nicht nur lateinische Buchstaben abgebildet werden

Mit Unicode können nicht nur lateinische Buchstaben abgebildet werden

Das bedeutet, dass in einem char nur Unicode-Zeichen gespeichert werden können, die in 16 Bit abgebildet werden können. Bei einem Array vom Typ char, einem StringBuffer und einem String sieht die Sache anders aus. Hier sind die Unicode-Zeichen in UTF-16 kodiert, damit können alle Zeichen des Unicode-Satzes kodiert werden. Das führt aber auch zu Problemen, so gibt die Methode length() einer String-Instanz die Anzahl der Unicode code units zurück, was gleichbedeutend ist mit der Anzahl Byte multipliziert mit zwei ergibt. Es bedeutet das die Methode nicht zwingend die Anzahl der Buchstaben zurück gibt, da manche Buchstaben mit zwei Unicode code units kodiert werden.

Unicode-Zeichen unter Mac OS X eingeben

Unter Windows kann man Unicode-Zeichen eingeben, indem man die Alt-Taste gedrückt hält und den entsprechenden Zahlencode auf dem Numpad eingibt. Unter Mac OS X ist das etwas komplizierter gelöst. Im ersten Schritt muss das Tastaturpanel in den Einstellungen mit dem Tab Eingabequellen geöffnet werden.

Die Tastatur-Einstellungen

Die Tastatur-Einstellungen

Dort fügt man nun eine neue Sprache und Eingangsquelle hinzu. Diese hört dabei auf den Namen Unicode Hex-Eingabe. Wenn diese hinzugefügt wurde, erscheint in der Menüleiste ein Symbol zum Umschalten der Eingabequelle. Wenn man dort Unicode Hex-Eingabe aktiviert, kann man Unicode-Zeichen mittels der gewohnten Alt + nummerischer Code-Notation eingeben.

Tofu im Unicode

Wenn ein Font ein Zeichen nicht unterstützt, erscheint meist ein leeres Quadrat, welches besagt das dieses Zeichen in der aktuellen Schriftart nicht verfügbar ist. Dieses nicht vorhandenen Zeichen nennt man dabei Tofu. Unter dem Namen Noto (was für No Tofu steht) wird eine Schriftart mit dem Ziel entwickelt das alle Unicode-Zeichen in dieser enthalten sein sollen.

Ein Font für alle Sprachen

Ein Font für alle Sprachen

Dabei sollen bereits bis Ende 2014 alle Zeichen vorhanden sein, welche in lebendigen Sprachen genutzt werden. Entwickelt wird Noto dabei vom Google Internationalization Team. Der Font kann auf der entsprechenden Projektseite bezogen werden. Lizenziert ist Notu unter der Apache Lizenz und somit freie Software.

Seltsame Zeichen unter PuTTY

Wenn man PuTTY nutzt, wird man sich sicherlich das ein oder andere Mal über die seltsame Zeichen gewundert haben. Ein schönes Beispiel dafür ist der Midnight Commander, der anstatt mit der gewohnten Linienoptik mit ganz anderen Zeichnen arbeitet. Das Problem ist hier allerdings nicht beim Server zu finden. Stattdessen muss bei PuTTY gesucht werden.

Die PuTTY Optionen

Die PuTTY Optionen

Um das Problem zu beheben, sollte man in den Einstellungen unter „Window“ -> „Translation“ das „Remote character set“ auf UTF-8 stellen. Danach gehören die fehlerhaften Zeichen der Vergangenheit an.