UTF-8, XML, IFS CCSID und SAX

[Robi]

Hallo *all
ich habe hier u.a. ein Pgm gefunden, das all die Daten, die das Hander Pgm bekommt einfach mal in eine PRTF schreibt.

Ich habe von der Bank einen Kontoauszug im XML-CAMT format bekommen.
Dieser ließ sich nicht betrachten (Windows Internet Explorrer). Lt. Aussage der Bank liegt das ein einer Zeichenfolge die vor dem eigentlichen

< ? XML version="1.0"...

steht.
Also habe ich diese zunächt mit dem Notepad entfernt und die Datei gespeichert.
Da o.g. Pgm nur aus dem IFS liest, habe ich anschl. die Datei über ein gemapptes Laufwerk ins IFS kopiert. Im XML steht : encoding UTF-8.
Über die Attribute im WRKLNK sehe ich die Datei mit CCSID 1252. Das List-Pgm läuft solange, bis ein Dateninhalt mit einem 'Ü' auftaucht (SONSTIGE GRÜNDE).
Sehe ich mir mit dem Editor die Orginaldatei an, und suche nach "SONSTIGE GRÜNDE" finde ich nix. Die Suche nach "SONSTIGE GR" findet etwas, dahinter ein Sonderzeichen. Setze ich über WRKLNK 2, F15, 3 die CCSID von 1252 um nach 1208 (= UTF-8 oder?) bricht das Pgm gleich am Anfang ab. Auch wenn ich den 'unbearbeiteten' CAMT-Kontoauszug einlesen will bricht das Pgm ab.

Nachrichten-ID . . . . :   RNQ0351       Bewertung  . . . . . . :   99      
Nachrichtenart . . . . :   Anfrage                                          
Sendedatum . . . . . . :   25.04.14      Sendezeit  . . . . . . :   10:17:03
                                                                            
Nachricht . . . :   Ein XML-Parsing-Fehler wurde festgestellt (C G D F).    
Ursache  . . . . : Die XML-Operation ist fehlgeschlagen, da der XML-Parser  
  einen Fehler in dem XML-Dokument für die RPG-Prozedur RD_XML2 in Programm 
  T999999/RD_XML2 bei Anweisung 011100 festgestellt hat.

So, viel Text, ...
Sind eure Kontoauszüge auch NICHT mit dem IE anzeigbar?
Wie löse ich das CCSID-Problem.

Muß ich ein PGM schreiben, das die Orginaldatei einliest und alles ab

< ? XML ...

in eine IFS-Datei ausgibt, oder gibt es da andere möglichkeiten.

Danke
Robi

[Fuerchau]

Häufig wird in den ersten beiden Stellen einer UTF-8-Datei 2 Byte vorangestellt, die die Art der Speicherung (normalerweise nur bei UCS2) kennzeichnet:
x'FFEF' = little Endian, x'EFFF' = Big Endian.
Dies resultiert aus unterschiedlichen Prozessorarchitekturen, Intel speichert Integer immer zuerst Byte 1 und dann Byte 0, alle anderen machend das "richtig rum".
Bei UTF-8 (und auch bei XML) macht das aber keinen Sinn, da es hier generell Prozessorunabhängig definiert ist.
Leider musst du da halt ein Programm schreiben, dass die 2 Bytes am Anfang (wenn sie denn nicht mit "<" anfangen) entfernt.
Beim Speichern ins IFS wird die Default-CCSID des NetServers eingestellt, unabhängig davon, welchen Inhalt die Daten tatsächlich haben.
Wenn du nun die Datei parsen möchtest, musst du das Encoding, bzw. die CCSID irgendwo vorgeben.
http://publib.boulder.ibm.com/infoce...0925086818.htm
Ggf. musst du als Zielvariable dann Typ "C" für UCS2 wählen.

Hilft alles nicht, kannst du per QSH CMD('iconv ...') die Datei umkopieren von 1208 nach 1252.

[AG1965_2]

Die Zeichenfolge am Anfang ist wahrscheinlich ein sogenannter "BOM", ein Byte Order Marker, den man bei UTF-8 eigentlich überhaupt nicht braucht, viele Leute aber trotzdem ausgeben (gut gemeint). Das ist für UTF-8 die Zeichenfolge x'EFBBBF'. Nachdem die Bank wusste, was das Problem ist, geben die das wahrscheinlich auch selber aus.
http://de.wikipedia.org/wiki/UTF-8#Byte_Order_Mark

Dieser BOM stört XML-SAX aber zum Glück nicht. Du musst es nicht entfernen. Extra ausprobiert.

Ein großes Ü ist in UTF-8 x'C39C'. Wenn das nach Deinen Änderungen noch immer so in der Datei steht, die CCSID 1208 hat, sollte das auch mit XML-SAX funktionieren. Ich habe erfolgreich eine Sanktionsdatei importiert, die nicht nur Umlaute, sondern auch arabische Namen in Originalschreibweise drin hat.

Du müsstest also nur die CCSID mit

CHGATR OBJ('/Dateiname')                                              
       ATR(*CCSID)                                           
       VALUE(1208) 

ändern.

[Robi]

Danke!
habe nun versucht die Datei direkt von dem PC-Laufwerk zu lesen, geht auch! (irgendwo in den Unterlagen steht, die Datei müsse im IFS stehen, sie muß aber anscheinend nur 'erreichbar' sein.
Also fällt das Kopieren und verändern der CCSID weg. Aber mit wrklnk betrachtet steht die Datei da trotzdem als 1252. Das, was vor dem 'eigentlichen' XML in der Datei steht ist deutlich länger als 2 Byte und beinhaltet u.a. den Dateinnamen (vermute ich mal.)
Aufbau: 30 Byte Schmierzeichen dann JJJJ-MM-TT_C53_dieIban_EUR_14_00058.XML
Mitlerweile weis ich, das die Datei NICHT von der Bank kommt sondern via SFirm ausgegeben wurde.

Der CHGATR hat leider nix gebracht, das Pgm bricht nach wie vor ab, wenn er aus 'SONSTIGE GRÜNDE' stößt.
Nein, er hat gar nicht funktioniert! (obwohl das anders gemeldet wird)

Attribute wurden für 1 Objekte geändert. 0 Objekte wurden nicht geändert.

Robi

[AG1965_2]

Das klingt seltsam.
Vielleicht hat SFirm eine gute Antwort, warum sie ungültige XML-Dateien produzieren?

Fakt ist jedenfalls, dass XML-SAX offenbar auf die CCSID Rücksicht nimmt; d.h. Du gute Chancen hast, dass Umlaute und dergleichen nicht stimmen werden.

Darum würde ich das file trotzdem ins IFS kopieren und die CCSID korrigieren.

Auch wenn dadurch die Chancen steigen, dass XML-SAX sich wegen ungültiger Zeichen aufregt. (Wenn z.B. ein "normaler", sprich ISO-8859-1, Umlaut im file auftauchen sollte. (Auch das gibt es, Leute kopieren einfach den Header inkl. UTF-8-Angabe irgendwoher und schreiben dann alles Mögliche in das file, nur nicht UTF-8.))

Wenn Du SFirm nicht kontaktieren willst oder die ihre Ausgabe nicht korrigieren wollen, brauchst Du eh ein kleines Programmerl, das die Datei einliest und alles ab < ? XML in eine neue Datei ausgibt. (So seltsam geschrieben, weil sonst die künstliche Dummheit des Forenprogramms zuschlägt und den Beitrag abbricht.)

[Fuerchau]

Das Forum ist nicht dumm, es erlaubt halt auch HTML-Tags, die auch mit "<" anfangen.
XML-Reader sollten das Encoding im XML-Header erkennen und danach handeln.
Natürlich muss die Datei reines XML enthalten. Ich scheitere auch schon mal daran (mit .NET), wenn nach dem letzte ">" am Ende der Datei noch Zeichen außer CRLF folgen.
Ist kein Encoding im Header definiert, so wird meist irgend ein Default angenommen und somit UTF8 nicht korrekt behandelt.