Sonderzeichen bei Spoolfilekopie aus dem iSeries Navigator

[Markus Gruebl]

Hallo,

ich hatte zu erwähnen vergessen, dass der Anwender der die Datei kopieren will angeblich ein Tschechisches Windows hat und es geht trotzdem nicht... Das muss ich aber nochmal prüfen nur der gute Mensch hat Urlaub....

Die User Profiles sind bei uns mit CCSID 65535 angelegt. Wenn nun so ein "normaler" User einen Spool in eine Windowsdatei kopiert tritt das Problem auf.
Eine mögliche Lösung ist einen "abgespeckten User" anzulegen der nur für diese Kopierfunktion genutzt wird und werden kann. Dieser User hat dann die CCSID 1153. Ich habe das getestet und es klappt dann auch mit dem Kopieren des Spools.

[Sven Schneider]

Ausprobiert habe ich es noch noch, aber versuch mal unter "iSeries Access für Windows - Eigenschaften" --> Sprache mit den Codepage Einstellungen zu spielen.

Wie gesagt , ich weis nicht ob der OpsNav das in diesem Fall berücksichtigt.

[Fuerchau]

@Sven
Es kommt auf die Windows-Codepage und nicht auf die AS/400-CCSID an.

Es ist immer eine Frage des Font's, der für die Darstellung der Zeichen zuständig ist.

[Sven Schneider]

@Sven
Es kommt auf die Windows-Codepage und nicht auf die AS/400-CCSID an.

Es ist immer eine Frage des Font's, der für die Darstellung der Zeichen zuständig ist.

Genau diese kann ich u.a. dort pflegen.

-ANSI-Codepage

Gibt die Nummer der ANSI-Codepage an, mit der die aktuelle ANSI-Codepage des Clients überschrieben werden soll. Geben Sie die entsprechende Nummer der ANSI-Codepage ein, oder wählen Sie in der Liste die Angabe "Standardwert" aus, um iSeries Access für Windows anzuweisen, die ANSI-Standardcodepage des Clients zu verwenden.

- OEM-Codepage

Gibt die Nummer der OEM-Codepage (OEM = Original Equipment Manufacturer) an, mit der die aktuelle OEM-Codepage des Clients überschrieben werden soll. Geben Sie die entsprechende Nummer der OEM-Codepage ein, oder wählen Sie in der Liste die Angabe "Standardwert" aus, um iSeries Access für Windows anzuweisen, die OEM-Standardcodepage des Clients zu verwenden.

- EBCDIC-CCSID

Gibt die ID des codierten Zeichensatzes (CCSID) für den EBCDIC-Zeichensatz an, mit der die aktuelle EBCDIC-CCSID überschrieben werden soll.

Anmerkung

Bei Angabe eines Werts "Standard" im Feld für die EBCDIC-CCSID wird die CCSID für alle Server, mit denen dieser Client verbunden ist, überschrieben.

Die Einträge werden in der Windows Registrierung abgelegt unter :

\HKU\Software\IBM\Client Access Express\CurrentVersion\NLS

Ich weis nur nicht, welche iSeries Access-Funktion diese Einträge benutzt.

[Fuerchau]

Das ist zwar korrekt, aber für Windows unerheblich.

Wenn in Windows eine TXT-Datei in SBCS geöffnet wird, entscheidet die aktuelle Windowsumgebung über die Darstellung der Zeichen.
Steht Windows auf 1252 (Latin1) werden osteuropäische Zeichen eben nicht dargestellt, da die Codes durch westeuropäische Zeichen belegt sind.

Du kannst es auch einfach wie Fonts vergleichen.
Erfasse ich in Word deutsche Zeichen und ändere den Font auf Wingdings (Symbol o.ä.) wird eben was anderes dargestellt.

Die selben Probleme hast du auch manchmal beim Austausch mit Linux/Unix oder wenn du noch TXT-Dateien aus einer DOS-Welt (Codepage 850) bekommst.

Du kannst es auch einfach ausprobieren:

Starte NOTEPAD, erfasse ÄÖÜ und speicher die Datei als TXT.
Starte eine DOS-Box und öffne diese Datei mit EDIT, dann verstehst du, was die grundsätzliche Problematik des Datenaustausches zwischen Sprachräumen in SBCS ist.

OEM-Codepage ist in deutschen Windows die 850, ANSI dann 1252.
CCSID eben 273, 500, 037 u.s.w.

Für Polnisch/Chechisch ist OEM 852, ANSI 1251, CCSID 870,1153 u.ä.

Durch die Windows-Sprachumgebung kann ich OEM und ANSI beeinflussen.

Einzig UNICODE/UCS und UTF unterstützen mehrere Sprachräume.