[comp.sys.ibm.pc] Why UUEncoding?

irwin@uiucdcsb.cs.uiuc.edu (08/18/87)

/* Written 11:48 am  Aug 17, 1987 by sierra@lll-tis.arpa in uiucdcsb:comp.sys.ibm.pc */
/* ---------- "Why UUEncoding?" ---------- */
>I know of two reasons for UUEncoding files for sending through Mail:

>  1. UUENCODE only transmit printable characters:
>     Many display terminals interpret sequences of non-printable
>     characters as commands to the terminal.  Thus, with printable
>     only characters the possibility to put the user display
>     terminal on the Twilight Zone state, is remote.

>     Does Mail commands or servers make use of non-printables as
>     commands too?

>  2. UUENCODE provides control and checksum:
>     When files are transmitted through probably noisy lines,
>     there are chances to lost information on the process.  Some
>     check characters and file integrity checksums provides the
>     mechanisms to determine, most of the time, if the file was
>     received correctly.

>Besides this two reasons, are there any other good reasons for
>sending UUEncoded files?  One problem with UUENCODE is that the
>file size is increased by approximatyely 35% (increasing the
>cost in transmisssion).
/* End of text from uiucdcsb:comp.sys.ibm.pc */

Allow me an attempt at an explaination:

On a HEX basis, 8 bits, 00 through FF are the possible combinations.
ASCII chars use 00 through 7F. Bytes that fall in the 80 through FF
are non ASCII and are considered "binary".

Note that 00 through 7F never has the left most bit set to a "1".
As a result, when sending ASCII files, this bit CAN be used to indicate
parity. NOW, how do you know if you are sending a byte that is ASCII
with parity, or a binary byte of 80 and above? It gets confusing, and
protocols of various systems tend to cloud the issue.

Hence, if you are sending strictly ASCII, you do not have to UUEncode
the file, but if you are sending a binary file, you must encode it
and then UUDecode it at the destination, converting it back to binary.

In this manner, an ASCII file can be sent with or without parity, as
the systems involved require. The fact that the UUEncoded file requires
more file space, is that to represent a none ASCII char, more than one
byte can be required to code a non ASCII char into ASCII form.

burton@parcvax.Xerox.COM (Philip M. Burton) (08/19/87)

In article <164300018@uiucdcsb> irwin@uiucdcsb.cs.uiuc.edu writes:
>
>/* Written 11:48 am  Aug 17, 1987 by sierra@lll-tis.arpa in uiucdcsb:comp.sys.ibm.pc */
>>  2. UUENCODE provides control and checksum:
>>     When files are transmitted through probably noisy lines,
>>     there are chances to lost information on the process.  Some
>>     check characters and file integrity checksums provides the
>>     mechanisms to determine, most of the time, if the file was
>>     received correctly.
>
>>Besides this two reasons, are there any other good reasons for
>>sending UUEncoded files?  One problem with UUENCODE is that the
>>file size is increased by approximatyely 35% (increasing the
>>cost in transmisssion).

The supposed checksum benefit of uuencode'd files is lost if a single file is
split up into several mailnotes.  My earlier request was that
people create several uuencoded'd files, if necessary, to transmit the
entire contents of an ARC file.

I have found that reconstituting a split up uuencoded'd file often doesn't work.







-- 
Philip Burton
Xerox Corporation    408 737 4635
 ... usual disclaimers apply ...