Fehlerhafte Sonderzeichenumsetzung

[mk]

Hallo

wenn die XML Datei im IFS liegt, welche CCSID hat denn die XML Datei ?

Sind in der XML Datei UTF-8 Daten, dann sollte die mit CCSID 1208 definiert sein.

Wie werden die Daten eingelesen ? SQL ?
Gruß
Michael

[Domeus]

Hallo Michael,
danke für deine Antwort.
Die Datei hat im IFS eine CCSID 1252. Allerdings habe ich die Datei auch vorher selbst noch bearbeitet und gespeichert. Welche CCSID die Datei hat wenn sie übertragen wird weiss ich grad nicht. Ich habe die Datei aber mal in 1208 geändert. Es hat leider nicht gebracht. Diese 3 Zeichen sind immer noch falsch.

Eingelesen wird die Datei über cpyfrmimpf. Sowohl FROMCCSID als auch TOCCSID ist mit 1208 angegeben. Die Datei in die die Daten geschrieben werden (qtemp/XX01234.PF) hat nur ein Feld:

A DATA 512A CCSID(1208)

Gruß
Sebastian

[Fuerchau]

Fakt ist, eine Job-CCSID ist nie unicodeconform.
D.h., beim Lesen in RPG in eine normale Char-Variable werden Zeichen in Singlebyte (die JOBCCSID) gewandelt, unbekannte Zeichen bekommen dann i.d.R. ein "?".

Die Frage, wie vom Vorgänger, ist: Wie werden die Daten verarbeitet?
Ist die Zielvariable vom Typ C bzw. varucs2 (CCSID 1200)?
Dann sollte es auch keine Probleme geben, wenn die Daten dann in eine Tabelle mit 1200 (NVARCHAR) ausgegeben werden.

Auch ist es wichtig, wie die CCSID der IFS-Datei getagt ist. Per Default via Netserver wird das 1252 sein, via FTP den FTP-Attributen entsprechend.
Ggf. die Datei mit CHGATR auf CCSIS 1208 anpassen. Keine Angst, eine Umwandlung wird da nicht gemacht.

[Domeus]

Hallo Fuerchau,

die Daten werden wie oben geschrieben über den CPYFRMIMPF aus der Datei in eine PF geschrieben. Diese hat nur ein Feld, nämlich das Feld DATA 512A als CCSID=1208 definiert.

Aus dieser Datei werden nun Satz für Satz die XML Daten eingelesen und verarbeitet. Diese Daten die die Sonderzeichen beinhalten werden dann wiederum in Felder einer anderen PF (bzw. einer TABLE) geschrieben die CCSID 1200 haben.

Der CPYFRMIMPF sieht so aus:

CPYFRMIMPF FROMSTMF(&WRKF) TOFILE(QTEMP/DM0720PF) +       
           MBROPT(*REPLACE) FROMCCSID(1208) +           
           TOCCSID(1208) RCDDLM(*CRLF) STRDLM(*NONE) +  
           RMVBLANK(*NONE) FLDDLM(*TAB) +               
           RPLNULLVAL(*FLDDFT)

Gruß
Sebastian

[Fuerchau]

Daten der CCSID 1208 können erst mal per SQL (ACS) bzw. im IFS mit EDTF korrekt betrachtet werden.
Wenn die Daten da in Ordnung sind, muss die Art der Verarbeitung das Problem sein.
Macht ihr das mit RPG, ist es wichtig keine einfachen Char sondern grundsätzlich UCS2-Variablen mit CCSID 1200 zu verwenden.

Ihr könntet ja die IFS-Datei auch direkt per CPY in CCSID 1200 kopieren, warum den Umweg?
Schon länger gibts auch den Zugriff per CLOB_FILE, wenn die IFS-Datei mit der richtigen CCSID getagt ist:
https://www.ibm.com/docs/de/i/7.5?to...s-that-use-sql
Die benutze ich schon des längeren, um EDI-Dateien per ILERPG zu lesen.

Alternativ kann man IFS-Dateien auch per SQL lesen, z.B. mit IFS_READ_UTF8:
https://www.ibm.com/docs/en/i/7.5?topic=is-ifs-read-ifs-read-binary-ifs-read-utf8-table-functions

[Domeus]

Danke für die vielen Infos.

Ich werde mir das mal in Ruhe anschauen und ausprobieren.

Ich werde eine Rückinfo geben ob es funktioniert hat.

Vielen Dank nochmal

[Domeus]

Also das Auslesen mit dem IFS_READ_UTF8 hat perfekt funktioniert.

Vielen Dank nochmal!

[Fuerchau]

Na also, geht doch;-)!

[Domeus]

Hallo.

Jetzt habe ich doch nochmal eine Nachfrage:

In einem anderen Programm haben wir folgenden SQL Befehl genutzt um zu prüfen ob die Variable daten273 Sonderzeichen beinhaltet:

D datenein        S            300A   CCSID(1208)    
D daten273        S            300A   CCSID(273)     

exec sql select cast(:datenein as varchar(300) ccsid 273)   
            into :daten273                          
            from SYSIBM.SYSDUMMY1 fetch first 1 row only;      
IF sqlcode = 335;                                   
  //Sonderzeichen vorhanden
ENDIF;

Ich frage mich nun ob man diese Prüfung nicht auch durch die Umwandlung mit ifs_read_utf8 mit erledigen kann? Aber egal welche Variablen ich kombiniere weder ifs_read_utf8 noch ifs_read usw. spucken hier einen anderen sqlcode als 0 aus.

Könnte man trotzdem irgendwie auslesen, falls z.B: beim ifs_read (ohne _utf8) eine Umsetzung fehlerhaft ist oder muss ich dafür immer die andere Prüfung nehmen?

Gruß
Sebastian

[Fuerchau]

Per Definition gibt es keinen Fehler bei einer Umsetzung von UTF8 oder UTF16 (1200) in eine beliebige andere CCSID, da bei ungültigen Zeichen grundsätzlich das "?" eingesetzt wird.
Dies wurde halt so festgelegt und ist auch im Windows-Umfeld so.

Wenn man per ODBC in die DB2 übertragen will und die Tabelle eine Single-CCSID hat, 273, 1141, 870, usw., gibt es eine Einstellung im Treiber, dass keine ungültigen Zeichen zugelassen werden (Default).
Dies trifft z.B. bei CCSID 273 das "€"-Zeichen, da dort das Zeichen nicht definiert ist.
Hier muss man dazu erwähnen, dass i.d.R. in ODBC-Zugriffe mit "String" umgegangen wird und diese sind seit 1998 grundätzlich UTF16. Einzig in byteorientierten Sprachen wie C/C++ kann man noch mit Singlebyte-char-Arrays arbeiten.
Man spart sich daher das Umwandeln von Strings in byte-Arrays, außer bei der Verwendung von UTF8.
Bei der Erkennung von ungültigen Zeichen wird der Insert/Update dann abgelehnt.