Harley Hahn's
Usenet Center


Home Page

File Sharing   NEW 
• Tutorial
• Posting Binaries

Quick Start Guide

Hands-On Guide

Le petit guide
illustré sur Usenet

Master List
of Usenet

Harley Hahn's
Usenet Tutorial

Usenet Glossary

Site Map

About Harley

Harley Hahn
Home Page

Send a Message
to Harley

  Top Usenet

  Top Usenet

Usenet Tutorial

How Binary Files Are Handled

As we have discussed, Usenet articles have four parts. The header, the body and the (optional) signature are all text. An article may also contain a separate file called at attachment, which can hold any type of data: not only pictures, but videos, music files, software, and so on.

From the beginning, however, Usenet has only been a text-based system. In other words, Usenet articles — including attachments — can contain only textual data. This requirement is part of the basic design of Usenet, which works well. However, it does create a problem: How can a purely text-based system transport large amounts of binary data?

The solution is that all binary data must be encoded as text before it is sent out as part of a Usenet article. At the other end, the text­encoded data is converted back into binary data to recreate the original file.

In the olden days, this encoding and decoding was done by using a system called UUENCODE (Unix to Unix encoding), usually spelled "UUencode" and pronounced "you-you-encode". The UUencode system was used for years, but it had an important problem: when binary data was encoded as text, it would expand by 30-40 percent.

To be sure, when the data was decoded at the other end, it would regain its original form. However, in transit, the size of the textual data was much larger than the original binary data. Since a very large number if binary files are posted to Usenet every day, the UUencode system created significant demands for bandwidth, processor time, and storage capacity. (You will remember that the Usenet distribution system requires an article to be transmitted many times, from one news server to another, in order for the article to propagate throughout the world.)

Today, binary data is encoded using a system with far less overhead. This system is called YENC, usually spelled "yEnc". yEnc is much more efficient than UUencode, in that it the text-encoded data is only 1-2 percent larger than the original binary data.

(You are probably wondering, where did the odd name "yEnc" come from? yEnc was created and released into the public domain in 2001, by a programmer named Jürgen Helbing. Four years earlier, Helbing had created a project named MyNews, and he wanted to use a similar name for his new encoding scheme. That is, he wanted to use MyEncode, or MyEnc for short. However, he found that these names had already been taken so, in a moment of whimsey, he removed the "M" and decided to use yEnc.)

Large binaries pose a particular problem, because Usenet servers impose limits on how large a single Usenet posting can be. For this reason, large files are typically broken up into parts, each of which is posted separately. Such files are called MULTIPART BINARIES or MULTIPART POSTINGS. At the receiving end, the various parts of a multipart binary are gathered and reassembled back into the original file.

In the olden days, all of this had to be done manually. Today, most of the work is done by your newsreader. When you want to send out a binary file, your newsreader will encode the binary data, break it into parts, and send it out as a multipart posting. When you receive a multipart binary, your newsreader will put the parts together and then decode the textual data back into the original binary file. If the file contains a photo, your newsreader will show it to you automatically.

Thus, using Usenet to look at pictures is easy. Just use your newsreader in the usual way. When an article contains a picture in the form of an attachment, your newsreader will automatically show it to when you look at that article.

Jump to top of page