nbsp; in XML

Im HTML existiert für das geschützte Leerzeichen die HTML-Entity:

nbsp;

Bei bestimmten Frameworks aus dem HTML5-Bereich wie Framework 7 kann diese Entity allerdings nicht genutzt werden, da z.B. Unterseiten als XML interpretiert werden und der Parser in diesem Fall mit einer Fehlermeldung reagieren würde. Stattdessen kann für das geschützte Leerzeichen das Zeichen:

 

genutzt werden. Bei diesem Zeichen handelt es sich ebenfalls um das geschützte Leerzeichen.

Unicode-Tabelle im Web

Unicode besteht mittlerweile aus über 137.000 Zeichen. Während ASCII mit seinen 128 Zeichen noch übersichtlich daherkam, ist dies bei Unicode etwas komplexer. Abhilfe schafft hier das Webprojekt der Unicode-Zeichentabelle. In dieser Tabelle lassen sich Unicode-Zeichen betrachten, kopieren und einzeln aufrufen. In der Einzelansicht werden verschiedene technische Angaben zu dem jeweiligen Zeichen dargestellt.

Die Unicode-Tabelle stellt die Unicode-Zeichen übersichtlich da

Zu finden ist das Projekt unter unicode-table.com. Die Seite steht in unterschiedlichen Sprachen, unter anderem Russisch, Englisch, Polnisch und Deutsch zur Verfügung. Die Daten, welche vom Projekt genutzt werden, sind auf GitHub zu finden.

One font to rule them all

Viele Fonts decken einen gewissen Teil der Unicode-Zeichen ab. Wenn sich ein Zeichen im Text befindet, welches nicht dargestellt werden kann, so erscheint stattdessen das Zeichen �. Dieses Zeichen in der Umgangssprache Tofu genannt ist der Platzhalter für Zeichen, die in der Schriftart nicht enthalten sind. Beim Zeichen selber handelt es sich um das Notdef-Zeichen. Allerdings existiert mittlerweile ein Font, dessen erklärtes Ziel es ist keine Notdef-Zeichen mehr zuzulassen. Der Name des Fonts, Noto, steht für No More Tofu und stellt das Ziel des Fonts da.

Unterschiedlichste Schriftsysteme werden unterstützt

Mittlerweile hat das Projekt einige Jahre Entwicklung hinter sich. 2011 gestartet werden über 64.000 Zeichen unterstützt, was in etwa die Hälfte der im Unicode definierten Zeichen ist. Dies schlägt sich allerdings in der Größe des Fonts nieder; im Moment belegt dieser knapp 1,5 Gibibyte auf der Festplatte. Deshalb ist er in unterschiedliche Dateien, mit den jeweiligen Schriftfamilien, aufgeteilt. Neben den unterschiedlichen Zeichen finden sich unterschiedliche Schnitte (wie z.B. Fett, Kursiv) im Font. Heruntergeladen kann der Font über die Projektseite von Google. Daneben kann die Entwicklung auf GitHub verfolgt werden. Lizenziert ist Noto unter der SIL Open Font License und damit freie Software.

Unicode-Zeichen identifizieren

Vor einigen Tagen stand ich vor dem Problem dass ich die Zeichen in einer Unicode-Zeichenkette auf die Schnelle identifizieren wollte. Hilfreich zur Seite sprang mir dann eine kleine Webapplikationen der Seite babelstone.co.uk.

Eine Unicode-Zeichenkette wird identifiziert

Besagte Webapplikation nimmt eine Zeichenkette entgegen und gibt anschließend die einzelnen Zeichen mit ihrer Unicode-Beschreibung aus. Damit kann das Problem unbekannter Zeichen in einer Zeichenklette sehr schnell gelöst werden.

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.