4.10 Zeichenkodierungen, XML/HTML-Entitys, Base64 *

4.10.1 Unicode und 8-Bit-Abbildungen

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.

Kodierungen über die Klasse String vornehmen

Die String-Klasse konvertiert mit der Methode getBytes(String charsetName) beziehungsweise 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.

try
{
  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.

byte[] ebcdic = "Vernaschen".getBytes( "Cp037" );
String s = new String( ebcdic, "Cp037" );
System.out.println( s );                  // Vernaschen

4.10.2 Das Paket java.nio.charset und der Typ Charset

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.

  Charset charset = Charset.forName( charsetName );
  System.out.println( charset );      // Ausgabe wie oben
}

Mit dem konkreten Charset-Objekt lässt sich auf zwei Wegen weiterverfahren:

• Wir können es direkt mit den Methoden encode() und decode() konvertieren oder
• über die Methode newDecoder() einen CharsetDecoder beziehungsweise über newEncoder() einen CharsetEncoder erfragen und damit arbeiten.

Oftmals wird ein Charset aber an Klassen übergeben, die einen 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)

Standards-Charsets

Das am System voreingestellte Charset liefert die statische Methode Charset.defaultCharset(). Weiterhin gibt es eine Klasse StandardCharsets mit Kontanten für oft gebrauchte Charset-Objekte:

final class java.nio.charset.StandardCharsets
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

4.10.3 Konvertieren mit OutputStreamWriter/InputStreamReader-Klassen *

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 6, »Datenströme«, im 2. Band 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 4.24: GetBytesConverter.java, main()

try
{
  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 Standard-Kodierung von Windows, »Cp1252« (Windows-1252 beziehungsweise Windows Latin-1), ist eine Anpassung von ISO 8859-1, die andere Zeichen in den Bereich 0x80 bis 0x9f setzt.

4.10.4 XML/HTML-Entitys ausmaskieren

In einer XML-Datei dürfen bestimmte Zeichen im normalen Textstrom nicht vorkommen und müssen umkodiert werden.

Eine Konstruktion wie &quot; nennt sich Entity. Die gültigen Entitys 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 &copy; und das Euro-Zeichen &euro;. 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 &#8364;.[125](Das führt in HTML zu viel mehr Entitys als bei XML, sodass es ein Problem werden kann, eine HTMLDatei als XML einzulesen – der XML-Parser meckert dann über die unbekannten Entitys.)

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 Entitys in einen Java-String zu bringen, bei dem insbesondere die HTML-Entitys 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.

StringWriter sw = new StringWriter();
XMLStreamWriter w = XMLOutputFactory.newInstance().createXMLStreamWriter(sw);
w.writeCharacters( "<&'Müsli\">" );
System.out.println( out.toString() );    // &lt;&amp;'Müsli"&gt;

4.10.5 Base64-Kodierung

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. Die im RFC 1521 beschriebene Methode übersetzt drei Bytes (24 Bit) in vier Base64-kodierte Zeichen (vier Zeichen mit jeweils sechs repräsentativen Bits). Die Base64-Zeichen bestehen aus den Buchstaben des lateinischen Alphabets, den Ziffern 0 bis 9 sowie »+«, »/« und »=«. Die Konsequenz dieser Umformung ist, dass Binärdaten rund 33 % größer werden.

Das JDK liefert zwar Unterstützung für diese Base64-Umsetzung mit den Klassen BASE64Encoder und BASE64Decoder, aber da die Kodierer im nicht-öffentlichen Paket sun.misc liegen, könnte Oracle sie prinzipiell jederzeit entfernen.[126](Siehe dazu http://java.sun.com/products/jdk/faq/faq-sun-packages.html. Bisher existieren sie aber seit über zehn 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[127](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://jakarta.apache.org/commons/codec/ die Commons Codec-Bibliothek beziehen.

Beispiel

Das folgende Beispiel erzeugt zuerst ein Byte-Feld der Größe 112 und belegt es mit Zufallszahlen. Die internen JDK-Klassen kodieren 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 4.25: Base64Demo.java

import java.io.IOException;
import java.util.*;
import sun.misc.*;

public class Base64Demo
{
  public static void main( String[] args ) throws IOException
  {
    byte[] bytes1 = new byte[ 112 ];
    new Random().nextBytes( bytes1 );

    // Byte array -> to String
    String s = new BASE64Encoder().encode( bytes1 );
    System.out.println( s );

    // String enthält etwa:
    // QFgwDyiQ28/4GsF75fqLMj/bAIWNwOuBmE/SCl3H2XQFpSsSz0jtyR0LU+kLiwWsnSUZljJr97Hy
    // LA3YUbf96Ym2zx9F9Y1N7P5lsOCb/vr2crTQ/gXs757qaJF9E3szMN+E0CSSslDrrzcNBrlcQg==

    // String -> byte[]
    byte[] bytes2 = new BASE64Decoder().decodeBuffer( s );
    System.out.println( Arrays.equals(bytes1, bytes2) );    // true
  }
}

Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.