RE: Base64 decode

Scott,

Thanks for the reply. For whatever reason I struggle with the whole encoding thing.
I guess I (incorrectly) assumed the base64 encoded element was UTF-8 because the XML document was UTF-8?

I took your (original) advice and removed the CCSID from my RPG variable that receives the base64_decode.
Then I changed my open() API to use CCSID = 0

fd = open(Stmf:flag:mode:0:0);
rc = write(fd: %addr(base64decoded): %len(%trim(base64decoded)));

The CCSID of the IFS file is 37. I can view it using Notepad++ and WRKLNK (although this does indicate: Message . . . . : File CCSID not valid.
Cause . . . . . : The file Coded Character Set Identifier (CCSID) was 00037,
but the data in the file looks like ASCII. A CCSID of 00819 is being used.
Recovery . . . : If another CCSID is needed, use F15 to change to the
desired CCSID. )

The ultimate goal is to send the decoded string of ZPLIii data to a label printer. And that seems to work. I'm just hoping it does in all cases.

I'm not sure how would I "know" what encoding the string is once I have decoded it using base64_decode()?
Would this be indicated in the WSDL for the SOAP web service?
The XML response indicates <?xml version="1.0" encoding="utf-8"?>

Thx,
Greg


-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Tuesday, August 11, 2020 11:19 AM
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Subject: Re: Base64 decode

Hi Greg,

What encoding was the label before it was originally base64 encoding?  
You seem to be hardcoding UTF-8, but... if it's not UTF-8, you'll get an
error as soon as you get a byte sequence that isn't valid for UTF-8.

You say stuff like "preferably in a common format like UTF8"... but...
this isn't something you can control!   The data that's sent to you is
already encoded a particular way.   The bytes already are what they
are.  You can't choose for them to be UTF-8 if they're not.

You need to know what they are so you know how to interpret them properly.

-SK


On 8/10/2020 3:54 PM, Greg Wilburn wrote:

While my original logic worked fine with the TEST web service, the real world implementation failed after successfully working for 20+ transactions.

To summarize... I am consuming a SOAP web service (with HTTPAPI's http_post_xml) that returns an XML element containing BASE 64 encoded ZPLII (Zebra printer) data.
I need to:
1. Decode the data
2. Write the decoded data to the IFS as a text file (preferably in a common format like UTF8)
3. Send that text file directly to the Zebra Printer (I'm using Scott's PRTSTMF utility for that)

Message . . . . : An error occurred during conversion from CCSID(1208) to
CCSID(937).

My code looks like this (currently in my "EndOfElement" callback for http_post_xml):

dcl-s base64encoded varchar(65535) inz;
dcl-s base64decodedUTF char(65535) ccsid(*utf8) inz;
// dcl-s base64decodedUTF char(65535) inz;
dcl-s len uns(10) inz;

when name = 'Base64LabelImage';
base64Encoded = value;
len = base64_decode( %addr(base64Encoded:*data)
: %len(%trim(base64Encoded))
: %addr(base64DecodedUTF)
: %size(base64DecodedUTF)
);
GetLabelResponse.label(lbl) = %subst(base64DecodedUTF:1:len); // this is where I receive the CCSID error above.


In debug, I can take the values of "value" and/or base64Encoded variables and paste them into an online decoder - it works fine. Even with the data that produced the error above.

But the decoding is what is failing (not the write to IFS). If the variable "base64decodedUTF" is set to CCSID(*UTF8), it worked most of the time (until I received the error above).
If I define "base64decodedUTF" WITHOUT the CCSID(*UTF8), the length is much larger and I cannot "see" the data value in debug (or write it to the IFS).

I'm doing something wrong... but what??

Greg


-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Monday, July 20, 2020 5:12 PM
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Subject: Re: Base64 decode

Greg,

If you need to use a CCSID(1208) field to write to the IFS, then you are
using the IFS APIs incorrectly.

Since you know your data is in CCSID 1208, tell the open API that the
data is CCSID 1208 and that it should not perform translation for you.
This will cause the file to be created successfully.  It does not matter
what the CCSID of your RPG field is in that case.

-SK

On 7/20/2020 4:00 PM, Greg Wilburn wrote:

Scott,

Thanks... it definitely was encoded. I copied the 40K string and placed it into an online decoder.
Decoded, it represents ZPL (Zebra Printer Language) for a label.

Once I changed the CCSID of the field DECODED to 1208 (to match the incoming data), I was able to write it out to an IFS file.
Before doing so (assuming the DECODED field was 37) the IFS file was illegible.

It must be something with RDi and displaying the resulting field... I know RDi gets unstable when trying to view large character variables while in debug. That is what prompted me to write out the result to a stream file. In this case, it may be useful to keep it (to reprint a USPS label w/out having to call the web service again).