Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!jarthur!nntp-server.caltech.edu!madler From: madler@nntp-server.caltech.edu (Mark Adler) Newsgroups: comp.compression Subject: Re: COMPRESSING of binary data into mailable ASCII Message-ID: <1991Mar26.233839.24835@nntp-server.caltech.edu> Date: 26 Mar 91 23:38:39 GMT References: <12485@pt.cs.cmu.edu> <12489@pt.cs.cmu.edu> Organization: California Institute of Technology, Pasadena Lines: 26 In article <12489@pt.cs.cmu.edu> tgl@g.gp.cs.cmu.edu (Tom Lane) writes: >However, it'd be nice to hear from someone who uses non-ASCII mailers about >just which characters are safe. (Anybody have an EBCDIC character chart >handy?) One thing that might be good to avoid is putting '.' at the start >of a line, which btoa will do quite happily. The set of 85 characters that I use in "ship" was originally selected for a full screen file transfer program on IBM 3270 terminals emulated through an ASCII terminal, so it had to go through a lot of EBCDIC paths, as well as get translated to and from ASCII. At the time, I checked several IBM ASCII/EBCDIC translation tables (all different, of course) and picked a set that had common translation in all of them. And the set works through IBM (RSCS) mail. Your suggestion about avoiding a '.' in the first character is interesting. Why? Are the any other things to avoid that people out there knows messes up mailers? I already know about an indented first line getting chewed up sometimes. One thing that I think we know is that lines lines that start with 'M' (as in uuencode) work through Unix mail. However, one character per line seems like too much overhead to me. It would not be hard to detect troublesome lines generated by the base 85 encoding and stick a character in front that will be ignored later. Mark Adler madler@pooh.caltech.edu