[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: getting back and printing a base64 encoded Zebra label...

Hi Charles,
The point behind base64 is to translate arbitrary binary data into a format that can be safely sent over a plain-text protocol.
Before we had this type of encoding, text protocols were notorious for changing the value of binary data during transmission. This includes translating it between character sets (and thus changing the underlying binary value), stripping control characters, or treating control characters as "special values" unless they were specially escaped, or inserting line feeds at inappropriate places.
Base64 takes a stream of bytes (it can be any bytes with any binary values) and converts it to a set of invariant text characters that can be safely sent over a text-based transport protocol. Once the data has been encoded in base64, you can do pretty much anything to it that you'd do to human-readable text without changing it's meaning.
When it finishes it's trip over the network, and is received on the opposite end, it can be decoded, and once decoded the bytes will have the exact same binary values that you started with.
The base64 encoder that I wrote expects that the *encoded* data should be a set of EBCDIC text values. But you can translate them to/from ASCII or Unicode without changing the underlying data. When received, the decoder can decode it and the result will be the original binary values.
My decoder, likewise, assumes that after all text manipulation has been done, the resulting *encoded* data will be in EBCDIC. (After all, it's an RPG program.) But, once decoded, it will have the exact same binary value you started with. 

Does that help?
I gave this long-winded explanation rather than answering your specific questions, because I didn't really understand your questions :-) 



On 4/27/2012 8:50 AM, Charles Wilt wrote:

All,

I'm helping another developer with a project that using HTTPAPI to
send a request to a transportation management company.  The response
back is supposed to include a encoded printer stream for a Zebra label
printer...

The data element of the response starts out
<data>PExvZ3M+PExvZyAgdGltZXN0YW1wPSIwNC

Assuming the data was base64 encoded, I copied and pasted it into an
online converter and got back...
<Logs><Log  timestamp="04/25/2012 13:45:03"><Owner></Owner>
<UserId></UserId>
<Process><  ½Aɽ?•ÍÌø(ñ Ù•¹Ðù1=ð½ Ù•¹Ðø(ñ?Ñ¥½¸ù

So it appears that my assumption was correct about the base64...but we
weren't expecting more XML...nor what appears to be binary data...I
was expecting text based ZPL.

Waiting to hear back from the TM company....

In the meantime, I'm trying to wrap my head around the the
implications of ASCII, EBCDIC, binary and possibly UTF :)

Scott mentions his BASE64 expects EBCDIC...
http://www.scottklement.com/archives/ftpapi/201007/msg00020.html

But that the base64 routines in the Apache Portable Runtime in the OS
if using the encode text routine, automatically translate from EBCDIC
to ASCII...
http://www.iprodeveloper.com/article/application-development/base64-is-built-in-to-ibm-i-63967

The HTTP protocol uses ASCII (or UTF I guess)
But the XML data returned to my procedure by http_url_post_xml has
been translated into EBCDIC, right?
I assume the base64 data was encoded from ASCII, but given the above
the encoded data would have been translated by HTTPAPI into EBCDIC..

Do I need to translate it back to ASCII before decoding it?

Or does it matter given that the invariant character set is used by
base64 encoding right?

Assuming the decoded data contains a binary data stream, can I just
store it in an RPG variable coded with CCSID(65535)?
Or if it's an ASCII stream, store it with CCSDI(???) (need to look that up :).

What's the best way to get it to a Zebra printer...
I was expecting to be able to use a PRTF defined as *USERASCII.... but
if it's binary data would that still work?


Thanks!
Charles



-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------



-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------