View Full Version : UTF16DB --> Import auf SQL Server
Hallo zusammen,
ich habe mir eine PF-DTA mit CSSID 1200 gebaut.
Dort kann ich (wenn ich meine CA Sitzung auf Russisch konfiguriere) auch mein Umgedrehtes "R" eingeben und auch in der DB speichen und in meinem RPGLE auch immer Anzeigen lassen kann.
Gut STRSQL und so zeigt mir nichts Sinnvolles mehr an aber egal.
Wenn ich mir die Daten über z.B. OLE DB migrieren will, dann steht in der DB hinterher komische Sonderzeichen.
Ich dachte immer der Vorteil einer UTF-DB sei, das alle Sonderzeichen unabhängig der lokalen Einstellung gespeichert werden?!?!?
Mache ich was falsch oder verstehe ich was falsch?
Danke an allen Helfenden!
UTF-16 ist noch ein eher seltenes Format.
Besser ist CCSID 13488 (UNICODE bzw. UCS2).
Das wird auch vom SQL-Server verstanden.
Ob das mit dem Russisch klappt, kann man z.B. über MS-Query, also Excel-Import, testen.
Allerdings nicht von der Vorschau von MS-Query verwirren lassen, da dies keine UCS2-Anwendung ist.
In Excel stehen die Daten dann sauber und sind auch als russisch lesbar.
Des weiteren hast du mit UCS2 auch in der Programmierung (ILERPG/COBOL) die volle Unterstützung, während du bei UTF8/UTF16 ständig selber die Codewandlungaufrufen musst.
Hallo Fuerchau,
danke erstmal für deinen Tipp.
Habe die DB mit CSSID 13488 erstellt, und aschließend in RPG per %UCS2 und %CHAR die DSPF-Felder gefüllt.
Habe dann in einer deutschen Sitzung eine email Adresse angegeben und gespeichert.
Schließend habe ich über eine russiche Sitzung mir den DS anzeigen lassen.
Resultat: Das @ ist kein @ ?!?!
Wie bereits erwähnt denke ich das der Vorteil der 2-Byte DB darin liegt, diese Sonderzeichen "global" zu übergeben.
Wo liegt mein Fehler?
Danke
An den diversen Ebenen der CCSID.
Welche Hostcodepage hat deine Sitzung?
Welche CCSID hat dein Job?
Zwischen Sitzung und Job wird keine Codewandlung durchgeführt.
Mittels %char wird die Job-CCSID verwendet.
Dein Problem ist, dass das @-Zeichen in deinem Programm nicht passend zum Terminal verarbeitet wird.
Übrigens:
Die DSPF unterstützt auch G-Felder mit CCSID 13488!
Die Codewandlung zwischen UCS2 und Terminal erfolgt dann automatisch.
Unicode considerations for display files (http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzakc/dspfil.htm)
Da UCS2-Felder doppelt lang sind, kann man die DSPF-Länge spezifisch anpassen:
CCSID keyword considerations for display files that use Unicode data (http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzakc/rzakcmstdfusc2.htm)
Hallo Fuerchau,
habe jetzt mal folgendes probiert:
1. G-Felder in DSPF mit CCSID 13488 eingefügt.
A WWTXT1 50G B 5 15CCSID(13488 25)
A 6 3'Text2 :'
2. Die komplette DB ist mit dem CCSID Keyword auf Recordebene auf 13488 gesetzt.
A CCSID(13488)
A R UTF16R
3. Jegliche Umsetzung (%CHAR %UCS2 ist aus dem RPG-Prpgramm entfernt.
C EVAL ATXT3 = WWTXT3
4. Eine Sitzung mit wie folgt definiert:
[5250]
ScreenSize=27x132
HostCodePage=1154-SC
Andere Sitzung wie folgt definiert:
[5250]
ScreenSize=27x132
HostCodePage=1141-G
Job ist immer wie folgt defineirt:
Sprachen-ID . . . . . . . . . . . . . . . . . . . : DEU
Landes- oder Regions-ID . . . . . . . . . . . . . : DE
ID des codierten Zeichensatzes (CCSID) . . . . . : 65535
Standard-ID des codierten Zeichensatzes . . . . . : 273
Das @-Zeichen wird mir auf beiden Sitzungen jetzt sauber angezeigt. Die Zeichen ÜÖÄ wird auf der Russ. Sitzung nur noch als Highlight angezeigt?
Irgendwie gerät mein UNICODE Weltbild gerade aus den Fugen ;)
Das Problem hier ist nun mal leider Windows.
Eine Codepage in der 5250-Sitzung die nicht zur Codepage des Windows passt, kann nicht funktionieren.
Begründung:
Die 5250-Emulation arbeitet als Terminal im SBCS, also kein Unicode.
D.h., dass die Tastaturzeichen aus Windows-ANSI an die Emulation geht.
Diese nimmt jetzt die Hostcodepage und wandelt auf dieser Codepoint-Basis (Zeichenwert des ANSI-Zeichens) in EBCDIC um und sendet an die AS/400.
Die Terminal-Schicht bekommt also nun den EBCDIC-Wert, identifiziert durch die Hostcodepage, und wandelt dann in UCS2 um bevor das Programm den Inhalt bekommt.
Bei Nicht-UCS2-Feldern erfolgt nämlich keine Umwandlung.
Bei der Ausgabe wird dann von UCS2 in die EBCDIC-CCSID des Terminals umgewandelt.
Die 5250 wandelt nun von EBCDIC in die Windows-Codepage und zeigt dann mit der eingestellten Schrift an.
Also auch die Schrift der 5250 muss dann russisch können. Diese iststandardmäßig auch nicht installiert.
Das Problem also ist, dass der Translate von Windows-Codepage in die EBCDIC-CCSID hier fehlschlägt, umgekehrt natürlich genauso.
Zufällig ist wohl das @-Zeichen in den Codepages das selbe, deshalb funktionierts.
Um also die 5250-Russisch zu testen musst du in Windows eine zusätzliche Sprache (Systemsteuerung->Region und Sprache->register Tastaturen), nämlich russisch, installieren und beim Aufruf der 5250-Sitzung dann auf diese Sprache umschalten.
OK, in Windows wird natürlich auch alles russisch dargestellt, du suchst dir da also jemanden, der das beherrscht:).
In Windowsanwendungen mit SBCS hat man genau die seleben Probleme (Beispiel MS-Query). Hier ruft man 2 Windows-API's auf (von MultiByte in Singlebyte bzw. umgekehrt), wobei dann eben Ersatzzeichen (MBCS->SBCS) genommen werden.
Auch die Funktion %CHAR(UCS-Feld) wandelt auf Basis der Job-CCSID um!
Steht die auf *HEX (wie dein Job jetzt) ist das auch nicht so klar, was die Funktion dann macht, könnte sein, dass er dann mal wieder 037 annimmt.
Nachtrag:
Auch PRTF's erlauben UCS2!
Wobei dann die CHRID (CRTPRTF/OVRPRTF) zum Erstellzeitpunkt des Spools für die korrekte Darstellung im Spool sorgt, eine spätere Anpassung geht nicht mehr.
Mit dem DDS-Schlüsselwort FONT kann man eine UCS2-fähige Schrift auswählen (muss auch installiert werden, OpenType/TrueType), dann klappts auch mit PDF's.
Ob Hosttransform das auch kann, konnte ich noch nicht ausprobieren.
Danke Fuerchau für die Ausführliche Problembeschreibung.
Warum kann nicht mal was einfach sein :)
Dann werde ich mal versuchen auf HEX-Ebene zu Vergleichen und eventuell an der PC-Anwednung schrauben.
Aber auf jeden Fall Danke erstmal!