Zeichensatz/Sonderzeichen

[Deficiency]

Hallo erstmal!
Ich poste heute das erstemal beschäftige ich mich jedoch mit dem Forum
schon länger!
Ich bin Student und gerade im Praxissemester! Und "muss/darf/kann" auf einer
AS400 arbeiten!
Ich habe ein Problem! Wir arbeiten noch mit einem Release was nur UTF 8 unterstütz.
Wenn ich jetzt über ein JAVA Programm die SZ(Sonderzeichen) einfüge macht die AS400
etwas ganz schlaues...
Sie ändert den HEX-Code auf 3F = "?" ab! Kann ich dieses verhalten unterdrücken?
Ich brauch den HexCode, da bei einer normalen Eingabe eines SZ in der Java-Appl, das SZ auch wieder bei der Ausgabe das gleiche sein soll!
Ihr fragt euch vielleicht warum?!?
Wenn ein Tscheche sein O mit Tilde eingibt weil es in seinem Namen ist, soll der Name ja bei uns richtig angezeigt werden! usw.

Vielen Dank

Gruß

[Fuerchau]

Das Thema CCSID's ist in diversen Beiträgen ausführlich beschrieben.

Um Daten aller Sprachräume gleichzeitig zu speichern, musst du UCS-2 (UNICODE, CCSID 13488) für die Datenbank nehmen.
An normalen 5250-Terminals (CA, Emulationen) lassen sich west- und osteuropäische Zeichen nicht gleichzeitig darstellen.

Wenn du in Java arbeitest, sind die Daten intern ja in UCS-2 gespeichert. Nur beim Datenaustausch per SQL kommt es zur Übersetzung und den damit verbundenen Verlusten wenn die Datenbank den Code nicht speichern kann.

[Deficiency]

Erstmal danke für die Schnelle Antwort!
Glaub mir oder nicht! Die Topics mit CCSID hab ich alle gelesen, sonst hätte ich ja net gepostet!
Also ich habe in der Tabelle Folgende Spalten
1. SQLCHAR typ CHAR
2. UC typ GRAPHIC CCSID 13488

Was du mit dem Terminal meinst ist mir noch nicht ganz klar!
Wir arbeiten PersonalCommunicatio AS400 Client AccessExpress vom IBM

Gibt es eine möglichkeit die Übersetzungsbedingten Verluste zu vermeiden???

Das Thema CCSID's ist in diversen Beiträgen ausführlich beschrieben.

Um Daten aller Sprachräume gleichzeitig zu speichern, musst du UCS-2 (UNICODE, CCSID 13488) für die Datenbank nehmen.
An normalen 5250-Terminals (CA, Emulationen) lassen sich west- und osteuropäische Zeichen nicht gleichzeitig darstellen.

Wenn du in Java arbeitest, sind die Daten intern ja in UCS-2 gespeichert. Nur beim Datenaustausch per SQL kommt es zur Übersetzung und den damit verbundenen Verlusten wenn die Datenbank den Code nicht speichern kann.

[Fuerchau]

Genau das ist ja das Problem:
In den verschiedenen CCSID's haben verschieden Hexcodes unterschiedliche Bedeutung (varianter Zeichensatz).
Im Gegnzug gibt es ein paar Zeichen (z.B. A-Za-z0-9), die als invariante Zeichen in allen CCSID's gleich ist.

Die CA-5250-Sitzung kann eben nur auf eine Host-CCSID (273, 870, usw.) eingestellt werden.
Bei der Ausgabe von CHAR-Daten erfolgt die Darstellung der Hexwerte eben in der eingestellten Schrift der 5250-Sitzung.
UCS-2 wird in die JOB-CCSID (die nicht UCS-2 sein kann) gewandelt mit den entsprechenden Verlusten und dann am Terminal angezeigt.

Daten eines 273-Terminals sehen eben anders aus als bei einem 870-Terminal.

Um dieses zu umgehen, muss man eben eine Client-Server-Anwendung schreiben, die die Daten aus der DB per SQL im UCS-2-Format liest und eben dann mit Windows-Methoden auszugeben.
Umgekehrt eben in Windows eingeben und per SQL im UCS-2-Format wieder in die DB zurückschreiben.

[Deficiency]

Das das nur so läuft hab ich mir fast gedacht, aber bis jetzt erfolgreich verdrängt!
Naja! mal gucken was daraus wird!

Nochmal vielen vielen Dank

Genau das ist ja das Problem:
In den verschiedenen CCSID's haben verschieden Hexcodes unterschiedliche Bedeutung (varianter Zeichensatz).
Im Gegnzug gibt es ein paar Zeichen (z.B. A-Za-z0-9), die als invariante Zeichen in allen CCSID's gleich ist.

Die CA-5250-Sitzung kann eben nur auf eine Host-CCSID (273, 870, usw.) eingestellt werden.
Bei der Ausgabe von CHAR-Daten erfolgt die Darstellung der Hexwerte eben in der eingestellten Schrift der 5250-Sitzung.
UCS-2 wird in die JOB-CCSID (die nicht UCS-2 sein kann) gewandelt mit den entsprechenden Verlusten und dann am Terminal angezeigt.

Daten eines 273-Terminals sehen eben anders aus als bei einem 870-Terminal.

Um dieses zu umgehen, muss man eben eine Client-Server-Anwendung schreiben, die die Daten aus der DB per SQL im UCS-2-Format liest und eben dann mit Windows-Methoden auszugeben.
Umgekehrt eben in Windows eingeben und per SQL im UCS-2-Format wieder in die DB zurückschreiben.