fopen() codepage für ANSI

[Marsman]

Hallo!

Ich habe mal eine Frage zur Standard-C Funktion fopen(): Welche Codepage oder CCSID muss man angeben, um bei Schreiben in eine IFS-Textdatei die Daten im ANSI-Format zu erhalten? Ich möchte das gleich Ergebnis erhalten, wie beim Befehl CPYTOSTMF STMFCODPAG(*PCASCII).

Ich habe schon 850 versucht. Die Datei wird dann trotzdem mit 273 erstellt und es werden unter Windows nur wirre Zeichen angezeigt.

Danke schonmal für jede Hilfe,

Titus

[Fuerchau]

1252 ist Windows-Codepage.

[Marsman]

Oh, danke für die schnelle Antwort. Leider klappt das aber irgendwie nicht. Wenn ich bei fopen() als ccsid oder als codepage den Wert 1252 angebe, hat die Ausgabedatei die CCSID 5348 und es werden immernoch wilde Zeichen angezeigt.



Titus

[Fuerchau]

Um eine CCSID/Codepage zu bestimmen, darf die Datei nicht bereits existieren, sonst behält sie ihre alte Codepage.
Codepageunterstützung gibt es nur im IFS nicht im QDLS oder QNTC.

Wenn man im C-Handbuch nachliest, erwartet das IFS die Daten bereits in der angegebenen Codepage, man muss die Codewandlung also selber durchführen (leider).

Macht man z.B. einen fpen(... codepage=1252) müssen die Daten in 1252 geschrieben werden. Existiert die Datei bereits, wird von 1252 in die Codepage der Datei gewandelt.

Es stellt sich also so dar, als ob der Job temporär auf diese Codepage gesetzt würde (schreiben und lesen).
Für die Codewandlung gibt es wiederum eigene API's:
http://publib.boulder.ibm.com/iserie...s/iconvopn.htm

[Fuerchau]

Wenn man noch ein wenig weiterliest gibt es "o_ccsid" bzw. "o_codepage". Damit sind wohl die echten File-CCSID's gemeint.

[BenderD]

Hallo,

der Trick mit nicht vorhanden und automatisch konvertieren geht mit:
öffnen mit Codepage und Create
schließen
neu öffen mit Textdata und ohne Codepage Angabe

Beispiel dazu auf meiner OpenSource Seite (nach OUTSTREAM suchen)

mfg

Dieter Bender

Um eine CCSID/Codepage zu bestimmen, darf die Datei nicht bereits existieren, sonst behält sie ihre alte Codepage.
Codepageunterstützung gibt es nur im IFS nicht im QDLS oder QNTC.

Wenn man im C-Handbuch nachliest, erwartet das IFS die Daten bereits in der angegebenen Codepage, man muss die Codewandlung also selber durchführen (leider).

Macht man z.B. einen fpen(... codepage=1252) müssen die Daten in 1252 geschrieben werden. Existiert die Datei bereits, wird von 1252 in die Codepage der Datei gewandelt.

Es stellt sich also so dar, als ob der Job temporär auf diese Codepage gesetzt würde (schreiben und lesen).
Für die Codewandlung gibt es wiederum eigene API's:
http://publib.boulder.ibm.com/iserie...s/iconvopn.htm

[Marsman]

Hallo!


Erstmal danke für die Hinweise. Dass ich die Daten selbst umwandeln muss, hatte ich schon fast befürchtet. Ich denke ich werde das mit den Umwandlungs-APIs mal ausprobieren. Hat eventuell sogar jemand Beispiel-Code? Ich bin in C und diesen CCSID-Geschichten nicht so fit und das würde mir die Arbeit sicher sehr erleichtern.

Was ich in dem Zusammenhang schon immer mal fragen wollte: Wo ist eigentlich der Unterschied zwischen Codepage und CCSID? Was bewirken die Eigentlich genau?

Gruß, Titus

[Fuerchau]

Da gibt es keinen Unterschied.
CCSID ist der AS/400-Begriff: CodedCharacterSetIdentification.
Codepage (CP) wird in der PC und Unix-Welt verwendet.

Die CCSID ist die interne Speicherungsform der Zeichen, so dass ein Ä immer den gleichen Hexwert annimmt.
Beim Konvertieren von einer CCSID zur anderen wird der Hexwert ausgetauscht (EBCDIC->ASCII/ANSII, 273->297, usw.).
Manchmal gibt es da halt Probleme, da es nicht immer entsprechende Zeichenzuordnungen gibt.
Man spricht daher von sog. invarianten Zeichen, die in jeder CCSID identisch sind, bzw. von varianten Zeichen, die eben je nach CCSID unterschiedlich sind.
Siehe hierzu: http://publib.boulder.ibm.com/iserie...ractersets.htm

Im Gegensatz hierzu steht die CHRID (CharacterIdentification), die der Darstellung der Zeichen entspricht.
In der PC-/Druck-Welt entspricht das dem Font (Schriftart).
Ein Beispiel in der Windows-Welt kannst du z.B. mit dem Symbol-Font sehen. In diesem Font entspricht jeder Hexwert einem Symbol an Stelle eines Druckzeichens.

Was deine IFS-Datei angeht, so würde ich Dieters Vorschlag anwenden.
Wichtig nochmal, auch dein Job muss in einer EBCDIC-CCSID laufen, z.B. 273, sonst klappts wieder nicht.

[Marsman]

Was deine IFS-Datei angeht, so würde ich Dieters Vorschlag anwenden.
Wichtig nochmal, auch dein Job muss in einer EBCDIC-CCSID laufen, z.B. 273, sonst klappts wieder nicht.

Aha, alles klar. Mein Job läuft aber in CCSID 65535, aber als "Standard-ID des codierten Zeichensatzes" die 273. Ist das okay?


Gruß, Titus

[Fuerchau]

Nein. Die Standard-ID wirkt nicht immer.
Ändere deinen Job auf CCSID(273).

Die Ursache liegt in eurem Systemwert QCCSID der auf jeden Fall auf die Landessprache der AS/400 gesetzt sein sollte.

[Rincewind]

Da man sich damit aber auch Feinde in der normalen Anwendung machen kann (bei uns auch CCSID Normal auf 65535) würde ich für den Zugreifenden Job einfach die CCSID auf 273 ändern.

Damit erspart man sich andere Baustellen aufzumachen

Lg

Rince

[Fuerchau]

CCSID auf 65535 halte ich für einen konzeptionellen Fehler.
Da ich ja die 5250-Sitzungen, Drucker usw. ja nicht ohne CCSID fahren kann, sollte dies passen.
Gerade wenn mann mehrsprachig fährt und Datenaustausch betreibt (und wer macht heute noch Insellösungen) MUSS die System-CCSID auf einen korrekten Wert gestellt werden.
Je nach Hauptsprache des Systems haben auch die Systemdateien immer eine CCSID.

Ohne CCSID hat man mehr Baustellen als mit CCSID !!!!!
Dann klappts auch mit den Umlauten.