2.4Zeichenkodierungen, XML/HTML-Entities, Base64 * ![Zur vorigen Überschrift](common/top.gif)
![Zur nächsten Überschrift](common/down.gif)
2.4.1Unicode und 8-Bit-Abbildungen ![Zur vorigen Überschrift](common/top.gif)
![Zur nächsten Überschrift](common/down.gif)
Einzelne Zeichen sind in Java intern immer in 16-Bit-Unicode kodiert, und ein String ist eine Folge von Unicode-Zeichen. Wollen wir diese Unicode-Zeichenkette in eine Datei schreiben, können mitunter andere Programme die Dateien nicht wieder einlesen, da sie keine Unicode-Zeichen erwarten oder nicht damit umgehen können. Die Unicode-Strings müssen daher in unterschiedliche Codepages, etwa Latin-1, umkodiert werden.
2.4.2Kodierungen über die Klasse String vornehmen ![Zur vorigen Überschrift](common/top.gif)
![Zur nächsten Überschrift](common/down.gif)
Die String-Klasse konvertiert mit der Methode getBytes(String charsetName) bzw. getBytes(Charset charset) den String in ein Byte-Feld mit einer bestimmten Zeichenkodierung. Auf diese Weise kann Java die interne Unicode-Repräsentation zum Beispiel in den EBCDIC-Zeichensatz eines IBM-Mainframes übertragen. Jede Kodierung (engl. encoding) ist durch eine Zeichenfolge oder ein Charset-Objekt definiert; die Namen sind unter http://tutego.de/go/encoding aufgeführt. Für den EBCDIC-Zeichensatz ist das die Codepage »Cp037«. Die DOS-Konsole unter Windows nutzt einen veränderten IBM-Zeichensatz, dessen Codepage »Cp850« heißt.
[zB]Beispiel
Kodiere den String "Vernaschen" in EBCDIC:
byte[] ebcdic = "Vernaschen".getBytes( "Cp037" );
System.out.println( Arrays.toString(ebcdic) );
// [-27, –123, –103, –107, –127, –94, –125, –120, –123, –107]
}
catch ( UnsupportedEncodingException e ) { … }
Zur Kodierung in die andere Richtung, also von einem Byte-Feld in einen Unicode-String, müssen Sie einen Konstruktor der String-Klasse mit der Kodierung nutzen. Auch hier kann eine UnsupportedEncodingException folgen, wenn es die Kodierung nicht gibt.
[zB]Beispiel
Kodiere das Byte-Feld mit den Zeichen nach dem EBCDIC-Alphabet zurück in einen String:
String s = new String( ebcdic, "Cp037" );
System.out.println( s ); // Vernaschen
2.4.3Das Paket java.nio.charset und der Typ Charset ![Zur vorigen Überschrift](common/top.gif)
![Zur nächsten Überschrift](common/down.gif)
Konvertierungen zwischen Unicode-Strings und Byte-Folgen übernehmen java.nio.charset.Charset-Implementierungen. Die statische Methode Charset.availableCharsets() liefert eine Map<String, Charset> mit etwa 150 Einträgen – und somit Namen und assoziierte Klassen aller angemeldeten Kodierer. Ein Charset-Objekt lässt sich über einen Namen und dann mit Charset.forName(String charsetName) erfragen.
[zB]Beispiel
Gib alle Kodierungen aus:
System.out.println( charsetName );
Charset charset = Charset.forName( charsetName );
System.out.println( charset ); // Ausgabe wie oben
}
Mit dem konkreten Charset-Objekt lässt sich auf zwei Wegen weiter verfahren:
direkt mit den Methoden encode(…) und decode(…) konvertieren
über die Methode newDecoder(…) einen CharsetDecoder bzw. über newEncoder(…) einen CharsetEncoder erfragen und damit arbeiten
Oftmals wird ein Charset aber an Klassen übergeben, die ein Charset für ihre Arbeit nutzen. Eine kleine Auswahl:
byte[] String.getBytes(Charset charset)
InputStreamReader(InputStream in, Charset cs)
OutputStreamWriter(OutputStream out, Charset cs)
String(byte[] bytes, Charset charset)
String(byte[] bytes, int offset, int length, Charset charset)
StandardCharsets
Die am System voreingestellte Kodierung liefert die statische Methode Charset.defaultCharset(). Weiterhin gibt es eine Klasse StandardCharsets mit Konstanten für oft gebrauchte Charset-Objekte:
implements Cloneable
final static Charset ISO_8859_1
final static Charset US_ASCII
final static Charset UTF_16
final static Charset UTF_16BE
final static Charset UTF_16LE
final static Charset UTF_8
2.4.4Konvertieren mit OutputStreamWriter-/InputStreamReader-Klassen ![Zur vorigen Überschrift](common/top.gif)
![Zur nächsten Überschrift](common/down.gif)
Neben der Klasse String mit getBytes(…) unterstützen auch andere Klassen die Umkodierung. Dazu zählen:
OutputStreamWriter: Ein spezieller Writer, der Unicode-Zeichen mit einer gewählten Kodierung in einen binären Datenstrom schreibt.
InputStreamReader: Übernimmt den anderen Weg zum Lesen von Byte-Folgen und Konvertieren in Unicode. Ist ein Reader.
Genauer stellt Kapitel 7, »Datenströme«, die Klassen vor, daher folgt an dieser Stelle nur kurz ein Beispiel.
Konvertieren in DOS-Latin-1
Zum korrekten Darstellen der Umlaute auf der Windows-DOS-Konsole wird ein OutputStreamWriter mit der Codepage 850 (DOS-Latin-1) verwendet:
Listing 2.14GetBytesConverter.java, main()
System.out.println( "Ich kann Ä Ü Ö und ß" );
PrintWriter out = new PrintWriter(
new OutputStreamWriter(System.out, "Cp850") );
out.println( "Ich kann Ä Ü Ö und ß" );
out.flush();
}
catch ( UnsupportedEncodingException e ) { e.printStackTrace(); }
Die Standardkodierung von Windows, »Cp1252« (Windows-1252 bzw. Windows Latin-1), ist eine Anpassung von ISO 8859-1, die andere Zeichen in den Bereich 0x80 bis 0x9f setzt.
[+]Tipp
Sollen ganze Dateien umkodiert werden, lässt sich auf der Kommandozeile das Dienstprogramm native2ascii nutzen.
2.4.5XML/HTML-Entities ausmaskieren ![Zur vorigen Überschrift](common/top.gif)
![Zur nächsten Überschrift](common/down.gif)
In einer XML-Datei dürfen bestimmte Zeichen im normalen Textstrom nicht vorkommen und müssen umkodiert werden:
Zeichen | Umkodierung |
---|---|
" | " |
& | & |
' | ' |
< | < |
> | > |
Tabelle 2.10Umkodierungen für eine XML-Datei
Eine Konstruktion wie " nennt sich Entity. Die gültigen Entities werden im XML-Standard beschrieben.
Weiterhin gilt, dass bei einer Webseitenkodierung in ISO-8859-1 nur die »sicheren« Zeichen wie Ziffern und Buchstaben verwendet werden können, aber keine Sonderzeichen, wie etwa das Copyright- oder das Euro-Zeichen. Daher bietet HTML eine Umkodierung für Sonderzeichen an, die nicht im Zeichenvorrat von ISO 8859-1 enthalten sind – für das Copyright-Zeichen ist es etwa © und das Euro-Zeichen €. In XML ist diese Umkodierung nicht nötig, da XML leicht als UTF-8 geschrieben werden kann, und dann heißt es für das Euro-Zeichen nach der Position in der Unicode-Tabelle einfach €.[ 26 ](Das führt in HTML zu viel mehr Entities als bei XML, sodass es ein Problem werden kann, eine HTML-Datei als XML einzulesen – der XML-Parser meckert dann über die unbekannten Entities.)
Java-Programme, die XML- oder HTML-Ausgaben erstellen oder XML-/HTML-Dokumente lesen, müssen auf die korrekte Konvertierung achten. Die Standardbibliothek bringt hier nichts Offensichtliches mit, aber Open-Source-Bibliotheken füllen diese Lücke – so etwa Apache Commons Lang (http://commons.apache.org/lang/), das mit der Klasse org.apache.commons.lang.StringEscapeUtils einige Kodierungsmethoden bietet, um einen String in XML/HTML umzukodieren und einen XML-/HTML-String mit Entities in einen Java-String zu bringen, bei dem insbesondere die HTML-Entities aufgelöst wurden. Die Klasse StringEscapeUtils bringt neben den statischen Methoden
String escapeHtml3(String input)
String unescapeHtml3(String input)
String escapeHtml4(String input)
String unescapeHtml4(String input)
String escapeXml(String input)
String unescapeXml(String input)
auch Methoden zum Maskieren von CSV-, Java- und JavaScript-Strings.
[zB]Beispiel
Für eine einfache Kodierung (ohne Hochkommata) lässt sich ein XMLStreamWriter einsetzen:
StringWriter result = new StringWriter();
XMLStreamWriter converter =
XMLOutputFactory.newInstance().createXMLStreamWriter(result);
converter.writeCharacters( "<&'Müsli\">" );
System.out.println( result ); // <&'Müsli">
}
catch ( XMLStreamException | FactoryConfigurationError e ) {
e.printStackTrace();
}
2.4.6Base64-Kodierung ![Zur vorigen Überschrift](common/top.gif)
![Zur nächsten Überschrift](common/down.gif)
Für die Übertragung von Binärdaten hat sich im Internet die Base64-Kodierung durchgesetzt, die zum Beispiel bei E-Mail-Anhängen und SOAP-Nachrichten zu finden ist. Auch bei der HTTP-Authentifizierung Basic Authentication kommt Base64 zum Tragen, denn die Konkatenation von Benutzername + »:« + Passwort wird über Base64 kodiert und so zum Server gesendet – der Sicherheitsgewinn ist natürlich null.
Die Base64-Kodierung wird im RFC 4648[ 27 ](http://tools.ietf.org/html/rfc4648) beschrieben. Drei Bytes (24 Bit) werden in vier Base64-kodierte Zeichen (vier Zeichen mit jeweils sechs repräsentativen Bits) umgesetzt. Die Konsequenz dieser Umformung ist, dass Binärdaten rund 33 % größer werden. Die Base64-Zeichen bestehen aus den Buchstaben des lateinischen Alphabets, den Ziffern 0 bis 9 sowie (im Normalfall) »+«, »/« und »=«.
Das JDK liefert seit Java 8 für diese Base64-Kodierung die Klasse java.util.BASE64 aus. Zwei innere Klassen Base64.Decoder bzw. Base64.Encoder kümmern sich um die Umwandlung. Zur Erzeugung der Exemplare gibt es statische Methoden in BASE64, und zwar nicht nur zwei, sondern sieben. Der Grund ist, dass es neben der Standardkonvertierung »Base« noch MIME und URL-/Dateiname-sicher gibt:
getEncoder() und getDecoder() liefern Exemplare vom Typ Base64.Encoder und Base64.Decoder bzw. für den normalen Basic-Typ.
getEncoder(int lineLength, byte[] lineSeparator), getMimeEncoder() und getMimeDecoder() liefern Encoder/Decoder für MIME-Nachrichten, bei denen Zeilen mit einem »\r« getrennt sind.
getUrlEncoder() und getUrlDecoder() nutzen zur Kodierung nur Zeichen, die für URL und Dateinamen gültig sind, und ersetzen »+« durch »-« und »/« durch »_«.
Beispiel
Das folgende Beispiel erzeugt zuerst ein Byte-Feld mit Zufallszahlen. Die Base64-Klasse kodiert das Byte-Feld in einen String, der auf dem Bildschirm ausgegeben wird. Nachdem der String wieder zurückkodiert wurde, werden die Byte-Felder verglichen und liefern natürlich true:
Listing 2.15Base64Demo.java, main()
// byte[] -> String
String s = Base64.getEncoder().encodeToString( bytes1 );
System.out.println( s ); // z. B. TVST9v+JMk/vVUOSENmIcriXFLo=
// String -> byte[]
byte[] bytes2 = Base64.getDecoder().decode( s );
System.out.println( Arrays.equals(bytes1, bytes2) ); // true
Wer nicht mit Java 8 arbeiten kann, aber mit älteren Versionen vom Oracle-JDK, der kann BASE64Encoder/BASE64Decoder aus dem nichtöffentlichen Paket sun.misc nutzen.[ 28 ](Siehe dazu http://www.oracle.com/technetwork/java/faq-sun-packages-142232.html. Bisher existieren sie aber seit über 10 Jahren, und wer Oracles Philosophie kennt, der weiß, dass die Abwärtskompatibilität oberste Priorität hat.) Wem das nicht ganz geheuer ist, der kann javax.mail.internet.MimeUtility von der JavaMail-API nutzen[ 29 ](http://www.rgagnon.com/javadetails/java-0598.html gibt ein Beispiel. Die JavaMail-API ist Teil von Java EE 5 und muss sonst für das Java SE als Bibliothek hinzugenommen werden.) oder unter http://commons.apache.org/proper/commons-codec/ die Bibliothek Commons Codec beziehen.