Wieder mal CCSID-Problem

[KM]

Ich habe wieder mal ein Problem mit der Code-Konvertierung diverser Codepages. Ich habe eine iSeries-Datei mit CCSID 1153 (= Polnisch). Die Daten stehen da korrekt drin. Wie schaffe ich es nun diese Daten z.B. in Excel zu kopieren, sodass die Zeichen nach der Übertragung immernoch korrekt sind (Polnisch) ? Ein File-Transfer erstellt mir immer eine Datei mit CCSID 819. Dieser Zeichensatz enthält natürlich keine polnischen Zeichen. Deshalb werden wohl Ersatzzeichen genommen. Wenn ich diese jetzt mit CPY in eine Datei mit CCSID 852 kopiere und danach den File-Transfer nochmal in diese neue Datei ausführe, ist die Konvertierung immernoch falsch. Auch diverse Tests mit Codepage 1252, 1250, 850, 852, usw. blieben erfolglos. Ich habe inzwischen auch schon mein Windows auf Polnisch umgestellt. Leider bis jetzt alles ohne Erfolg.

Weiß jemand einen Rat ?

Danke,
KM

[Fuerchau]

Stelle die Daten in eine Datei als UTF-8 (CCSID 13488) und lade diese dann aus Excel per MS-Query und ODBC (nicht mit den Filetransfermethoden).
per SQL:

create table myutf8 (fldutf8 graphic (100) ccsid 13488 not null with default)

insert into myutf8
select fldchar from myfile

[KM]

Vielen Dank, so funktioniert es. Aber ist das denn die einzige Möglichkeit ? Geht es nicht mit "herkömmlichen" Mitteln (CCSID der Datei; Filetransfer, etc.) ? DDS-beschriebene Dateien kann ich ja gar nicht auf 13488 ändern. Der Umweg über SQL-beschriebene Datei und MS-Query ist etwas aufwendig in meine Applikation zu implementieren.

Gruß,
KM

[Fuerchau]

Das liegt leider an den verschiedenen Sprachräumen Latin1/2.
Du kannst aber auch mittels CREATEVIEW und casting das Ergebnis ohne Umwege erreichen:

create view myview as select graphic(fldcar, 30, 13488) as fldchar from myfile

Dann kannst du per MS-Query / MS-Access o.ä. direkt auf die Inhalte gehen.

Das Problem sind die Standard-Transfer-Pgm'e, die keinen Unicode (13488) unterstützen.
Du kannst natürlich auch per CPYFRMIMPF eine Stream-Datei ins IFS mit 13488 stellen. Das Zielprogramm muss allerdings die Datei im UTF-8 verstehen.

Frage:
Ist das eine PC-Applikation ? Dann könntest du ganz normal per ODBC auf obige View zugreifen.

[KM]

Kurze Erklärung zu meiner Applikation:
Ich habe ein Frontend-Programm (Greenscreen), in dessen Maske ich einen SQL-Select absetzen kann. Im RPG-Programm selbst wird dieser SQL-Befehl über das API QSQPRCED (extended dynamic SQL) verarbeitet. Die selektierten Daten werden dann im RPG-Programm mittels Java-Methoden (HSSF) direkt in eine Excel-Tabelle geschrieben, die automatisch erstellt wird. Somit kann ich voll automatisiert iSeries-Daten in eine native Excel-Tabelle schreiben. Wenn ich nur im Latin-1 Bereich arbeite, funktioniert das auch wunderbar. Nur bei Latin-2 wird die Umsetzung nicht korrekt durchgeführt. Liegt vermutlich am API.

Ich habe jetzt herausgefunden, dass ich die iSeries-Datei mit CCSID 1153 mit MS-Query korrekt in Excel laden kann, ohne den Umweg über Unicode. Ist halt leider ein manueller Schritt. Aber damit kann ich leben.

Gruß,
KM

[Fuerchau]

Java verarbeitet eigentlich grundsätzlich Unicode !
Übergeb doch den generierten SQL an Java und führe diesen miitels java.sql-Package aus. Dann gibts auch kein Problem mit der Umsetzung.

[Fuerchau]

PS:
Kannst du mir die Adresse geben, wo du das Java-Package für Excel her hast ?

[KM]

Auf folgender Seite findest Du mehr darüber:

http://jakarta.apache.org/poi/index.html

Mittels HSSF kann man Excel-Dateien erstellen und bearbeiten, mit HWPF Word-Dokumente. Wir erstellen z.B. aus unserer Kundenstamm-Verwaltung per Funktionstaste ein Word-Dokument, in das dadurch bereits die Anschrift des Kunden vorgegeben wird.

Kannst auch mal nach SQL2XLS suchen. Das ist dieses Tool, das ich verwende, um iSeries-Daten nach Excel zu transferieren.

Gruß,
KM

[KM]

Was ich nur nicht ganz verstehe, jetzt mal völlig unabhängig von Unicode. Warum wird von Codepage 1141 beim Filetransfer offenbar korrekt in die Windows-Codepage 1252 konvertiert, während die 1153 (für Polnisch) nicht korrekt in die 1250 konvertiert wird ? Oder kann man das woanders noch irgendwie einstellen ?

[Fuerchau]

Die CCSID 1141 unterscheidet sich von 273 einzig im €-Zeichen ist aber ein 1-Byte-Code.
Der DB-Serverjob der AS/400 fährt nun mal auch mit einem 1-Byte Code (entweder 273 aus QCCSID oder 037 für Default.). Dadurch werden die Daten dem DB-Job natürlich übersetzt weitergegeben. Beim Transfer von 1153 (870 ohne €) kommt es zum Verlust der Darstellung.

Windows-Programme arbeiten aber mittlerweile immer (bis auf wenige Ausnahmen) mit Unicode ! Der 1-Byte-String des DB-Server-Jobs wird somit von 273/037 in Unicode des PC's gewandelt und somit bleibt ein Ü ein Ü auch wenn das Windows Polnisch ist.

Anders siehts nun mal bei CCSID 13488 aus. Dies ist UNICODE !!!
Der DB-Job erhält die Daten als GRAPHIC-Feld (also 2-Byte-Code) und gibt diese auch so weiter. Der Empfangsjob erhält einen 2-Byte-Unicode und passt diesen ggf. nur geringfügig an Windows an.

[KM]

Das ist ja genau meine Frage. Wenn der DB-Server-Job die 1141 bzw. 273 korrekt in Unicode des PCs konvertiert, warum dann nicht die 1153 ??? Kann ich dem DB-Server irgendwie mitteilen, dass ich von 1153 konvertieren will, damit er auch diese Zeichen korrekt in Unicode umsetzt oder ist das grundsätzlich nicht möglich ? Ich möchte halt erstmal herausfinden, ob ich die vorhandenen Dateien automatisch vom System konvertieren lassen kann, bevor ich weitere Dateien mit Unicode erstelle.

[Fuerchau]

Versuch es doch mittels der View, die bereits korrekt in UNICODE umsetzt. Oder besser noch, verwende JAVA auch zum Abfragen der DB (Grund siehe oben).

Leider geht das ansonsten so nicht !!
Begründung:
Solange dein System ein SBCS-System ist (Singelbytecharacterset) muss ein Job auch mit einer SBCS-CCSID arbeiten.
Alle Jobs erfahren dann halt eine Code-Wandlung der Daten in die jeweilige CCSID (Ausnahme 65535!). Beim Schreiben der Daten werden diese nun wieder in die SBCS-CCSID der PF zurückgewandelt.

Wie wir ja wissen, gibts zwischen Latin1/Latin2 im SBCS Verluste, die man nur mit DBCS (Doublebytecharacterset) ausgleichen kann. Da Excel nun mal im UNICODE (=DBCS 13488) arbeitet, wird nun mal der Hexwert eines SBCS-Jobs der entsprechenden DBCS-Stelle zugeordnet und somt die Codewandlung durchgeführt.

Korrekt kann das ganze nur funktionieren, wenn der Job der dies durchführt mit einer kompatiblen CCSID fährt.
Solange das System ein SBCS ist, kann ein Job keine DBCS-CCSID annehmen. Also ist er gezwungen die Daten so zu verarbeiten wie sie ankommen.
Bei CCSID 65535 (Job/Datei oder sonst wo) erfolgt keine Datenumsetzung der SBCS !
Die Anwendung (oder der User) muss also GENAU wissen, welche Daten angenommen werden sonst kommt es (wie so häufig) zum Datenchaos. Ich kann also duchaus Latin1-Zeichen in eine Latin2-DB schreiben und hoffen dass diese auch das nächste mal so zurückkommen, ggf ein ein anderer User den Wert an einem Latin2-Teriminal "korrigiert" und der Latin1-User wundert sich.
Auch beim späteren gemeinsamen Ausdruck / Download o.ä. ist die Eindeutigkeit der Zeichen nicht mehr gewährleistet

Also: Der Job muss mit seiner CCSID immer zur CCSID der DB UND der AUSGABE/EINGABE-Geräte passen !!!

Wie kann ich nun in einem Job Latin1 und Latin2 oder chinesisch, türkisch usw. verarbeiten ? ===> UNICODE 13488

Dazu muss das System aber auf DBCS umgestellt werden !!!
Die Programme müssen ihre Zeichenfelder als GRAPHIC-Felder verwenden, Zeichenkonstanten müssen als G'...' umgesetzt werden, usw. usw. usw., die Latte erscheint endlos.

Will ich das nicht, bleibt mir nur SQL (System bleibt SBCS) und die Variablen die ich benötige definiere ich als GRAPHIC !

Warum kann das System das nicht automatisch ?
Nun, mit welcher CCSID arbeitet denn dein Java-Job (im Batch) um mit der 1153 umzugehen ? Wahrscheinlich in 273 oder 1141 ! Und nun weißt du auch warum bei der Ausgabe in Excel die polnischen Zeichen verloren gehen.
Ändere den Job (keine Ahnung wie in Java) auf 1153 ! Dann müsste es gehen.

Oder: Generiere den SQL mit casting in GRAPHIC, so dass dein Java bereits UNICODE bekommt.

Und zum Schluss !
Warum klappt UNICODE per ODBC aber 1153 nicht ?
Auch der DB-Server arbeitet mit SBCS und die CCSID wird auf Grund der installierten Primär-Sprache der AS/400 (Latin1/2) und nicht des PC's entschieden. Der PC ERWARTET also Latin1-Daten beim SBCS und wandelt diese in den PC-korrespondierenden UNICODE um und somit bleibt auch bei CP1252/CP1250 ein 273/1141-Ü immer ein Ü.

PS:
Was ich noch nicht ausprobiert habe ist (seit V5R2) die direkte Angabe der CCSID im ConnectionString (ODBC-Registrierung->Umsetzung->Erweitert).