Kroatischer Zeichensatz auf IBM i über Google Maps API Webservice

[Fuerchau]

Hier hilft nur tatsächlich UCS-2 (CCSID 13488 in der DB, Feldtyp C), ansonsten erhältst du halt Schrott in den Daten.

[Rainer Ross]

Herzlichen Dank, ich probiere es aus. Muss ich im RPG-Header hier auch noch UCS-2 einfügen oder reicht es aus, die CCSID 13488 im Datenbankfeld zu definieren?

[Fuerchau]

Ich weiß nicht, wie XML-INTO Zielfelder (DS) auswertet, sollte aber funktionieren, wenn deine DS-Felder mit "C" (UCS2) definiert sind.

[Rainer Ross]

Hallo Fuerchau,

ich habe deinen Tipp wie folgt umgesetzt. Es geht um die Darstellung der Stadt Baška.

1. Eine Datei erstellt mit dem Feldtyp "G" und CCSID 13488

CITY 40G TEXT('CITY')
CCSID(13488)

2. Im Programm ein Feld mit 40C definiert, in das die Daten mit xml-into geparst werden

D long_name 40c

3. Das Ergebnis in der Datei sieht so aus. Die Unterstriche sind nicht darstellbare Zeichen. Ich habe sie nur eingefügt, da die Zeichen sonst verschoben sind.

*...+....1....+....2
_â_ /__ ,_ /
04060106060202020202
02010A0B010000000000

Hex 0042 = "B"
Hex 0061 = "a"
Hex 001A = ?
Hex 006B = "k"
Hex 0061 = "a"
Hex 0020 = Blank

lt. UTF-8 Zeichensatz müsste "š" Hex C5A1 sein, aber in der Datei steht Hex 001A. Hast du noch eine Idee?

Herzlichen Dank
Rainer

[Fuerchau]

X'1A' ist ein Ersatzzeichen bei der Codewandlung von UTF-8 nach SBCS (z.B. 273).
Dies zeigt, dass XML-INTO intern ein normales Zeichenfeld verwendet und das Ergebnis dann nach UCS2 konvertiert. Daher halt auch der Zeichenverlust.

Beachte, ob die IFS-Datei wirklich CCSID 1208 hat, wenn nicht, wird die IFS-Datei erst noch von der Datei-CCSID in die gewünschte CCSID umkopiert, was wiederum zu Verlusten führen kann (Siehe Handbuch).

Um UCS2 zu erhalten muss in der Option des XML-INTO CCSID=UCS2 angegeben werden da sonst immer erst in die Job-CCSID gewandelt wird (siehe Handbuch)!

[Rainer Ross]

Hallo Fuerchau,

wahrscheinlich sind wir nur noch einen Mausklick von der Lösung entfernt.

- Die CCSID der IFS-Datei habe ich geprüft, sie ist 1208

anbei der Inhalt als Hexcode: š ist korrekt als x'C5A1' in der Datei dargestellt

20203C61 64647265 73735F63 6F6D706F 6E656E74 <address_component
2020203C 6C6F6E67 5F6E616D 653E4261 C5A16B61 <long_name>Ba ka<
2020203C 73686F72 745F6E61 6D653E42 61C5A16B <short_name>Ba ka
2020203C 74797065 3E6C6F63 616C6974 793C2F74 <type>locality</t
2020203C 74797065 3E706F6C 69746963 616C3C2F <type>political</

- der XML-into enthält folgende Optionen:

d#opt = 'doc=file +
ccsid=ucs2 +
path=geocoderesponse +
countprefix=cnt_ +
case=any allowextra=yes +
allowmissing=yes'; // XML-Options

xml-into rsp %xml(%trim(d#stmf):%trim(d#opt));

Somit sollte alles korrekt sein, aber in der Datei erscheint trotzdem noch x'1A', irgendwo geht da etwas verloren.

Herzlichen Dank Fuerchau

Herzliche Grüße
Rainer Ross
www.myhofi.com
schnelle und komfortable Hotelsuchmaschine mit Volltextsuche – powered by IBM i

[B.Hauser]

Nur so eine Frage:
Das Text-Feld in der Datenstruktur rsp ist mit Datentyp C oder Datentyp A definiert?

[Rainer Ross]

Hallo Birgitta,

das Text-Feld ist wie folgt definiert:

dcl-ds address_component qualified;
type char(30) dim(2);
long_name ucs2(60);
short_name ucs2(60);
end-ds;

[Rainer Ross]

Herzlichen Dank,

das Problem ist gelöst, ich hatte noch ein Zwischenfeld im Programm, das als Char definiert war und nicht als UCS2-Feld.

Anbei das Programmlisting im neuen all-free RPG

Herzliche Grüße
Rainer Ross
www.myhofi.com
schnelle und komfortable Hotelsuchmaschine mit Volltextsuche – powered by IBM i