|
-- [ Picked text/plain from multipart/alternative ] Hi all, i'm the original poster of the ebcdic mime support, i'm happy to say the problem was solved for me (i needed this in order to encode mime message, embed in xml and send via mq series). First and most important step - i downloaded this version of the decoder (http://www.fourmilab.ch/webtools/base64/) thanks to a response in this group. This version supports EBCDIC by using a form of a table with the characters to use. Now all i had to do is play a little with the ccsid of the files i opened and i was able to recieved encoded message in ccsid 819 to ebcdic file and encode as400 phisical file to 819 file. Thank you all for your kind support. Jim Langston <jlangston@celsinc.com> wrote: 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. _______________________________________________ This is the MI Programming on the AS400 / iSeries (MI400) mailing list To post a message email: MI400@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/mi400 or email: MI400-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/mi400. Shahar mor consultant --------------------------------- Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards®
As an Amazon Associate we earn from qualifying purchases.
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.