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.