Base64 encode zum zweiten

[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?

[camouflage]

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]

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;-).

[camouflage]

Hab's zu meiner Neugier auch noch mit dem HTTPApi von Scott Klement entwickelt. Zwei Herzen in meiner Brust: SQL zukunftssicherer, da IBM als Provider - HTTPApi viel einfacher und übersichtlicher, allerdings von Dritthersteller. Und da kann man mir von OS noch so viel erzählen oder sonst was. Ich sag nur noch eines: Synon lässt grüssen! Und ich kenn noch andere Hersteller die grossmundig den Himmel versprochen haben.

[Andreas_Prouza]

Meistens brauch ich Base64 wenn ich das ganze an ein HTTP-API übertragen will.
Klar geht das recht simple via SQL, jedoch verwende ich auch hierfür ein eigenes Service, dass mir das übernimmt, inkl. Fehlerhandling, Protokollierung und !Wiederanlauf! falls das Service nicht erreichbar sein sollte.
Da ich das in Python auf der i mache, würde ich dort auch das Kodieren ins Base64 übernehmen.
Wie Baldur schon sagte, gibt es bei SQL ein Limit. (Ich verstehe ja nicht, warum IBM hier nicht einfach CLOB als Parameter genommen hat.)
Gerade beim Umgang mit Files weiß man nie wie sich diese mit der Größe in den nächsten Jahren entwickeln werden.
Wenn das ganze nur für kurze Zeit halten soll, dann reicht es aber aus.

[Fuerchau]

Wie oben bereits beschrieben, lässt sich eben Base64 in simplen 2K-Blöcken aneineinander reihen, was mit LIST_AGG( BINARY_READ 2K ) durchaus realisierbar ist.
Das Ergebnis ist dann eben ein CLOB 1208, das 2GB groß werden kann über LOB-Locator oder 16MB für RPGLE-Variable.
Warum sollte man also weitere Produkte bemühen, außer wenn es Spaß macht;-)

[Pikachu]

Überträgt man heutzutage große Dateien wirklich als Base64?