× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Scott,

Thanks for the vote of confidence... I'm not sure I completely understand it :). All I know is that if I don't convert it to ASCII before base64 encoding it, the web service on the other end cannot understand the payload part of the message (it accepts the message, but it doesn't decode properly for them).

On the other hand, if the web service payload doesn't require encoding (base64 or otherwise), I can simply post the data without worrying about the EBCDIC to ASCII conversion (I'm guessing that's handle under the covers)..

And thanks again for your response (You too Jon)... I knew my biggest issue was dealing with varchar fields.

Greg

-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Friday, May 17, 2019 2:42 AM
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Subject: Re: Base64 Encoding

Mihael,

Base64 has no concept of character sets, so I find your description confusing.

Anything you encode with base64 will decode to the exact same binary value.  So if you encode EBCDIC data, it will decode to the exact same data.  Where many people get this wrong is that they encode ASCII or Unicode data, then decode it and are surprised when its unreadable as EBCDIC data. (or vice-versa).  This shouldn't surprise people, though, since it will have the same binary value.   The binary values of ASCII or UNICODE will look like "garbage" if viewed as EBCDIC.

But, Greg seems to understand this already as his example is converting the data to utf-8 prior to encoding.  So ...  why are you saying this stuff?



On 5/16/19 9:38 PM, Mihael Schmidt wrote:
Base64 encoding is character set dependent. If you encode your data
with an encoder for some EBCDIC CCSID and your online encoder expects
it to be UTF8 it won't work.

The ILEastic project has a Base64 encoder for UTF8. This will
definitely work better with the online encoders. I have successfully
used it for JWT signing where you also have to Base64 encode the parts
of the JWT token.

Best regards

Mihael


On 16.05.19 23:36, Greg Wilburn wrote:
Is this the easiest way to Base64 encode and XML document (either in
an RPG variable or on the IFS) for use in a SOAP web service?

I've used Scott's BASE64R4 service program for smaller things like
API keys, etc.

I've been trying to mock-up a test scenario, and I'm not getting the
results I expected - pretty sure I'm doing something wrong with the
varchar fields.  The code I'm copying was using much smaller fixed
length fields.

xmlData and xmlData64 are both varchar(2048)... however the data is
nowhere near that large (utflen=710).

    http_setCCSIDs( 1208: 0 );
    utflen = HTTP_xlatedyn( %len(%trim(xmlData))
                          : %addr(xmlData)
                          : TO_ASCII
                          : p_xmlDataUTF );

    b64len = base64_encode( p_xmlDataUTF
                          : utflen
                          : %addr(xmlData64)
                          : %size(xmlData64) );

    dealloc p_xmlDataUTF;


My resulting data in xmlData64 does not match the online encoders.

Thanks,
Greg


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.