Dauerthema Sonderzeichen

[Liebhoff]

Hallo zusammen, ich habe mal wieder eine Frage zum DauerthemaSonderzeichen. Gibt es eine Möglichkeit Sonderzeichen aus einem anderem Zeichensatz auf beliebigen Maschinen anzuzeigen. Beispiel:

Erfassung des Wortes "Köln" in Deutsch(auf deutscher AS/400) Anzeige erfolgt in Frankreich auf franz. AS/400 und es soll "Köln" zu lesen sein und nicht "K{ln" oder ähnlich falsch.

Umgekehrt soll es auch funktionieren, also Erfassung französischer Sonderzeichen und richtige Darstellung in Deutschland und/oder Erfassung deutscher Sonderzeichen in Frankreich.

Das Ganze am besten mit allen Ländern dieser Welt ;-).

Gibt es da sowas wie einen UNICODE Zeichensatz, der alle Zeichen enthält und überalle installiert werden muß ?

Für alle Ansätze bin ich dankbar.

Thomas

[Fuerchau]

Wirklich ein Dauerthema !
Natürlich gibt es Unicode, aber auch den inzwischen in mehreren Varianten:
UCS-2: 2-Byte-Zeichensatz, ca. 65000 Zeichen
UCS-4: 4-Byte-Zeichensatz (ist allerdings nicht auf der AS/400 verfügbar)

Zusätzlich gibts da noch:
UTF-8: 1-4 Byte pro Zeichen, also variable Breite
UTF-16: 2-4 Byte pro Zeichen

Aber im Terminal (5250) siehts da ganz anders aus:
Standardmäßig arbeitet die Emulation (CA, Telnet, Mocha, usw.) im SBCS-Zeichensatz, d.h. genau 1 Byte pro Zeichen, wobei alle Zeichen EBCDIC < X'40' als Steuerzeichen verloren gehen.
SBCS wird in Sprachräume unterteilt (Latin1-7 und inzwischen mit Varianten).
In diesen Sprachräumen werden variante und nicht variante Zeichen unterschieden:
Nicht variante Zeichen = in allen Sprachräumen identisch
variante Zeichen = können je nach Sprachraum unterschiedlich sein.

Kommen wir nun zum Sprachraum:
In den CCSID's eines Sprachraumes gibt es für jedes Zeichen auch genau ein passendes in ggf. anderem Hexcode, so dass bei der Konvertierung nichts verloren geht.
Konvertiert man allerdings von Sprachraum 1 nach 2 und umgekehrt, bleiben nur die nichtvarianten Zeichen identisch, bei allen anderen kann es zu Verlusten kommen.

Dann gibt es noch den Unterschied zwischen CCSID und CHRID:
CCSID = interne Speicherungsform, also der Hexwert
CHRID = externe Darstellungsform, also das sichtbare Zeichen.

Wie geht die AS/400 damit um (schon mehrfach beschrieben):
Zwischen Datenbank und Job wird eine Codewandlung durchgeführt, sobald beide eine andere CCSID als 65535 haben (HEX). Dazu gehört übrigens auch eine MSGF !

Zwischen Job und Terminal wird nur dann eine Codewandlung durchgeführt, wenn dies per CHRIDCTL auch definiert ist und von den DSPF's, MNU's usw. unterstützt wird.
Ansonsten erfolgt nämlich KEINE Codewandlung.
D.h.: Die CA-Sitzung ist in der Hostcodepage einzustellen, die der Dialogjob verwendet ! Ansonsten kommt es nämlich zum berühmten Datensalat: ö = { u.ä.
Das selbe gilt auch für PRTF's, wobei hier die später zu verwendende CHRID einzustellen ist (bei AFPDS/IPDS auch auf Feldebene möglich). Allerdings sind ggf. WSCST-Objekte zu erstellen, die beim Drucker dann auch eine Codepageumschaltung erreichen.

Die einzig sichere Möglichkeit alle Zeichen für einen Anwender verfügbar zu machen, ist eine Client-Server-Lösung, die die Daten ausschließlich per SQL austauscht, wobei für die AS/400 gilt, dass a) die Daten in UCS-2 (CCSID 13488) gespeichert sind und b) die SQL's auch in UCS-2 ausgetauscht werden (ODBC-Einstellung).

Solange man seine Datenbank immer noch in SBCS speichert und CA-SBCS-Sitzungen verwendet, gibt es ABSOLUT KEINE Möglichkeit, sämtliche Zeichen aller Sprachräume GLEICHZEITIG zu verwenden !

[Deficiency]

Das ist schon ein grauß mit den Sonderzeichen! Da soll man International sein und nichts funktioniert...!

[Liebhoff]

Ich muß an dieser Stelle mal unseren guten FUERCHAU loben, der hat dieses Thema wie ich finde nämlich so kurz, knapp und informativ zusammengefaßt, wie es nur geht. Danke nochmal dafür. Vielleicht hat ja der ein oder andere noch ein paar nette Tips und Tricks dazu auf Lager. Alles kann helfen, wenn am Ende auch jeder selber seiner Sonderzeichen Herr werden muß.

Thomas

[spiceisnice]

Hallo,
welche Methode funktioniert dann am Besten wenn man eine derartige Datenbank(zB. globaler Kundenstamm 273 auch für CZ,HU,PL etc.) ohne Verlust der jeweiligen Sonderzeichen(also zB. nur der Kundenstamm auf PL eingeschränkt, ist aber auch 273 da ja die gleiche Datei) nach EXCEL oder ähnliches PC'File transferieren möchte ?

Filetransfer oder FTP oder CPYxxx ? Oder erst nachher im EXCEL die Fehler korrigieren (Makro) ?

[Fuerchau]

Tja, ähem, ....

Nun kommt es darauf an, wie denn die Daten erfasst werden.
Wenn z.B. polnische Daten ausschließlich an polnischen Terminals erfasst werden, kommt es ja nur auf die korrekte Darstellung an. Dies lässt sich per SQL mit doppeltem CAST erreichen:

cast ( cast(myfield as char(xx) ccsid 65535) as char(xx) ccsid 870)

xx = Länge des Feldes

Dadurch wird eben der Code als polnisch angenommen.

[spiceisnice]

Eingabe und Darstellung erfolgen jeweils in einer 'sauberen' Umgebung je Land und sind OK.

Erstelle ich jetzt mit SQL eine eigene Zwischendatei(worauf muss man dabei achten), setze die in Frage kommenden Felder wie beschrieben mit SQL um und mache dann einen Filetransfer ?

[Fuerchau]

Du kannst direkt per CREATE VIEW eine Sicht erstellen, die du dann einfach per ODBC (MS-Query) überträgst. Filetransfer führt ggf. wieder zum Verlust der Zeichen wenn du keinen polnischen PC verwendest.
Ggf. ist auch ein CAST (... as graphic(xx) ccsid 13488) (UCS-2/UNICODE) erforderlich.

[spiceisnice]

Also das habe ich mal so gemacht, OKCUNM ist der Kundenname mit Sonderzeichen :

CREATE VIEW TESTLIB/TESTFILE (OKCUNO, OKCUNM, OKCUNMUNI) AS SELECT
OKCUNO, OKCUNM, CAST(OKCUNM as graphic(36) ccsid 13488) FROM
DATA/KUNDEN WHERE OKCUNO like '07%'

Gibt's jetzt im ODBC noch spezielle Einstellungen ? Umsetzung etc...

[Fuerchau]

Da ist leider noch ein Fehler drin, da durch die einfache Konvertierung ja von 273 nauch UCS-2 gewandelt wird und somit bleibt alles westeuropäisch.
Für solche Fälle brauchst du ein 3-fach Cast:

cast ( cast ( cast (myfield as char(xx) ccsid 65535) as char(xx) ccsid 870) as graphic(xx) ccsid 13488)

Inner-Cast: betrachte die Zeichen als Hex ohne Codewandlung
Middle-Cast: nimm die Hex-Werte als 870 Osteuropa an
Outer-Cast: Wandle die Osteuropa-Zeichen in UCS-2 ohne Verluste

Im ODBC sind keine weiteren Einstellungen nötig (ab V5R1), da die Graphic-Felder als W-String erkannt werden. ACCESS/MS-Query könnte ggf. Schwierigkeiten machen, da diese mit DAO arbeiten.
Bei nativen ADO-Zugriffen gibt es jedoch keine Schwierigkeiten.

[spiceisnice]

Also so geht's - Vielen Dank. Habe auch fürs Verständnis einiges dazugelernt.