Ein Unicode-Entity wird immer mit einem Backslash eingeleitet, der das
folgende 'u' maskiert, d.h. als Zeichen mit Sonderfunktion kennzeichnet.
Trifft der Compiler auf ein derartiges Entity, so ersetzt er die gesamte
Folge durch die entsprechende Character-Repäsentans, da die Zeichenfolge
'\u' angibt, dass die folgenden Stellen als Unicode-Hexadezimalwert zu
interpretieren sind.
\u00FC → ü
Möchte man das Unicode-Entity als solches darstellen, so reicht es, den
Backslash selbst wiederum mit einem Backslash zu maskieren, das Entity somit
mit einem doppelten Backslash beginnen zu lassen:
\\u00FC → \u00FC
Hierdurch wird der Backslash selbst maskiert und dient nicht mehr
zusammen mit dem nachfolgenden 'u' als Character-Repräsemtans.
Bei der Entwicklung der Transformation von fremdsprachigen Zeichensätzen in
HTML-Entities in
Cent stand ich vor der Aufgabe, die Stringrepräsentationen
der jeweiligen Zeichen aus einer Datei einzulesen. Das Problem hierbei
besteht darin, dass der Entity-String in der Datei aus einer Folge von
Einzelzeichen besteht, denen ihrerseits jeweils eine hexadezimale
Entity-Form zugeordnet werden kann. Der in der Datei lesbare Entity-String
besteht also selbst aus einer Folge von Entity-Strings, bzw. deren
Zeichenform. Vorstellen kann man sich das Ganze ähnlich einem
Character-Array. Um hieraus ein einziges Zeichen zu erzeugen, muss der
numerische Anteil des Entity-Strings in seine hexadezimale numerische
Repräsentans überführt werden. Dies ist durch die Klasse
java.math.BigInteger
möglich, die zwei Konstruktoren bereit stellt, die String-Repräsentationen
eines
BigIntegerin einen BigInteger-Wert wandeln. Bei dem hier
verwendeten Konstruktor wird als zweiter Parameter die Basis 16 des
gewünschten hexadezimalen Zahlensystems übergeben. Das gebildete
BigInteger-Objekt
wird anschließend zunächst in den primitiven Datentyp
char gecastet
und dann als String zurück gegeben.
Die Methode
convertUnicode(String
s) im Beispiel demonstriert das Gesagte.