Base64 encode zum zweiten

[Fuerchau]

Leider ist das Feld "DSNAME_DATA" mit der konstanten Länge fix definiert. Das Problem aber ist, dass der SQL nur die Länge schreibt, für die Daten vorhanden sind.
Wenn du also erst 1000 Zeichen liest und dann 500, enthält das Feld immer noch die 500 Rest vom vorherigen Read. Einfach ein %SUBST() liefert dir ein VARCHAR wieder zurück.

Du kannst allerdings eine DS mit Overlay auf den CLOB definieren, die dann einen VARCHAR/VARUCS2 mit 4-Bytel Länge und der korrekten CCSID (1200/1141) beinhalten.

Wie oben schon beschrieben, kannst du aber mit dem IFS_READ in 2K-Blöcken, dem BASE64 und einem LIST_AGG drumrum auch längere Inhalte zusammen basteln.
Dann hast du nur 1 Aufruf, egal wie lang das Ergebnis dann ist (wegen der Beschränkung).

Wie kommen die auf eine url-Länge über 2K? Das maximum ist doch auf 2K festgelegt.
Mehr geht nur via HTML-Dokument (HEAD/BODY) mit z.B. JSON/XML-Daten.

[camouflage]

Baldur,
Genau so hab ich es gemacht, einen %subst auf den clob.Die Konfusion geht halt auf eine API Beschreibung zurück die zum Heulen ist. bin der Lösung mittlerweile ziemlich nahe. Und URL Parameter brauche ich dazu auch nicht, das geht über den request.

[Fuerchau]

Bedenke auch, dass die Eingangsdaten entweder wirklich binär oder in 1208 sein müssen und Ausgangsdaten in 1208 kodiert sind. Da BASE64 sich auf den unteren Codeteil von ASCII/ANSI beschränkt erhält man auch reinen ASCII-Code.
1200 (UTF16) bringt da dann garnichts.

[camouflage]

Danke Baldur,
Vielleicht hast Du eine Idee, warum ich den String nicht durchbringe. Erhalte diese Meldung:
One or more validation errors occurred.","status":400
0x16' is invalid within a JSON string. The string should be correctly escaped.


Den Request bereite ich so auf:
dcl-s base64String sqltype(clob:1572864) CCSID(1208);
request = %scanrpl('%%data%%' : %trim(%subst(base64String:5:32500)) : request);

Mach das zum ersten Mal so, sonst immer nur mit Scott's Http Api.

[Fuerchau]

0x16 = hex: 16 ist ein Zeichen kleiner Blanks und im JSON nicht erlaubt. Das hat nichts mit dem BASE64 zu tun, denn da kann x'16' nicht vorkommen.
Da musst du mal beim Debugger den Inhalt mit Hex ansehen, wo der herkommt.
Andererseits könnte der Inhalt deines BASE64 bereits dein JSON sein und der Expand passt da nicht zu.

Und wenn du das Compile-Listing für deine CLOB ansiehst, so hast du da da eine
base64String_Length 10I sowie ein base64String_Data verfügbar (wie Birgitta schon sagte).
Somit kannst du direkt mir %subst(base64String_Data:1:base64String_Length) arbeiten und sparst den %trim.

Du lässt dir da nicht in die Karten gucken;-).

[Fuerchau]

Hast du das falsche Zeichen nun gefunden? Das würde mich zumindest mal interessieren.

[B.Hauser]

Dir ist aber schon klar, dass in UTF-8 ein Zeichen 1, 2, 3 oder 4 Byte lang sein kann?
Die RPG Built-In-Funktionen (z.B. %SUBST oder %SCAN ...) arbeiten per Default auf Byte-Ebene.
Ein %SUBSTR() könnte somit mitten in ein Zeichen platzen und dieses halbieren.

Wie man diese Probleme in RPG umgehen kann, werden hier beschrieben:
CHARCOUNT-NATURAL mode

[Fuerchau]

Und dir sollte klar sein, dass In Base64 dieses Problem gar nicht erst auftritt, da alle Zeichen <= x'7F' sind!
Und %subst arbeitet in Abhängigkeit der CCSID auf Byte oder Zeichenebene.
Sonst würde das mit CCSID 1200 (2/4-Bytesatz) gar nicht klappen.

[Fuerchau]

Der Fehler ist wahrscheinlich, dass base64String für RPG eine DS vom Typ Char ist.
Das der SQLTYPE sich ja in _Lenght und _Data teilt, ist nur der _Data-Teil mit einer CSSID versehen und nicht die DS. Somit berücksicht der %SUBST nicht die CCSID bei der Übertragung.
Du musst das _Data Feld verwenden und kannst die Länge auf _Lenght beschränken.
Wenn nun deine Variable Request nicht auf CCSID 1208 steht, erfolgt auch keine Codewandlung in die Job-CCSID. Bei der Übertrag von 1208 in Char ohne CCSID erfolgt automatisch eine Codewandlung.

Hast du dir die Daten mal binär via Debugger angesehen?

[camouflage]

So habe ich es definiert und bekomme es trotzdem nicht gebacken. Request und Job alles UTF8.

         dcl-s base64String   sqltype(clob:1572864); 
         exec sql
           select base64_encode(
           cast(T.DATA as blob)
           )
           into :base64String
           from table (
           QSYS2.IFS_READ_BINARY(:ifsFilePath)
           ) 
           as T(PATH, DATA);

SQLSTATE = 000000 SQLERR = 7964, keine Response

ok, der CAST müsste vllt nicht sein.

[Fuerchau]

Schau dir bitte die SQL-Auflösung genau an.
Mit welcher CCSID werden die Felder definiert.
Besser ist:
dcl-s base64String sqltype(clob:1572864) ccsid(1208);

Ist denn deine Datei kürzer als 2732? Ist die Beschränkung auf 2732 aufgehoben?