mschmidt@exunido.UUCP (06/25/87)
Uuen/decode - question (and flame)
Till now, I thought, that uuen/decode makes sending of arbitrary data over
arbitrary nets possible. But this seems not to be the truth ...
The Problem ...
I had to send a number of files with C and Fortran source from an UTS/V
system to a MUNIX system (both Sys V descendants). Unfortunately the
only connection between them is a RJE link to a mainframe. (You know that stuff?
It's "Remote Job Entry" - an oldfashioned way of connecting computers.)
RJE truncates lines longer than 80 characters, so I decided to shar the
files, uuencode it, send it over RJE (the manual says, that only printable
characters are used by uuencode), uuedecode and then unshar the whole thing.
When I try to uudecode the received data, I got the message "no end line"
(very informative!). A look at the sent file shows, that the "end"-line was
there! Well, after thinking a while, I got it: The RJE system filles lines
with blanks up to 80 characters (from RJE's point of view the whole world
consists of punched cards, no hole in the pasteboard means 'blank') - and
uudecode don't like this blanks. After vi'ing (1,$s/ *$//) uudecode works
fine, but the result was not the original contents of the file. What
happend? Well, *some* of the blanks at the end of line *are* significant
to uudecode. Grrrr!!
So, I did the job once more, but before sending, the uuencoded data was
vi'ed with 1,$s/$/@END@/ or something like that, so that I can edit
the received data, throwing away the @END@ and following blanks. But
when trying this, vi gives the message ... characters non-ASCII!.
Looking at the data, I found some lower case 'f's (which weren't really
ASCII-'f's!), that cause the message. The original uuencoded file has
'^'s (hat) at these points. Probably, the translation/retranslation of the
data to/from RJE (EBCDIC!) has failed. The real cause seems to be, that there
is no non-ambiguous assignment for special characters (like ^~\|{}) between
ASCII and EBCDIC.
After changing the 'f's to '^'s and uudecoding, the result was not the
original file. Some characters were missing. Again: Grrrr!!
Now the flame ...
Knowing that mailers have problems with blanks, because sometimes
they change the number of them in the data, why, the hell, is just
the blank a significant character for uuen/decode?!
Why isn't the uuencoded data formed like
<start_of_line_character_sequence><piece_of_uuencoded_data><end_of_line_seq>
so that uudecode can find out the significant part itself, whether how
much blanks are before or after it?!
Knowing that there are problems with special character translation between
the different "standard" codes, why are special characters used for encoding?!
WHY MUST ONE BE A WISARD TO USE UUEN/DECODE??!!
And now the question ...
Can someone help me? Are there any other possibilities of encoding
*arbitrary* data, that can be sent over *arbitrary* nets?
Thanks for listening.
------------------------------------------------------------------------
Martin Schmidt
mschmidt@mcvax!unido!exunido.uucp
ccb010@ddohrz11.bitnet
------------------------------------------------------------------------roy@phri.UUCP (Roy Smith) (07/03/87)
In article <119700003@exunido.UUCP> mschmidt@exunido.UUCP writes: > Can someone help me? Are there any other possibilities of encoding > *arbitrary* data, that can be sent over *arbitrary* nets? Btoa/atob do essentially the same thing that uuencode/uudecode do, but somewhat more efficiently (20% instead of 25% overhead). I don't know, however, if btoa'd files are any more RJE-proof then uuencoded ones are. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016