yEnc : Java Glossary

A new more efficient way of transporting binaries around in newsgroup attachments.
Unfortunatly, yEnc itself does not use MIME (Multipurpose Internet Mail Extensions)
headers, which means content types are not labeled and it is not designed for email.
yEnc files are always stored to disk at their destination so the receiver does not
need to know what kind they are. They are effectively all MIME
type application/octet-stream.

8-bit attachments for email will have to wait. Email evolution seems utterly stuck
in the dark ages. Every improvement reeks of eau de kludge. You only get a chance to
make changes in communication standards once every couple of centuries or so, yet
people still fail to plan ahead.

yEnc uses uses 252 of the possible 256 byte codes. Only NULL, CR, LF and
'=' are escaped. For some applications it might be necessary to encode other
characters as well, especially leading/trailing SPACES and TABs. The escaping
mechanism is generic so if the channel is interfering with some character, it is easy
to add it to the escaped list.

yEnc does not have built-in compression. That is handled at another level. Because
binaries typically contain many NULLs, usually the characters are rotated by 42
before encoding. Why is yEnc so much more efficient than the competition? Other
encodings (UUenc, Base64, BinHex, Encode) are doing their very best to avoid
control-chars (0x00-0x1F) and the 8th bit. They are using only 64 or 96 chars out of
the possible 256. BinHex, for example, has 100% overhead by avoiding perfectly valid
bit patterns. Base64 has an overhead of about 33%. yEnc has an overhead of only about
2%. Such encodings are still respecting old computer software which was never
prepared for 8-bit — but works properly only with
7-bit US-ASCII. yEnc is 8-bit. It
is new and still unofficial. Agent, Gravity and Xnews newsreaders already support it.
It was devised by Juergen Helbing of
Germany.