Base64 encode zum zweiten

[camouflage]

Ich möchte aus einem ISF XML File einen Base64 string machen und das Ganze neu mit SQL. Dazu lese ich das ISF File erstmal mit QSYS2.IFS_READ_BINARY in einen BLOB. Leider komme ich da nicht mehr weiter, da der BASE64_ENCODE mir einen leeren Wert zurück gibt.
(set base64String = base64_encode(:xmlBinary)

Ich hätte schon andere Methoden, da man ja modern sein möchte ....
Weiss jemand Rat? Danke.

[camouflage]

Hat sich erledigt! Alles gut.

Für die Neugierigen, meine Lösung:

dcl-s xmlString sqltype(blob:1000000);
dcl-s base64String sqltype(clob:1500000);
exec sql
set :base64String = (
select base64_encode(T.DATA)
from table(QSYS2.IFS_READ_BINARY(:ifsFilePath)) as T(PATH, DATA)
);

[Fuerchau]

Da kennst du die Ursache. Deine Datei ist wahrscheinlich kürzer. Umd wahrscheinlich hast du einen negativen SQL-Code bekommen.

https://www.ibm.com/docs/en/i/7.6.0?...calar-function

character-string

A character expression to be encoded. The maximum length in 2732 characters.

[camouflage]

Abgesehen davon (das hätte ich jetzt nicht gedacht), habe ich immer das http api von Scott Klement für meine Webservices verwendet. Nun finde ich die Web SQL Methoden viel praktikabler und vor allem Release sicherer. Da habe ich echt Mühe, wenn ich Drittprodukte einsetzen muss - Synon lässt grüssen.

[Fuerchau]

Vom API her ist das ja neutral zu sehen.
Base64 ist eine 3 zu 4 Methode (3-Byte = 4 Zeichen). Also kannst du das API in Blöcken zu 2700 (durch 3 teilbar) aufrufen.
Dann kannst du das Ergebnis immer noch verketten.
Leider kennt SQL noch keine "Segment"-Funktion, eine Bin/Text-Spalte in Segmente einer gegebenen Größe zu packen.
Du kannst den IFS-Read allerdings auch auf binär mit fester Größe 2700 umstellen, die Zeilen in Base64 umwandeln und das Result per List_Agg wieder zusammenbauen.

Sollte 2732 das Ergebnis sein, wäre der maximale Input 2049, da 2732 durch 4 glatt teilbar ist.

Umgedreht kann man dann auch Base64 in Blöcke zu 2732 zerlegen und erhält dann durch den Decode wieder max. 2049 Bytes, die man einem IFS_Write übergeben kann.

[camouflage]

Diese Clob Klauberei macht mich noch wahnsinnig. Frage, wie werde ich den Längenindex am Anfang wieder los. Ich lese das XML in einem Schluck mit einem QSYS2.IFS_READ_BINARY in einen clob string. Und danach wiederum einen encode wieder in einen clob string. Funktioniert ja alles ok, nur brauch ich den base64 als parameter in der url. Kommt hinzu, dass die url die 32672 übersteigen kann. Konzept kommt nicht von mir.

[B.Hauser]

Der SQL Precompiler konvertiert LOB-Variablen in eine Datenstruktur mit 2 Feldern.
1. DSNAME_LEN Uns(4) - Länge der tatsächlichen Daten
2. DSNAME_DATA Char(?) - Daten in der LOB-Variablen angegebenen Länge (?=Länge)

Eine LOB-Variable kann mit einer Länge bis zu 16MB definiert werden (dann kommt RPG an seine Grenzen).

Über gib das Unterfeld DSNAME_DATA als Parameter (CHAR).

Birgitta

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

[Pikachu]

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

[Fuerchau]

Komprimierung => Binär => BASE64
Im Mailtransfer heißt das dann Mime64 und eigebettete Dokumente werden per Mime64 übertragen.
In meinen eigenen Dokumenten (XML) bette ich häufig Base64-Daten ein.