CCSID Problem aufs Neue

[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.