× 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.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.