Eric:
 
As you may recall, I've been doing a lot of work with trying to accomodate
storage and delivery of LISTSERV files with 8-bit characters. You pointed
me to the GET FN FT F=MIME option and that works great.  However, I just
discovered something very strange.
 
In some of our files, we have inserted an ASCII code 29 character in
various places. This is normally an invisible character and we use it to
trigger a specific HTML tag when the file is processed for WWW pages.
Using all means of delivery (FTP, standard GET, and GET with F=MIME), the
ASCII code 29 comes through just fine and it's worked well.
 
Then we discovered we needed an additional code, so we began using ASCII code
28. This character is stored properly and is delivered properly using all the
above described methods *except* F=MIME.  When the F=MIME option is used to
GET the file (either via command or AFD), the code 28 is transposed into a
code 130. I have confirmed this using two separate BASE64 decoders.
 
My questions: Why is this happening? Is it a bug? Should we use another
code (27 perhaps) and forget about it?
 
My theory: Something is wrong with the internal BASE64 encoder in
[log in to unmask]
 
Any ideas would be helpful.
 
Mark Hunnibell                  Email: [log in to unmask]
KIDLINK Gopher/WWW Coordinator  http://www.connix.com/~markh/index.html