Convert UTF-8 String to ANSI

[klaesmann]

Hallo zusammen!

Folgendes Problem:
Ich möchte gerne einen bereits in UTF-8 konvertierten String mit Java in ANSI konvertieren.
Dabei sollten alle Sprachen bzw. alle Ländercodes gelten, sofern per UTF-8 darstellbar.
Dazu ein Beipsiel, welches mit Notepad++ convertiert wurde:

Der UTF-8 String:

مل على مدار اليوم. يمكنك مشاهدة ب

ANSI String:

مل على مدار اليوم. يمكنك مشاهدة ب

Dazu mein Code-Snippet:

String content = "مل على مدار اليوم. يمكنك مشاهدة ب";
String ansi = new String (content.getBytes("UTF-8"),"ANSI");

Habe das ganze schon mit ASCII, ISO-8859-1 anstelle von ANSI probiert.

Ich habe gelesen das Java generell Schwierigkeiten mit dem konvertieren von UTF-8 nach ANSI hat.
Stimmt das? (Siehe Blog Entry auf Sun) (Sorry, hab den Link net mehr)

Vielen Dank für Eure Hilfe.

 

[ModellbahnerTT]

Das Encoding heißt Windows-1252
Und du weißt schon, dass selbiger Zeichensatz nur 128 Zeichen kennt? Wenn du versuchst arabische Zeichen mit dem Zeichensatz darzustellen kommt nur Müll raus (was Notepad++ dir ausspuckt)

Dass dein Quelltext quatscht ist hast du ja offenbar schon selbst bemerkt, was soll der bewirken? Java-Strings haben kein explizites encoding.

 

[maki]

Stimmt das?

Nein.

 

[Leroy42]

Ich habe gelesen das Java generell Schwierigkeiten mit dem konvertieren von UTF-8 nach ANSI hat.
Stimmt das? (Siehe Blog Entry auf Sun) (Sorry, hab den Link net mehr)

???:L

Der Link würde mich interessieren.

 

[Wortraum]

Ich möchte gerne einen bereits in UTF-8 konvertierten String mit Java in ANSI konvertieren.

Warum? Je nach Anwendungsgebiet gibt es verschiedene Möglichkeiten, beispielsweise Base64, aber ohne Rückkonvertierung kannst Du die arabischen Zeichen nicht darstellen. UTF-8 dient als Kodierung für Unicode, das derzeit etwa 100.000 Zeichen enthält; ANSI enthält 128 Zeichen, wovon 32 Zeichen reine Steuerzeichen sind.

 

[sliwalker]

Wie schon gesagt wurde,

wenn die Zeichen in Deinem String nicht im ANSI bzw. ASCII Bereich liegen, also im Dezimalbereich von 0 - 127, dann können sie nicht interpretiert werden bzw. es kommt Bitmurks raus. Nimm einen zwei Bytes großes Encoding und zeige nur ein Byte davon an. Kannst Dir vorstellen, dass das nicht klappt, wie man will.

Dein Vorhaben ist schlichtweg nicht möglich. Hab was von Rückkonvertierung gelesen, was ich so nicht stehen lassen kann. UTF-8, ANSI und auch ASCII sind im Dezimalbereich von 0 - 127 (nahezu) identisch. ANSI und ASCII unterscheiden sich dann nur noch unterschiedlich (je nach Codepage) im Dezimalbereich von 128 - 255.
UTF-8 kann alle bislang bekannten Sprachen aufnehmen, weil es ein vier Bytes großes Encoding ist.

Es bringt da auch nichts mit ISO rumzuspielen, da nicht gewährleistet ist, dass Dein UTF-8 codierter String überhaupt in ISO angezeigt werden kann. ISO ist keine Teilmenge von UTF-8. Zumindest nicht mathematisch gesehen. ISO zeigt Zeichen aus UTF-8 an, ja, aber mittels unterschiedlicher Codepoints.

Dein String hat ein Standardencoding. UTF-16, außer Du sagt ihm etwas anderes.

 

[Spacerat]

Wenn man's genau nimmt, unterscheidet sich ASCII (7 Bit; 128 Zeichen) von UTF8 oder ANSI überhaupt nicht, was die ASCII relevanten Zeichen angeht. Erst beim erweiterten ASCII (8 Bit; 256 Zeichen) wirds interessant. Im Codebereich 128 bis 255 gibt es dann nämlich verschiedene Belegungen wie ANSI, UTF8, IBM (DOS-Extension) usw. Mit anderen Worten: ANSI, UTF8, IBM sind Varianten des erweiterten ASCII Zeichensatzes (liesmich).
Der erste Satz der bei der Insel

Java kodiert Texte durch Unicode-Zeichen. Jedem Zeichen ist ein eindeutiger Zahlenwert (engl. code point) zugewiesen, sodass zum Beispiel das große A an Position 65 liegt. Der Unicode-Zeichensatz beinhaltet die ISO-US-ASCII-Zeichen von 0 bis 127 (hexadezimal 0x00 bis 0x7f, also 7 Bit) und die erweiterte Kodierung nach ISO 8859-1 (Latin-1), die Zeichen von 128 bis 255 hinzunimmt.

lässt den Schluss zu, das sich UTF8 sehr wohl nach ANSI konvertieren lässt, jedoch als String dann nicht mehr korrekt angezeigt wird, solange die von Java verwendete Codepage nicht auch angepasst wird.

 

[Wortraum]

Natürlich läßt sich eine Zeichenkette von einer Kodierung in die andere überführen, weshalb ich Base64 erwähnte. Fürs Speichern oder Versenden ist das nützlich, um die Zeichenkette aber „normal“ darzustellen, muß man sie rückkonvertieren.

Es gibt schlaue Köpfe, die überlegten sich sogar, daß man beliebige Daten mit einem Alphabet aus zwei Zeichen darstellen könne. Eine Ziffer nannten sie dann Bit. Gelegentlich wird das heute sogar noch genutzt. Ganz verrückte Geschichte!

 

[Spacerat]

Es gibt schlaue Köpfe, die überlegten sich sogar, daß man beliebige Daten mit einem Alphabet aus zwei Zeichen darstellen könne. Eine Ziffer nannten sie dann Bit. Gelegentlich wird das heute sogar noch genutzt. Ganz verrückte Geschichte!

Bit? Moment... Hab' ich schon mal gehört... Hmmm... Neee... Bier lass ich beim proggen aussm' Schädel... :lol:
... Meinst du etwa diese Geschicht mit den Nullen und Einsen? Weshalb denn so 'ne geringe "Auflösung"? Base64 wäre mir persönlich auch noch zu klein. Am geeignetsten zum Konvertieren ist meines Erachtens Base128 Encoding und das ist ASCII-Standard.
Andererseits... Weis gar nicht, ob es dafür Wandler in der Standard-JRE gibt, oder ob man da selber implementieren muss. Base64 ist also schon OK.

 

[Wortraum]

Base128, ASCII-Standard? Also wenn ich von den 128 ASCII-Zeichen die 32 Steuerzeichen abziehe, bleiben nur 96 übrig.

Base64 ist nicht standardmäßig bei Java dabei, was ich bis heute nicht verstehe. Allerdings ist es recht einfach selbst zu programmieren, und zum Testen reicht der BASE64Encoder und -Decoder aus sun.misc.

 

[Spacerat]

Wie? Wenn ich mit 'ner Standard-VM z.B. unter Eclipse "Base6" und anschliessend Codevervollständigung mache, kommen sogar eine ganze Reihe Vorschläge (z.B. "com.sun.org.apache.xerces.internal.impl.dv.util.Base64"). Ist das Standard genug?
Base128 war auch nur so daher gesagt. Gibt es ja unter dieser Bezeichnung nicht. Wenn man aber so will, kann man mit dem ASCII-Standard, welcher ja nur 7-Bit belegt, das selbe anstellen wie mit Base64. Ein derartig kodierter String würde halt nur aus Bytes mit gelöschtem Bit 8 (oder anders gesagt ASCII-Zeichen) besteht. Die Länge eines solchen Strings wäre dann eben nur 8/7 grösser, statt 4/3 bei Base64. Der Nachteil ist allerdings der, das immer noch nicht alle Zeichen druckbar sind. Das höchste, was ich finden konnte war Base85 ? Wikipedia

 

[klaesmann]

Vielen Dank für die vielen, schnellen Antworten und Ideen.
Die Umstellung auf "Windows-1252" war der richtige Tip.
Über Sinn und Unsinn einiger gegebener Einstellungen in der DB und
auch in verschiedenen Variablen lässt sich streiten.
Anregungen Dinge schnellstmöglich zu ändern sind dabei.

Nocheinmal vielen Dank an Alle.