UTF-8 vs. ISO

[mOSSpOWER]

Ich würde mal gerne wissen, wie man in Java eine Datei im UTF-8 (UNICODE) - Format speichert. Hintergrund ist der, dass wenn man in Propertyfile Eszett schreibt und dieses dann im UTF-8 Format speichert und zusammen mit korrespondierender JSP im HTML header das meta tag mit UTF-8-Zeichensatz anwendet, so muß eben dieses Eszett nicht maskiert oder codiert werden (CodeNummer; ¨ ect.). Wie schafft man das beim Erstellen einer Propertyfile in Java; ich dachte immer, dass JAVA UNICODE speichert, jedoch werden normale Textdateien auch im Textformat gespeichert. Gleiches Problem bei XML Dateien. Wird hier im Prolog UTF-8 angegeben und Datei mit normalen Editor gespeichert (hier immer ANSI) bekommt man Parserfehler - speichert man die gleiche Datei jedoch im UTF-8-Format, so läuft der Parser problemlos drüber. Gibt es in Java so eine Einstellung, dass man den Typ mitteilt? Könnte mir hier jemand helfen, kann sogar sein, dass ich hier etwas grundlegendes noch nicht kapiert habe. Danke schon mal im voraus

[themaster]

Das mit der XML-Datei ist ja auch kein Wunder.

Den Editor interressiert es überhaupt nicht ob du Unicode als Zeichenkodierung angibst oder nicht, er speichert immer in ANSI. Deshalb ist es auch klar warum Java die Datei nicht ordentlich einlesen kann. Es wird versucht Unicode zu lesen es ist aber ANSI.

Du kannst das mit einem XML-Editor machen (z.B. Cooktop finde ich für Windows ganz gut). So ein Editor speichert die Datei mit der Zeichenkodierung ab wie du sie angibst. Oder du gibst nicht Unicode an sondern die ANSI-Zeichenkodierung (leider kenne ich die entsprechende Nummer der ISO-Norm nicht mehr, die man dann angeben muss), dann kann man auch eine XML-Datei lesen, die mit einen normalen Editor geschrieben wurde.

Allerdings sind die Propertiesklassen als ANSI definiert und kannst also auf keinen Fall Unicodezeichen aus den Propertiesklassen herauslesen. Deshalb werden für viele mehr-sprachige Anwendungen auch XML-Dateien anstatt Propertiesdateien verwendet, wenn man die lokalisierten Strings speichert.

Ich hoffe ich konnte etwas helfen...

Grüße

themaster

[solvery]

ich habe ein ähnliches Problem mit dem aus einer DB gelieferten verschlüsselten Passwort-String.

Dieser gespeicherte verschlüsselte PW-String ist immer ungleich dem zur Prüfung verschlüsselten Input-String, der per CallableStatement zur Prüfung erstellt wird. Ungleich bei Umlauten und Sonderzeichen. Die DB ist auf einer UnixKiste installiert und ich greife über einen WinClient zu.

Kennt sich jemand mit dem Zeichsatz-Wirrwarr aus???

[themaster]

Zeichenkodierung, wenn man innerhalb von Java bliebt, ist echt eine einfache Sache. Sehr kompliziert wird es nur, wenn man auf externe Systeme wie Datenbanken zugreift.

Wenn die Datenbank dies unterstützt und die Datenbank nur für dich zur Verfügung steht, so kann man evtl. die Datenbank auf Unicode umstellen. Aber dies ist nur sehr selten möglich. Vielleicht kannst du auch den Passwortstring umkonvertieren wie dies HTML auch macht oder als base64. Und vor dem Vergleichen wieder zurückkonvertieren. Da könntest du dir die Codec-Bibliothek von jakarta ansehen: http://jakarta.apache.org/commons/codec/

Ok, zu zeichenkonvertierung bei java: wenn du ein byte-Array hast und daraus einen String machen willst und du weist in welcher zeichenkodierung dies gespeichert ist, dann kannst du mit new String(bytearray,kodierung) den String erstellen.

Grüße

themaster

[solvery]

also wenn ich mir das verschlüsselte PW (das gespeicherte ReferenzPW) aus der DB als String liefern lasse, dann kommt es auch so an wie es in der DB gespeichert ist. Lass ich es mir als ByteArray liefern und wandle es dann in einen String mit der Codepage "8859_1" um, so erhalte ich ebenfalls den richtigen String wie er in der DB gespeichert ist.

Nur die Abprüfung des Eingabepasswort, welches per CallableStatement verschlüsselt wird und dann verglichen wird, bringt jedesmal nur eben fast genau den gleichen String. Und diese Problematik tritt eben nur bei Umlauten und Sonderzeichen auf...

So langsam gehen mir die Ideen aus :-(