IBM REST Web Service mit VarUCS2

[Malte]

Hallo Zusammen,

ich bin aktuell dabei ein RPGLE als REST Web Service bereit zustellen.

Mein RPG hat 2 Parameter

       Dcl-Pi *N;          
          iXml   VarChar(999999);
          output VarChar(9999999);
       End-Pi;

Ich bekomme ein XML rein und gebe ein XML zurück.

Wenn ich nun aber die Parameter auf VarUCS2 ändere bekomme ich immer nur die ersten 512 Stellen der Output Variable zurück.

Geht das einfach nicht oder muss ich da etwas anders machen?

Maschine
V7R4
TR 5

MfG
Malte

[Fuerchau]

UCS2 wird für WEB-API's nicht unterstützt, da XML's nur Textcodierungen wie z.B. UTF8 enthalten. Stichwort XML-Encoding im XML-Header (Processinginstructions).
Du kannst also nur Daten mit Codepage 1208 (UTF8) von einem Webserver bekommen, da UCS2 ein 2-Byte-Zeichensatz ist, und somit X'00nn'-Zeichen enthält, die im XML nicht unterstützt werden.

[Malte]

Danke für die Schnelle Antwort.
So ein bisschen scheint es ja noch zu Funktionieren da ja die ersten Zeichen erfolgreich übertragen werden

Aber wenn ich den Web Service mit CCSID(*UTF8) an den Parametern definiere sollte es ja ohne Probleme funktionieren ?

Mein Problem sind nämlich Sonderzeichen in einem Kommentarfeld welche mir dann beim auslesen der XML Probleme bereitet.

[Fuerchau]

Probiers doch einfach mal aus.
Über SQL kann man dann UTF8 (CCSID 1208) in UTF16 (1200), nahezu UCS2, übersetzen.
Im ILEPG ist das dann Feldtyp ucs2(1200).

[prsbrc]

Mittels iConv() sollte die Konvertierung zwischen der großen weiten Welt und der IBMi ja auch klappen. Hast das schon probiert? Also UTF8(1208) auf LOCAL(0) und beim senden wieder retour.

[Fuerchau]

iConv ist zu kompliziert, da dies mit SQL ebenso geht:

exec sql
set : Ziel = cast ( cast ( Cast(: Quelle as varchar(nn) ccsid 65535) as varchar(nn) ccsid 1208) as nvarchar(nn) );

Ggf. klappt es auch schon in ILERPG:

dcl-s Quelle varchar(100) ccsid(1208);
dcl-s Ziel varucs2(1200);

eval Ziel = Quelle; // UTF8 => UCS2
eval Quelle = Ziel; // UCS2 => UTF8

[B.Hauser]

Baldur
hast Du schon einmal versucht einen String mit CCSID 65535 mit CAST nach UTF-8 zu konvertieren?
Das funktioniert nicht!
Du musst den String zunächst in eine gültige single byte CCSID (z.B. 273 oder 1141) konvertieren.
Dieser String kann jedoch problemlos nach UTF-8 oder auch direkt nach UTF-16 (ohne den Zwischenschritt über UTF-8) oder UCS2 konvertiert werden.

Hat ein String eine gültige CCSID wird die Konvertierung von SQL z.T. sogar automatisch vorgenommen, z.B. wenn ein String mit CCSID 1141 mit einem String in UTF-8 verknüpft wird, dann ist ein expliziter CAST nicht erforderlich.

Das ist allerdings nichts neues, das ging vielleicht nicht schon immer, aber zumindest solange ich denken kann, so.

Birgitta

[dschroeder]

...
So ein bisschen scheint es ja noch zu Funktionieren da ja die ersten Zeichen erfolgreich übertragen werden

Aber wenn ich den Web Service mit CCSID(*UTF8) an den Parametern definiere sollte es ja ohne Probleme funktionieren ?

Mein Problem sind nämlich Sonderzeichen in einem Kommentarfeld welche mir dann beim auslesen der XML Probleme bereitet.

Ich weiß nicht, ob das Problem schon gelöst ist. Aber ich habe bei uns gerade mal nachgeschaut. Unsere Webservice-Programme geben immer UTF8 zurück, also z.B. varchar(800000) ccsid(*UTF8);

Intern verarbeiten wir die Daten aber meistens mit UCS2, da UTF-8 im RPG relativ "unbequem" zu handeln ist. Z.B. kann der RDi-Debugger das nicht anzeigen. Mit der Konvertierung zwischen den Datentypen haben wir gar keine Probleme. In der Regel geht das implizit, also einfach durch Umspeicherung:

dcl-s text1 varchar(100) ccsid(*utf8);
dcl-s text2 varucs2(100) ;

text1 = text2;
// funktioniert genauso, wie:
text2 = text1;

Eine explizite Konvertierung mit iconv oder anderen Verfahren brauchen wir normalerweise nicht.

[Fuerchau]

Wobei 1208/*UTF8 in älteren Releasen noch nicht unterstützt wurde, teilweise auch nicht von SQL.
Daher wohl die Alternative per iConv (C-API) oder QSH.

@Birgitta:
Dann bist do wohl erst mit V5R4 eingestiegen;-). Bis dahing ging nämlich vieles noch nicht.

[B.Hauser]

@Birgitta:
Dann bist do wohl erst mit V5R4 eingestiegen;-). Bis dahing ging nämlich vieles noch nicht.

Ach ja, dann versuch doch mal die folgende Abfrage auszuführen:

Values(Cast(Cast('Dies ist ein Test' as VarChar(25) CCSID 65535) as VarChar(50) CCSID 1208));

Aktuelles Release aktueller PTF-Stand aktuelle Software

Gleiches Ergebnis i.Ü. in STRSQL

[Fuerchau]

Entschuldigung, ich meinte damit nicht das Thema UTF8;-) sondern deine Aussage:
"Das ist allerdings nichts neues, das ging vielleicht nicht schon immer, aber zumindest solange ich denken kann, so."