RE: [MI400] base64 encoder/decoder for EBCDIC systems

[Jim Langston <jlangston@xxxxxxxxxxx>]

True, and although I don't know Base64 encoding, what I am assuming is
happening is that any character that is NOT displayable by an ASCII
character is encoded by it's byte value.

I would be interested to know two things to get this to work on EBCDIC.

1. What would happen if you encoded EVERY byte value, Text displayable or
not?  Would it still decode properly?
2. How difficult would it be to determine the range of EBCDIC values that
are Text displayable?  I know they are scattered, and the IF statement could
get quite complex, but it should be very doable.

The assumption being, however that what you are encoding in EBCDIC Base64
will be decoded into EBCDIC.  Trying to decode into ASCII would give you
garbage.  The whole purpose of Base64 encoding, if I remember my history
correctly, was for ANY type of data that any machine could make to be
represented by ASCII characters and hence moved from various different
platforms without loosing data.

The Base64 encoding we are taking samples from here is the ASCII
implementation of it.  Encode ASCII/Decode ASCII.  It will obviously have to
be changed for the EBCDIC character set.

Then consider what will happen when this code was written and someone looks
at it and tries to implement it on some other character set like ASCII.

"It is typical AS/400-weenie, EBCDIC-specific, RPG code written by people
with no idea that anything else
exists (or being gracious, it may have been optimized for an EBCDIC
environment by someone who did consider the ramifications but somehow I
doubt it)."

Regards,

Jim Langston

-----Original Message-----
From: Simon Coulter [mailto:shc@flybynight.com.au]

Hello Jim,

You wrote:
>return(((cc >= 33) && (cc <= 60)) || ((cc >= 62) && (cc <= 126))) AND ...
>Basically, that is looking for any "standard" type character.  ASCII

I think that was the original appenders point.  That this code is full of
ASCII specific assumptions.  So it won't work on an EBCDIC machine where
the character representation is different.  It is typical Unix-weenie,
ASCII-specific, C code written by people with no idea that anything else
exists (or being gracious, it may have been optimized for an ASCII
environment by someone who did consider the ramifications but somehow I
doubt it).

The above code returns TRUE if the character is a 'displayable character'
(i.e., printable) in ASCII.  It ain't going to work on an EBCDIC machine
where the 'displayable characters' are scattered throughout a 256
character range and where most of the useful characters are above 127.
Nor does it account for the gaps that appear between groups of alphabetic
characters in EBCDIC -- which are there for a reason.  Nor does it
consider different codepages and character sets where characters like #
and $ may have different representations.

Regards,
Simon Coulter.