Anmelden

View Full Version : Fehlerhafte Sonderzeichenumsetzung



Seiten : [1] 2

Domeus
23-07-24, 12:29
Hallo.

Wir haben einen Datenimport der Daten aus einer XML Datei einliest.

Der Import Job läuft mittels CHGJOB CCSID(1153)

Die Datei in die die Daten geschrieben werden hat für das Feld CCSID(1208)

Nun haben wir folgenden Datenstring: "?íáŠ????óž ??ú?ýé???àä??ü?"

EDIT: Interessant. Selbst das Forum scheint diese Zeichen nicht umsetzen zu können. Beim kopieren der Zeichen in den Text hat es noch normal ausgesehen. NAch dem erstellen des Threads nicht mehr. So sieht es eigentlich aus:

678

Die drei rot markierten Zeichen werden hierbei nicht korrekt erkannt und falsch umgesetzt. Mir wurde aber gesagt es sollen angeblich alles UTF-8 kompatible Zeichen sein.

Das erste ist wohl zum Beispiel "LATIN SMALL LETTER G WITH BREVE"

Ich weiss jetzt leider nicht warum diese drei nicht umgesetzt werden, und woran es liegen kann.

Weiss hier zufällig jemand was ich noch versuchen kann?

Gruß
Sebastian

mk
23-07-24, 13:11
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
23-07-24, 14:50
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
23-07-24, 14:51
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
24-07-24, 08:00
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
24-07-24, 08:36
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?topic=dlhviiratus-lob-file-reference-variables-in-ile-rpg-applications-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

(https://www.ibm.com/docs/en/i/7.5?topic=is-ifs-read-ifs-read-binary-ifs-read-utf8-table-functions)

Domeus
24-07-24, 15:29
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
25-07-24, 08:34
Also das Auslesen mit dem IFS_READ_UTF8 hat perfekt funktioniert.

Vielen Dank nochmal!

Fuerchau
25-07-24, 08:58
Na also, geht doch;-)!

Domeus
02-08-24, 11:03
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