yEnc : Java Glossary

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.