CCSID Problem aufs Neue

[b.horstmann]

Hallo Interessierte,

ich war mal wieder an meinen Problem und wollte ein "vorläufiges Endergebnis" kurz mitteilen. Zur Erinnerung: Excel-Daten, die in Kroation auf einem kroatischen PC (Codepage 852 Latin2) erstellt werden soll in eine iSeries-Datei (CCSID 870) übernommen werden (... durch ein USRPRF/JOB mit CCSID 870, LANGID HRV, der Rest der DB hat CCSID 273 Latin1). Ich möchte das ganze mit iSeries-Mitteln lösen.

Der einzig gangbare Weg zur Übernahme ist ein CPYFRMSTMF in eine TEMP-File mit CCSID 65535 und dann ein CPYF in die eigentliche Zieldatei mit CCSID 870. Bei dieser Vorgehensweise gibt es keinen Zeichenverlust - zumindest konnte ich keinen mehr feststellen.

Das Hauptproblem dabei ist das Ausspielen aus Excel als .CSV bzw. .TXT. Wir haben inzwischen einen kroatischen PC bei uns im Netz und wenn ich von diesem aus, direkt ins IFS die Daten ausspielen - und dann übernehme (siehe oben) - nur dann habe ich keinen Zeichenverlust. Komischer Weise wird immer(!) für die von Excel ausgespielten Daten die Codepage 1252 (Ansi Latin1) angezeigt - egal ob von einem deutschen oder von dem kroatischen PC aus (hat jemand eine Erklärung dafür?). Vom kraotischen PC aus sind aber die Zeichen korrekt und werden korrekt auf die iSeries übernommen.

soviel für heute

[Fuerchau]

Beim Zugriff auf das IFS wird die Default-CCSID im NetServer eingestellt.
Dies hat auf die Daten selbst keine Auswirkung, da der Copy ja immer Binär ausgeführt wird.
Einzig bei den CPY-Befehlen kann man auf die CCSID der Datei (*STMFILE) verweisen oder aber eben eine eigene bzw. *NONE angeben.
Das Problem von Excel ist eben, dass beim Export in Text/CSV die Codepage des Windows verwendet wird und somit eine Umwandlung von Unicode in die ANSI-Codepage vorgenommen wird.

Beim CPYF mit einer CCSID 65535 (*HEX) wird eben auch keine Codewandlung vorgenommen.

[b.horstmann]

>Das Problem von Excel ist eben, dass beim Export in Text/CSV die Codepage des >Windows verwendet wird und somit eine Umwandlung von Unicode in die ANSI->Codepage vorgenommen wird.

ich hätte aber erwartet, dass auf einem PC der komplett kroatisch eingerichtet ist - d.h. WIN2000 in kroatisch (von einer kroatischen CD aus Kroatien!!!) und MS-Office in kroatisch, dass dann kein ANSI-Westeuropäisch (Codepage 1252) auftaucht. Ich habe das Gefühl, dass das aber in Excel (und auch in ACESS) festverdrahtet ist.

[Fuerchau]

Dem ist nicht so, sonst würde Office in Kroatien enorme Schwierigkeiten haben.
Auch Office verwendet die normalen Windows-Kernel-Funktionen für Codeumwandlungen und diese verwenden immer die aktuellen Ländereinstellungen des Windows.
Bei der Ausgabe ins IFS hat die Datei aus AS/400-Sicht zwar das Attribut CCSID 1252(NetServer), aber Windows weiß das nicht.

Ggf. könnte noch ein ODBC-Problem im CA beim Zugriff von/nach AS/400 bestehen da hier die aktuellen Einstellungen der AS/400 verwendet werden.
Hierfür kann man bei der ODBC-Konfig für Datenumsetzung dann CCSID 1251 vorgeben.