!!!Unicode in Java

Java verwendet intern Unicode-16 Zeichen. das heißt: Ein __char__ sind 16 Bit!

Hier die Tabelle, um deutsche Umlaute plattformunabhängig in String-Konstanten oder Properties-Dateien zu codieren:

{{{
Zeichen Unicode
------------------------------
Ä, ä \u00c4, \u00e4
Ö, ö \u00d6, \u00f6
Ü, ü \u00dc, \u00fc
ß \u00df
€               \u20ac
}}}

in der Properties Datei "messages.properties" steht dann z.B.:

{{{
menu.undo=R\u00fcckg\u00e4ngig machen
}}}

-- PeterHormanns

----
Wie man in der [Java API|http://java.sun.com/javase/6/docs/api/java/util/Properties.html] lesen kann, sind insbesondere Properties-Dateien per Definition immer in ISO-8859-1 kodiert. Das heisst, man kann Umlaute direkt benutzen, wenn man seinem Editor beibringt, immer das richtige Encoding zu benutzen. Da die meisten Systeme heutzutage UTF-8 als Standard benutzen, kann das etwas problematisch sein. Angenehm ist hier z.B. der Eclipse-Editor, der Properties anhand der Dateiendung erkennt und immer richtig kodiert. ''ISO-8859-1'' heisst übrigens eigentlich, daß das Euro-Zeichen(€) immer noch nicht drin vorkommt (habe ich aber noch nicht probiert).

Natürlich gelten obige Hinweise immer noch für alle nicht-Properties-Dateien. Wer also z.B. ein Quelltextpaket zwischen zwei Systemen austauscht, sollte immer auf das Encoding achten. In Eclipse kann man z.B. ein festes Encoding für ein Projekt in den Projekteinstellungen angeben. Das hilft natürlich nur, wenn der andere Rechner ebenfalls Eclipse nutzt.

Man kann [Unicode Escapes|http://java.sun.com/javase/6/docs/api/java/util/Properties.html] also sehr weitgehend vermeiden, wenn man sauber und sorgfältig vorgeht, sie können aber andererseits (bis auf die etwas verminderte Lesbarkeit) niemals schaden. -- ThomasBayen

:; In ''ISO-8859-1'' ist auch kein Umlaut enthalten. Weiter ist es nur möglich mit Unicode Escapes Protable Programme zu schreiben. Wer mal versuchte unter verschiedenen anderscodierten Systemen eine Swinganwendung mit Umlauten zum laufen zu bringen wird sich freuen wenn er die Escape Zeichen genutzt hat. ''native2ascii'' ist hier ein wichtiger hinweis, schade eigentlich, dass es keine gute Unterstüzung in Eclipse dafür gibt. Das Tool ist im bin Verzeichnis des JDK (JRE?) --JensKapitza

::>> <<ISO-8859-1 enthält selbstverständlich Umlaute (Guckst Du da: http://de.wikipedia.org/wiki/ISO_8859-1), aber eben kein Euro-Symbol.
<<
Der Hinweis von Jens auf das Tool '''native2ascii''' ist sehr interessant. Es wird mit dem JDK automatisch installiert und kann sowohl zu Unicode-Sequenzen hin als auch wieder zurück in verschiedenste Codierungen konvertieren. Im Zweifel könnte man damit also sein ganzes Projekt durchkonvertieren - vielleicht sogar im build-Skript, bevor ich eine Version an andere herausgebe...

Jens' Warnung bzgl. Problemen auf anderskodierten Systemen stimmt grundsätzlich, wenn man nicht sorgfältig vorgeht (was nicht immer leicht ist). Auf der anderen Seite steht die Unbequemlichkeit der unleserlichen Zahlen im Code sowie die Not, diese auch schreiben zu müssen. Aber man kann definitiv portable Programme ohne Unicode Escapes in UTF-8 schreiben! Texte aus dem Quellcode werden beim Compilieren sowieso immer in das interne UTF-16 konvertiert. Texte, die man anderweitig in Form von Dateien oder Resourcen (Dateien im Jar-File) beilegt, werden immer über Methoden eingelesen, denen man eine Kodierung mitteilen kann (und sollte!). Im übrigen muss man sowieso jedesmal, wenn man eine Textdatei liest, d.h. immer wenn man einen [Reader|http://java.sun.com/javase/6/docs/api/java/io/Reader.html] benutzt, nachdenken, wie man mit dem Encoding verfährt - (Systemdateien sind anders als Benutzerdateien sind anders als Internetseiten sind anders als eigene Resourcen).

Ich persönlich bevorzuge "UTF-8 everywhere", gebe dies beim Lesen eigener Dateien oder Resourcen (hoffentlich) immer explizit an, lese Dateien des Benutzers aber mit seinem Standardencoding und komme da ganz gut mit zurecht. -- ThomasBayen


[{Tag Java}]