#XPRIM_Binary Base64 encoding/decoding

[Speedlime]

Morning All

The code below takes a block of base64 data ( PDF document) and converts it to native PDF and stick it in to a CLOB.

My question is, will you get different decoding result when running this code on the server in a function ( iSeries ) as opposed to running in the client (Windows) in a reusable . ??? My assumption the PDF was encode to base64 on a windows server before being sent in the JSON


DEFINE_COM Class(#XPRIM_Binary) Name(#HashBytes)

* base64 block of data from Json
#MyBase64String := #Reader.ReadStringWithName( 'manifest' ).AsNativeString
* Decode Base64 string
#HashBytes.FromBase64String String(#MyBase64String) Errorinfo(#ErrorInfo)
#STD_CLOB := #HashBytes.AsFile

[KEC]

Data is Unicode, so should be identical between Windows and IBMi.

One other thing is you might want to investigate using some of the newer primitives for JSON

Define_Com Class(#prim_ioc.FileStream) Name(#uoFileStreamWriter)
Set Com(#uoFileStreamWriter) Fileaccess(Write) Filemode(CreateNew) Path(#ufOutputFile)
#uoFileStreamWriter.WriteBase64String Base64string(#uoMessage.Item<'contentBytes'>.AsString)

[Speedlime]

KEC

Thanks for the reply, if the data is equal on either platform that is one question answered, I need to look further down the line in my code.
I will take a look at these new primitives, the problem might be when I write the blob to the IFS.

Regards
LK

[Tim McEntee]

Hi LK

In your posts you talk about both CLOBs and BLOBs. My gut feel (without knowing) is that a PDF should be treated as a BLOB not a CLOB. If you transfer it as binary data in a BLOB it might fix your problem. CLOBs are purely character based, and if there is anything that the PDF is relying on that is not a character that part will be lost in translation.

Tim

[Speedlime]

Hi Tim,
Yes you are correct, must be a blob. I think at the time of writing I was trying both to see if there was a difference.