Mac E-M@il Resource Page

AppleDouble and AppleSingle

By Rich Siegel, Bare Bones Software

AppleSingle and AppleDouble are both -binary- packaging conventions, and do not specify or imply the transfer encoding.

It's very important to understand the difference between "packaging" and "transfer encoding". On the Mac, packaging is pretty important because Mac files consist of three components: data fork, resource fork, and file info. So to transfer a Mac file in its entirety, you need to package it up such that it can be recreated by the receiving client.

Since many transfer links or lesser email clients can only handle US ASCII characters, it's usually desirable to encode a binary file so that it can be transmitted across a 7-bit link and recreated on the other side. The "transfer encoding" specifies the fashion in which this is done, and is essential to transmitting non-ASCII files via email, regardless of the sending or receiving platform.

UUcode and BASE64 are both transfer encodings; they take any binary data as input, and convert it to a pure ASCII form which can be transmitted over any text-only link. UUcode is slightly more specialized, because it was originally designed for transmitting files over text-only UUCP links, and thus contains a "begin" line, which specifies the file name and the Unix permissions for that file. (That's what the "644" is.) BASE64 is newer, and can be used to encode any arbitrary stream of data.

AppleSingle and AppleDouble are both packaging conventions: they take any Mac file, and "flatten" it into a representation which can be stored on any non-Mac file system, and then subsequently recreated into the original Mac file. After packaging a file with AppleSingle or AppleDouble, a transfer encoding -must- be applied if the file is to be transmitted across a 7-bit link (such as email).

If you're writing to a correspondent who is on a Mac, using any modern Mac email client, it really doesn't matter what you use for either packaging or transfer encoding - all of the currently available clients can handle various combinations of packaging and transfer encoding.

If you're sending a Mac file to a correspondent who's not using a Mac, but who can handle the data of a Mac file (be it text or any other format), use AppleDouble. If the email client he's using is suitably advanced, then it will be able to present the data portion of the file. Again, it doesn't matter what transfer-encoding you use, assuming that the recipient's email client is reasonably modern.

If you're sending a Mac file to a correspondent who's not using a Mac, but the Mac file must be used in its entirety (data, resources, info) and no part is disposable, then use AppleSingle. Your correspondent will more than likely need a Mac to use the file anyway, but AppleSingle is a packaging that can be transported across multiple (non-Mac) platforms and from which the original Mac file can be re-created in its entirety. If any part of an AppleDouble package is lost, you'll be unable to recreate the original file.

As with AppleDouble, the transfer-encoding is irrelevant so long as the receiving client can decode it. Most modern clients can handle BASE64 and decode it.

Notice that I haven't mentioned BinHex. That's because it only adds to the confusion, because it combines -both- binary packaging -and- transfer encoding. In general, you should only use BinHex to encode files that you're sending to someone who is using a Mac - but as I pointed out, if they're using a Mac, it really doesn't matter what you use.

Finally, observe in all of this that I haven't mentioned compression. There's a reason for this - it's a rat's nest of possibilities. For another thing, the choice of compression is independent of binary packaging and transfer encoding. If you're sending a compressed file, use whatever format your correspondent can handle - just as if you were sending an ordinary document.

© 1998-2000 by Omar Shahine