PDA

View Full Version : Base64 encode zum zweiten



Seiten : 1 2 [3]

camouflage
03-07-25, 08:25
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
06-07-25, 06:32
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
06-07-25, 11:23
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
06-07-25, 17:58
Überträgt man heutzutage große Dateien wirklich als Base64?

Fuerchau
07-07-25, 08:17
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.

Andreas_Prouza
08-07-25, 09:05
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;-)

Oder anders Formuliert: Warum einfach wenn's auch komplizierter geht :-)

camouflage
08-07-25, 09:16
Sag mal Baldur, Du bist dir da wirklich sicher, dass man noch die 2K Limite beachten muss und nicht direkt in einen 16MB String lesen kann?

Fuerchau
08-07-25, 13:49
Falsch verstanden:
Das Base64-API kann nur maximal die ca. 2K. Allerdings kann List_Agg wiederum ohne Trennzeichen einen langen String bis 16 MB variable oder 2GB Lob-Locator füllen.
Ebenso wäre per IFS-Write auch eine direkte Ausgabe als Stream möglich.
Im Gegensatz zur Komprimierung ist jeder 2K-Block (Genauer 2046 ist durch 3 teilbar) unabhängig.
Die 2732 sind ja auch nicht glatt durch 3 teilbar, sondern durch 4 was einer Inputlänge von 2049 entspricht.

camouflage
08-07-25, 14:07
-----------gelöscht---------