PDA

View Full Version : Base64 encode zum zweiten



Seiten : 1 [2] 3

camouflage
24-06-25, 09:38
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
24-06-25, 12:25
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
25-06-25, 09:08
Hast du das falsche Zeichen nun gefunden? Das würde mich zumindest mal interessieren.

B.Hauser
25-06-25, 16:13
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 (https://www.ibm.com/support/pages/node/6827067)

Fuerchau
25-06-25, 21:03
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
26-06-25, 09:16
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
26-06-25, 16:19
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
26-06-25, 16:36
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?

camouflage
27-06-25, 07:55
Hat sich alles erledigt, danke für die Zeit.
Ich werde den request mit den base64 Daten mit einem CLOB und einem Pointer +4 übergeben.
Danke auch an den Provider, der die response Blank zurückgeschickt hat und mich im Unklaren gelassen hat. Ein herkömmlicher Post mit SQL gibt halt nicht die Infos zurück, welches das HTTPAPI von Scott Klement mit eingebaut hat. Da hätte ich mir viel Zeit und Frust ersparen können. Ok, ich hätte einen Verbose machen können. Doch ist der Web-Verkehr mit SQL einfach mühseliger. Wenn's funktioniert, top.

Fuerchau
27-06-25, 09:03
Dass ein Provider keine aussagefähige Fehlermeldung gibt ist doch eigentlich klar.
Sonst könnte man anhand er Hinweise ebeno so lange probieren bis es klappt.
Und das tun nun auch Menschen, die kein freundliches Ansinnen haben.
Und warscheinlich war dein %SUBST auf ein CHAR ohne CCSID zuständig, so dass eine Codewandlung von Job-CCSID in UTF8 erfolgte, obwohl der Inhalt bereits UTF8 war.
Aber du hast dich ja erfolgreich gegen die Verwendung des _Data-Feldes gewehrt.
Mit dem Pointer umgehst du dann das Problem;-).