Last week's article in TidBITS-444 about the need for developers to support MacBinary III brought in a lot of email from people confused about various Macintosh file formats that appear on the InternetShow full article

Hide full article

Last week's article in TidBITS-444 about the need for developers to support MacBinary III brought in a lot of email from people confused about various Macintosh file formats that appear on the Internet. What do these formats do, and how do they interact? I hope this article, written with the help of Leonard Rosenthol (the original developer of StuffIt Expander), will clear up confusion.

<http://db.tidbits.com/article/05050>
<http://www.aladdinsys.com/expander/ index.html#Win>

First off, Mac users regularly deal with three kinds of encoding formats: archiving formats (like StuffIt, Compact Pro, and Zip), binary packaging formats, and transfer encoding formats. Archiving formats bundle multiple files into a single file, compressing the originals in the process. I'll assume that everyone understands the concept behind lossless compression - you replace repeating patterns of data within a file with a token representing those patterns, thus reducing the amount of data needed to represent the original.

Binary packaging and transfer encoding formats are more complicated, and worse, they can be combined in the same format. Binary packaging formats include MacBinary, AppleSingle, and AppleDouble. Transfer encoding formats include uuencode, Base64, and quoted-printable. Last but not least, the venerable BinHex straddles the fence, providing both binary packaging and transfer encoding. Should you wish to encode or decode files manually, shareware utilities exist for some specific formats, and Aladdin's StuffIt Deluxe 4.5 provides translators for many as well. TidBITS readers can get a discount on StuffIt Deluxe - see the sponsorship area at the top of the issue for details.

MacBinary -- MacBinary is an old format, first proposed back in 1985 by Dennis Brothers on MAUG on CompuServe. Two years later, a group of developers made additions to the format to handle HFS and other changes in the Mac OS. That format, MacBinary II, has survived to this day, although it is being replaced by MacBinary III to address the issue raised by the new file flags originally slated for Mac OS 8 and appearing now in Mac OS 8.5. Interestingly, the MacBinary II format has an option for a "secondary header" for future expansion, but it's never been used.

As a binary packaging format, MacBinary bundles up the data fork and the resource fork, along with Finder information about the file (type, creator, etc.). In bundling the two forks of a Macintosh file together, MacBinary protects the file when it's uploaded to a Unix machine or PC, neither of which support Macintosh two-forked files. Without MacBinary, resource forks would be lost, which could be disastrous or merely annoying, depending on the file.

Support for MacBinary is broad within applications, though users have seldom understood it because MacBinary support is generally transparent. When you upload a Macintosh file using Anarchie or Fetch, for instance, both default to uploading in MacBinary format. Part of the problem, I suspect, is that many people who upload files don't know to change the file name to reflect MacBinary's file extension - .bin. Some FTP applications, notably Fetch, try to add the .bin extension automatically.

Although application support has been broad, it's seldom deep. For instance, although Anarchie and Fetch deal with MacBinary correctly and transparently, Web browsers generally pawn MacBinary files off on a helper application, such as MacBinary II+ or StuffIt Expander. Without the appropriate helper application, you can't decode the file.

Worse, many Web servers don't set the proper MIME type for MacBinary files, which can result in old Web browsers trying to display the MacBinary file as text within the browser window. In this case, there are two solutions, short of updating to a modern Web browser. First, click and hold on the link and choose Download Link to Disk from the pop-up menu that appears in many browsers. Once you've downloaded the file, drop it on StuffIt Expander. Second, convince the Web site administrator in question to set the correct MIME type for MacBinary files. They should download in binary mode, with the "bin" extension, and using the MIME type "application/x-macbinary" (type and creator fields can be set to BINA and SITx so double-clicking the file launches StuffIt Expander).

Even more confusing, it turns out that Internet Config, and thus Internet Explorer, incorrectly sets the MacBinary MIME type to "application/macbinary", which is an uncompleted proposal. And, older versions of Netscape Navigator (at least 2.x, and possibly 3.x) don't set any MIME type for MacBinary at all. Without agreement between Web servers and browsers, there's a good chance that something will go wrong when a user clicks a link to a MacBinary file. In theory, forcing a download to disk and then decoding manually should work, but with so many variables, there's no telling. My recommendation: set the MIME type for MacBinary to "application/x-macbinary" wherever you see it, including Internet Config, Web servers, and older versions of Netscape Navigator. Other settings for handling MacBinary, such as the file suffix and an application to handle the files, should be the same as those mentioned above for Web servers.

Again, MacBinary is a binary packaging format, not a transfer encoding format. Thus, it requires a full 8-bit connection whenever the MacBinary file is being transferred. If someone still behind an obsolete 7-bit connection to the Internet tries to transfer a MacBinary file, it will be damaged in transit. (Some 7-bit connections still exist, but are rapidly fading into the mists of Internet past because both FTP and the Web's HTTP use 8-bit connections.) For that extremely uncommon situation, a transfer encoding format like BinHex is also necessary.

AppleSingle -- Like MacBinary, AppleSingle is an 8-bit binary packaging format. Most people have seen AppleSingle only in the attachment encoding format pop-up menu in Eudora or Emailer. Apple developed AppleSingle and AppleDouble in the days of A/UX, Apple's original version of Unix. Since A/UX didn't support two-forked Macintosh files, Apple needed a way to share files between A/UX and the Mac OS. MacBinary was the obvious choice, but because MacBinary stores the data fork first in the file, you couldn't do live edits on MacBinary files within A/UX. So, Apple reversed the order in which the forks were stored in MacBinary files (so programs could append or remove data without moving the resource fork), added some never-used options for future expansion, and called it AppleSingle.

Thanks to its extensibility, AppleSingle is a better format than MacBinary (it even supports the new Finder flags appearing in Mac OS 8.5), but it suffers from one significant problem: almost nothing supports it for file transfer. Email programs can often handle AppleSingle attachments, and Fetch can both upload and download AppleSingle files. Web browsers, however, are clueless. When the file flag issue that resulted in MacBinary III first arose, the immediate thought was to evangelize AppleSingle. But, without existing code, developers were loathe to put in the work necessary to support AppleSingle and to unleash a new file extension on the Mac community. MacBinary III was the course of least resistance.

AppleSingle use is primarily restricted to occasional email messages between Macintosh users (although Apple also uses AppleSingle when storing disk images). As a cross-platform format, AppleSingle falls down because it bundles the two forks of a Macintosh file together in such a way that they can't easily be separated - that's what AppleDouble is for. In short, unless you're sending an attachment to another Macintosh user, there's no point in using AppleSingle, and even then, AppleDouble works as well.

Since AppleSingle is an 8-bit format, AppleSingle files must be protected by a transfer encoding format when sent via email, since email protocols like SMTP (unlike FTP and HTTP) aren't guaranteed or required to be safe for 8-bit files.

AppleDouble -- AppleDouble stores the two forks of a Macintosh file as separate files (bundling Finder information like type and creator in with the resource fork). AppleDouble also came about because of A/UX. You could share files between the Mac OS and A/UX using AppleSingle if programs on both sides understood AppleSingle. However, if you were sharing files with other flavors of Unix using NFS (Network Filing System), programs on those machines were unlikely to understand AppleSingle. AppleDouble's technique of storing a Macintosh file as two separate files enabled those other Unix users to edit just the data fork without disturbing the resource fork. You won't see files stored in AppleDouble on Internet file sites, since it's silly to store two files for each file uploaded.

However, AppleDouble's way of splitting Mac files proved extremely useful for email, since each part of the file could be a different MIME part within a single message. That enables the receiving email program to pick out the parts it understands. If a Mac email program receives an AppleDouble-encoded attachment, it knows to read both forks and put them back together. If a non-Macintosh email program receives an AppleDouble-encoded attachment, however, it saves only the data fork, throwing away the resource fork.

In fact, AppleDouble is the standard for sending Macintosh files in email according to the Macintosh extensions to MIME, written by Eudora author Steve Dorner. Like AppleSingle, AppleDouble doesn't lose Mac OS 8.5's new file flags, which makes it the default format of choice for attachments in the future. Keep in mind, however, the fact that AppleSingle and AppleDouble can both store these new file flags, doesn't mean that older applications properly read the new flags or write them out again. So, even though these formats don't require any changes, applications still might.

Once again, AppleDouble is an 8-bit binary packaging format, so any AppleDouble email attachments must be protected by a transfer encoding format, generally Base64.

uuencode -- uuencode is one of the oldest of the Internet transfer encoding formats. Designed many years ago for transferring binary files via the text-only UUCP protocols that carried email and Usenet news, uuencode takes 8-bit data and converts it to 7-bit text. There are many uuencode implementations, but files are easily recognizable because they all start with a "begin" line that specifies the file name and the Unix permissions for the file (generally 644).

Transfer encoding formats like uuencode are essentially the reverse of compression software. They take groups of 8-bit bytes and represent them in a series of 7-bit characters. Thus, files encoded with a transfer encoding format always grow after encoding, up to 35 percent.

uuencode doesn't know about Macintosh file forks and encodes only the data fork of a Mac file. Not all Mac files have resource forks or store necessary information in them (Microsoft Word files, for instance, have resource forks, but they don't contain any information essential to the file), so uuencode proves an acceptable way to transfer files to Windows users. Support for uuencode is more common in Windows programs, so I fall back to uuencode when sending attachments to Windows users if AppleDouble fails (which it might if the recipient's email program isn't MIME-savvy).

Base64 -- Like uuencode, Base64 represents 8-bit files using 7-bit characters so they can withstand being transmitted over 7-bit links or using 7-bit protocols. Base64 wasn't developed originally for the Internet, but for PostScript Level 2 for computers to transfer binary data to printers.

Unlike uuencode, which sports numerous utilities, Base64 is almost entirely transparent to the user, being handled in the background by email programs. This transparency comes as a result of Base64 being a modern format that's handled by modern programs. In the past, computers and programs were less capable and users tended to be more sophisticated, so it was less necessary to make transfer encoding support transparent.

Quoted-Printable -- Quoted-printable, which most people know of only indirectly because of Eudora's QP button, is a transfer encoding format designed for representing high ASCII characters (special characters with diacritical marks, for instance) in 7-bit form. The important difference between quoted-printable and the other transfer encoding formats is that quoted-printable encoded text remains mostly human-readable. Quoted-printable isn't used for encoding files, just the text of email messages.

We've all seen email messages with equal sign characters at the ends of the lines - that's an indication of a quoted-printable message not being decoded, usually because the MIME header that specifies the quoted-printable encoding was deleted. This problem crops up primarily in mailing list digests, since mailing list software removes all but the essential headers from messages before combining them into a digest. The solution to this problem is MIME digests, which maintain headers for each message within the digest, facilitating bursting the digest into a mailbox and retaining special headers that specify transfer encoding.

BinHex -- I've saved the most confusing format for last. BinHex is a binary packaging and transfer encoding format originally developed by Tim Mann for the TRS-80 in the early 1980s and rewritten completely by Yves Lempereur for the Macintosh in 1984. Yves was also part of the team that created the MacBinary format, and he wrote the BinHex 5.0 program to support it. This caused some confusion because his BinHex 4.0 program used the BinHex format, whereas BinHex 5.0 used MacBinary.

<http://www.research.digital.com/SRC/personal/ mann/trs80.html#binhex>

The BinHex format solves both problems facing transmission of Mac files on the Internet. When you encode a file in BinHex, the encoder first combines the file's forks, then converts the 8-bit result into a 7-bit file. The combination of these functions made BinHex the most popular way to deal with Mac files on the Internet because you could be pretty sure that whatever you did, the original file would survive.

I shouldn't imply that BinHex is an entirely good thing any more. It was great back when 7-bit links were common, but in today's world, the 30 to 35 percent by which files grow when binhexed is an unnecessary waste of space and downloading time. Also, BinHex doesn't store Mac OS 8.5's new file flags, which will render it less useful in the near future.

That said, BinHex won't go away any time soon. Support for BinHex is widespread, and everyone recognizes the BinHex .hqx extension and knows how to decode BinHex files (drop them on StuffIt Expander). Because BinHex files are 7-bit text, they're more likely to survive badly configured applications, and in the past, it was even common practice to copy them out of an email message or a browser window into a text file, save it, and decode it. If you see BinHex text in today's software, something has probably gone wrong, and it's likely that the file will be damaged. Another minor advantage of BinHex's text format is that it can have human-readable descriptions above the BinHex code.

The main argument I've seen for why people like BinHex is that it works. That's true, and I'd never encourage someone to switch to something that worked badly. I've heard of situations where BinHex decoders deal better with huge files than MacBinary decoders, and the whole MIME type debacle with MacBinary that I mentioned above has also caused trouble. At the same time, though, our goal should be to identify and eliminate the problems that affect today's modern formats, rather than sticking, DOS-like, with what we're used to.

Hide full article

MacTech Conference, for IT Pros and Apple developers, is Nov 3-5,
in Los Angeles. The 3-day event is packed with sessions & evening
activities. Learn from the best. Meet and spend time with peers.
TidBITS readers save $50 at <http://macte.ch/conf_tidbits>!

Okay, we may have confused a few people with last week's quiz, where we asked "What's the best encoding to use when sending a file to a Windows user via email?" I'll get to the correct answer shortly, but first let me explain the confusion. Terminology -- As I explained in "Macintosh Internet File Format Primer," in TidBITS-445, there are usually two actions that take place for Macintosh files to be transferred via email: binary packaging and transfer encodingShow full article

Hide full article

Okay, we may have confused a few people with last week's quiz, where we asked "What's the best encoding to use when sending a file to a Windows user via email?" I'll get to the correct answer shortly, but first let me explain the confusion.

Terminology -- As I explained in "Macintosh Internet File Format Primer," in TidBITS-445, there are usually two actions that take place for Macintosh files to be transferred via email: binary packaging and transfer encoding. Binary packaging, which is the realm of formats like AppleDouble, AppleSingle, and MacBinary, deals with the problem of other platforms not understanding that Macintosh files can have both data and resource forks. Transfer encoding, which is done via Base64 or uuencode, takes an 8-bit file and converts it to 7-bit ASCII text that can survive the journey through Internet email, which only guarantees safe passage for 7-bit ASCII data. The BinHex format combines both binary packaging and transfer encoding.

<http://db.tidbits.com/article/05066>

Here's where we vexed some people. Most email programs, including Eudora, Emailer, and Outlook Express, call the process of formatting an attached file for transmission "encoding," thus conflating the binary packaging step with the transfer encoding step. That's not generally a problem for users, but caused some confusion in our quiz for people who know that Base64 (which garnered the most responses) is a transfer encoding format, whereas AppleDouble (the runner-up) is technically only a binary packaging format.

Now, you might be wondering, "So if AppleDouble is a binary packaging format, how does it survive being sent in email?" The answer is that an attachment, when packaged with AppleDouble and sent via email, is also automatically encoded via Base64. Under most circumstances, that Base64 encoding is transparent to users on both ends. Let me explain more about each email attachment format in turn.

The Correct Answer: AppleDouble -- Despite the turmoil we accidently engendered, AppleDouble is the best format to use when sending attachments to Macintosh or Windows users, and particularly if you're sending the same file to Mac and Windows users at the same time. That's because AppleDouble breaks the Macintosh data and resource forks of a file apart, then attaches them separately to the message, at which point they're also Base64 encoded for transfer. When a modern Macintosh email program sees the two attachments, it decodes the Base64 and then reassembles them into a single file. When an email program on another platform sees the two attachments, it throws the resource fork away and decodes only the data fork, since other platforms don't understand Macintosh resource forks.

Some have questioned my recommendation of AppleDouble over uuencode for sending files to Windows users. In reality, uuencode will work most of the time, but here's why I recommend AppleDouble over uuencode:

• If you're sending a file to both Macintosh and Windows users, and that file contains a resource fork that's useful but not necessary (as can be true of Microsoft Word or Nisus Writer files, for instance), AppleDouble preserves the resource fork for Macintosh users while allowing Windows email programs to strip it transparently. In contrast, uuencode can cause headaches for Macintosh recipients because it removes the resource fork completely.

• Base64, which is the transfer encoding format used by AppleDouble, is almost totally transparent to users, whereas uuencode is only usually transparent.

• Uuencode is not and will never be standardized, which leaves the door open for possible decoding problems.

• Finally, AppleDouble is the official Internet standard for sending Macintosh files in email, and there's nothing new about it. To quote from the MacMIME specification (RFC 1740), from December of 1994:

"AppleDouble is the preferred format for a Macintosh file that is to be included in an Internet mail message, because it provides recipients with Macintosh computers the entire document, including icons and other Macintosh specific information, while other users easily can extract the data fork (the actual data) as it is separated from the AppleDouble encoding."

<http://www.cis.ohio-state.edu/htbin/rfc/ rfc1740.html>

Usage of and adherence to standards is a good thing, and it's the main reason we have the Internet today. The sooner we eliminate obsolete email programs that understand only old attachment formats, the better off we'll all be, and the sooner articles like this will be unnecessary.

Note that some Macintosh email programs don't use the term "AppleDouble," but instead call it "MIME," and even Eudora has moved to calling it "AppleDouble ("MIME")." That's not entirely unreasonable, since "AppleDouble" doesn't lead you to believe that it's useful for sending files to Windows users. The problem, however, is that MIME will mean something different in Windows programs (and in Outlook Express 5.0 for the Mac), since Windows has no need for binary packaging at all, so "MIME" just means "Base64 encoding" for binary files that are attached to email.

The main problem with AppleDouble is that it doesn't work in a few rare cases, mostly for people behind old email gateways that don't properly support Internet standards. In that case, you'll want to use whatever you can figure out that works.

AppleSingle -- Whereas AppleDouble splits the data and resource fork into two files for attachment, AppleSingle bundles them together into a single file (much like MacBinary, which isn't used for email). AppleSingle's utility for email attachments is minimal, with spotty support through the Macintosh email universe. The main reason AppleSingle is still around is that the MacMIME specification also says that Mac files that lack a data fork, should be sent as AppleSingle. Overall, though, AppleSingle isn't generally relevant to most people today.

uuencode -- Again, uuencode is a transfer encoding format that throws away any resource fork information in the Macintosh file and converts the 8-bit file into 7-bit ASCII text. Although this destructive behavior with regard to the resource fork sounds bad, it actually isn't quite as awful as I've made out because no Windows applications would be able to read the resource fork of a Macintosh file, even if it was transferred. If a Macintosh document required its resource fork, it wouldn't be readable in Windows anyway. And if you were to send a Macintosh application via email with uuencode encoding, the application would be destroyed, but since a Macintosh application can't run under Windows, there's no loss.

The main reason uuencode still exists is historical - it was so prevalent in the days before MIME that it remains a necessary fallback when sending to folks using Windows and other platforms who haven't upgraded their email programs in several years.

Base64 -- As a transfer encoding format, Base64 is quite similar to uuencode but has the advantage of being modern and standardized. As with uuencode, if you send a Macintosh file using Base64 encoding, you'll lose the resource fork. Remember that Base64 is automatically used with AppleDouble, and if you're looking at a Windows email program, "MIME" in the context of attachment formats probably means Base64 encoding

<http://www.cis.ohio-state.edu/htbin/rfc/ rfc2045.html>

I haven't quite been able to complete testing with AOL, but it appears that Base64 is the best choice for sending attachments to AOL users. Other formats work, but not as seamlessly. We'll have results next week.

BinHex -- As I noted above, BinHex is an amalgam of binary packaging format and transfer encoding format. It combines both forks of a Macintosh file, then turns that 8-bit file into 7-bit ASCII text for sending. BinHex remains popular for sending files via email between Macintosh users, since essentially all Macintosh email programs understand BinHex. However, BinHex works far less well when sending files to Windows users, since few Windows email programs other than Eudora can decode BinHex. Many Mac users still rely entirely on BinHex for sending files via email, and if it works for you, that's fine. However, I would encourage you to switch to AppleDouble if possible, and here's why:

• Although BinHex is standardized, unlike uuencode, it's still an old format that would be good to relegate to the back burner for occasional needs so as to encourage everyone to upgrade to and support AppleDouble (most modern email programs do).

• If you send a file to both Macintosh and Windows users, there's a good chance that the Windows users won't be able to decode the file if you used BinHex.

• As discussed in "Calling Developers to MacBinary III" in TidBITS-444, BinHex doesn't support the new icon badges or custom routing information that's been available since Mac OS 8.5 shipped. That information may not be crucial, but there's no reason to use encoding formats that don't support it.

<http://db.tidbits.com/article/05050>

On the other side of the argument, BinHex includes an integral checksum at the end of the file, which means it's easier for an email program to check the attachment for corruption when BinHex is used than with other formats.

Quoted-Printable -- Although quoted-printable, which most people have only seen via the QP button in Eudora, is a transfer encoding format, it's used not for attachments, but for high ASCII characters (special characters with diacritical marks, for instance). Since they aren't part of 7-bit (or low) ASCII, quoted-printable encodes such characters as an equal sign followed by a number. Since all other low ASCII characters remain intact, the message remains mostly human-readable despite the quoted-printable encoding.

An email message with equal signs at the ends of the lines is almost certainly a quoted-printable message that hasn't been decoded, usually because the Content-Transfer-Encoding header that specifies the quoted-printable encoding is missing. This problem crops up primarily in mailing list digests, since mailing list software removes most headers from messages before combining them into a digest. The main solution to this problem is MIME digests, which maintain headers for each message within the digest, facilitating bursting the digest into a mailbox and retaining special headers that specify transfer encoding.

The Role of Compression -- Just when you thought you had a handle on all this, I'm going to throw in another variable: compression. It's often a good idea to compress files before sending them via email. That's especially true if you're sending large files or if you want to attach many files to a single message, since compressing the files into a single archive will save space and may make them easier to work with on the other end. I say "may" because one of the developers of Mulberry, which is primarily an IMAP email program, noted that in the IMAP mentality everything lives on the server until requested by the client, so being able to pick and choose one of several attachments to download is an advantage.

Compression can offer another advantage in that it may allow Macintosh files to survive transfer encoding that would normally destroy a file's resource fork. For instance, a StuffIt 5 archive stores everything in the data fork, so uuencode and Base64 won't damage it. Previous versions of the StuffIt file format could store some data in the resource fork (believe me on this, the information comes straight from the developers); moving everything to the data fork for cross-platform support was one of the main reasons Aladdin introduced the StuffIt 5 format. So, if you're using an email program that can compress files automatically before sending, uuencode and Base64 may work much better for you.

Of course, if you send a compressed file to a Windows user via email, they may be able to decode the attachment fine but find themselves left with a compressed file that they can't expand. If you anticipate sending that person lots of compressed files, encourage them to download a free copy of Aladdin Expander for Windows, which can decode a wide variety of formats, much like StuffIt Expander on the Mac side. On the other hand, if you need to send a compressed file to a Windows user only occasionally, both DropStuff 5.5 and StuffIt Deluxe 5.5 can create Windows self-extracting applications (.exe instead of .sea) that your recipient could launch to expand.

<http://www.aladdinsys.com/>

Another use for compressing files is if you want a Windows or Unix machine to be a go-between for two Macs with files that require resource forks. By compressing the file down to just a data fork, you can ensure that no information is lost when the file stops temporarily on an intermediate machine before moving on to the destination Mac (via a network, floppy disk, or some other transfer mechanism). Of course, this assumes StuffIt Expander is available on the destination Mac.

What You Attach -- Throughout this discussion, I've barely skimmed the surface of the types of files you're attaching to email. It won't do your recipient any good if you choose the proper attachment format if they can't open the document inside. The variables involved with choosing the proper format are numerous, but follow these recommendations and you'll be on the right track.

• If possible, ask what programs your recipient has that could open the file you're planning on sending. Then save the document in a format that you know can be opened by the recipient's programs.

• Make sure to give your files appropriate filename extensions for Windows, since without a .doc extension, for instance, Windows can't figure out that a file should open in Microsoft Word. Some email programs help with this; Outlook Express can optionally add extensions automatically, and Eudora goes to some effort to provide the extension in the meta-data about the attachment, without changing the actual name of the file.

• Most document formats for major productivity applications like the Microsoft Office suite, Adobe products, and so on, are fully cross-platform. If you stick to well-known applications that have Macintosh and Windows versions, conversion isn't likely to be a major issue. With files like spreadsheets and databases, sticking with the formats used by popular applications is your best bet, since the few available interchange formats are often quite limited and annoying to use.

• For word processing documents, Microsoft Word format (without the Fast Save option turned on) is the usually best choice and the most likely source format, followed by RTF if either of you aren't using Microsoft Word. If all else fails, drop down to straight text, which you can send within the body of a message instead of as an attachment. As a matter of manners, if you're sending a document that's meant to be read-only, and the contents are pure text, just paste them into the body of the message rather than using an attachment.

• For graphics, stick either to the native file formats of cross-platform applications like Adobe Photoshop or to standard and well-supported graphics formats like GIF, JPEG, TIFF, EPS, and PNG.

• For sounds, stick to standardized formats like AIFF, MP3, and WAV.

• When in doubt, keep a copy of DataViz's MacLink Plus around (apart from a brief hiatus recently, it has shipped with the Mac OS for a long time) for translating between different file formats.

Sealing the Package -- I hope this article has thrown some light on what has traditionally been a murky subject. The question that prompted the entire topic - the best format to use when mailing files to Windows users - seems relatively simple, and in an ideal world, we wouldn't even think about it. That's in large part why I recommend AppleDouble (with its transparent Base64 encoding) for everything - it should work with all modern email programs that adhere to Internet standards. The fact that it doesn't always work doesn't mean that we should rely on other formats for more than the occasional file to a user of an old email program. Rather, it means that we should work all the harder to make sure AppleDouble is supported everywhere so the entire question can fade into the depths of Internet lore, where it belongs. No one should even have to think about attachment formats, and only with full compliance with the MIME standards of AppleDouble and Base64 can we reach that point.

Next week I'll finish this topic off with information about what formats today's major email programs support for sending attachments, plus the results of our tests with receiving attachments on AOL.

Hide full article

Pear Note 2: More complete, understandable notes on your Mac.
Typed notes are blended with recorded audio, video, and slides
to create notes that make more sense when you need them most.
Learn more at <http://www.usefulfruit.com/tb>!

The hubbub we caused with last week's "Email Attachment Format Explained" article is only just subsiding - indication, I think, that this topic creates strong feelingsShow full article

Hide full article

The hubbub we caused with last week's "Email Attachment Format Explained" article is only just subsiding - indication, I think, that this topic creates strong feelings. It's frustrating when you think you're doing everything right with sending attachments but still can't get one through. This week I'll try to shed more light on the issue, and I also recommend that you read the threads these topics spawned on TidBITS Talk.

<http://db.tidbits.com/article/05787>
<http://db.tidbits.com/getbits.acgi?tlkthrd=921+ 929>

Loose Threads -- First, let me address some questions generated by last week's article, and then I'll look at how you work with attachment formats in the major Macintosh email clients.

Many people seemed confused about AppleDouble, with several asking "Is it a program?" To reiterate, AppleDouble, like AppleSingle, BinHex, Base64, and uuencode, is a file format - a specific organization of related bits. Every file on your hard disk exists in a specific format, whether it be the format created by AppleWorks, Microsoft Word, or StuffIt Deluxe. Some file formats like AppleDouble are handled within other programs almost exclusively, so you're unlikely to see a program devoted to creating and decoding AppleDouble files.

Many people recommended Adobe's PDF (Portable Document Format) as another format that's useful for sending files between platforms. Creating a PDF file is generally as simple as printing; see the TidBITS Talk message linked below for a list of ways to create PDF documents. To read a PDF document, you need Adobe's free Acrobat Reader. One tip that I hadn't realized previously: if you want to copy a chunk of text from more than a single page of a PDF document from within Acrobat Reader, you must first set the Default Page Layout to Continuous in File -> Preferences -> General Preferences. We have no idea what Adobe was thinking when they came up with this interface - who ever heard of modifying the functionality of a ubiquitous command like Copy based on your default page layout?

<http://db.tidbits.com/getbits.acgi?tlkmsg=5796>
<http://www.adobe.com/products/acrobat/ readermain.html>

Another popular recommendation for cross-platform file support was the Zip compression and archiving format that's common in the Windows world. Although utilities for creating and expanding Zip archives on the Mac have been around for a long time, they haven't been particularly well known. That should become less of a problem now that Aladdin has released the shareware DropZip 5.5 (bundled with StuffIt Deluxe 5.5), which enables you to create Zip archives. One of the problems with Zip in the Macintosh world is that Zip by default only preserves the data fork of Macintosh files. Aladdin's DropZip 5.5 (as well as Tom Brown's $15 shareware ZipIt utility) can optionally encode Macintosh files with resource forks in the protective binary packaging format MacBinary before compressing, which lets Zip archives contain Macintosh files without fear of data loss. Unfortunately, a Zip archive with MacBinary-encoded files inside isn't necessarily usable in Windows unless the user decodes using Aladdin's free Aladdin Expander. For more details about MacBinary, see "Macintosh Internet File Format Primer" in TidBITS-445.

<http://www.aladdinsys.com/dropzip/>
<http://www.aladdinsys.com/expander/>
<http://www.maczipit.com/>
<http://db.tidbits.com/article/05042>
<http://db.tidbits.com/article/05066>

To simplify the lives of less-experienced recipients, you might include information in the body of the message telling them precisely what you're attaching and the details of any compression and encoding formats you've used. Then, if something goes wrong, they have a chance at figuring out what to do, particularly if you included some boilerplate information about how to decode, expand, and open attached files.

Finally, I want to note that although there are lots of "shoulds" when it comes to which attachment formats work, the only absolute answer is the one you can verify for yourself in a particular instance. If there are weird email gateways in between you and your recipient, if either of you are using LAN-based email programs that have not been updated to support true Internet email, or the phase of the moon is wrong, your attachments may come through corrupted. The only solution is to try alternate attachment formats and see what you can make work.

Test It Yourself -- I spent a bit of time sending messages with attachments to friends who use AOL in an attempt to figure out what AOL does with different attachment formats. After I was done, I realized that with a little work in Eudora, I could set something up for anyone to receive the same tests and see how they worked. With a combination of stationery, filters, and automatic mail checks, I've created a simple auto-reply system using a copy of Eudora Pro running on a Power Mac 7100 here. When Eudora receives a message with a specific subject line, it returns a file using a specific encoding format.

For instance, want to see if you can receive an inline GIF encoded with Base64 via your Lotus Notes account at work? Just send the appropriate test message and Eudora will reply. The system checks for new requests every 10 minutes, so it could be 20 minutes or more before you receive a response, depending on traffic. Please use this service only for serious testing, since it's not intended to support extremely high loads.

The four attachment formats I've used are AppleDouble, Base64, BinHex, and uuencode. My ten test files are an inline GIF image, an inline JPEG image, a Word document, a PDF document, a SimpleText file, a Macintosh application (a self-extracting archive), a Windows application (an .exe self-extracting archive), a stuffed Word document, a stuffed Macintosh application, and a Zip archive of two Word files. That provides 40 possible combinations, including one (the uuencoded Macintosh application) that is guaranteed to fail.

To access these messages, visit the Web page below and click the links for combinations that interest you. The system checks for exact matches in the subject lines to avoid loops and reduce the impact of spammers, so I strongly recommend that you don't try to guess at the appropriate subject lines.

<http://www.tidbits.com/resources/516/ attachments.html>

Unfortunately, there's no way to reverse the testing and figure out how to receive attachments on the Mac from random other email programs. That you'll have to do on your own.

Looking at Specific Email Programs -- All that said, here are details on using different encoding formats with each major Macintosh email program.

• AOL: There's no way to change how AOL formats attachments, which are sent as Base64 unless a resource fork is present, in which case at least recent versions of the AOL software use AppleDouble. Text files (which includes anything you manually encode with BinHex or uuencode before sending) are sent in the body of the message rather than as an attachment. To decode such files, save the text out to a file, concatenating it carefully if necessary, and then drop the resulting file on StuffIt Expander.

  More the issue is how AOL receives attachments, a concern that's generally moot with true Internet email programs. For instance, AOL cannot accept multiple attachments in a single message (try compressing multiple files into an archive or sending them separately). If you're sending a file to an AOL user, the best attachment format appears to be Base64, which worked in the most test cases and with the least additional fussing. BinHex and uuencoded documents generally arrived intact, but came in with the .mim extension (for MIME) and were usable only after they were decoded by StuffIt Expander (Mac) or Aladdin Expander (Windows). AppleDouble attachments also usually arrived intact, but with the filename "Unknown." They could be opened manually on the Mac if you chose Open from the File menu in an appropriate program, and in Windows if you added an appropriate filename extension. AOL appears to do some image conversion, so the tests of inline JPEG images worked, but arrived as PNG files.

  These test were done with AOL 4.0 on both the Mac and Windows; the Windows 5.0 client may have different behaviors. But remember, you never know what version of AOL someone may be using, and the older it is, the more likely you are to have trouble.

<http://www.aol.com/>

• Emailer: In Claris Emailer 2.0v3, click the disclosure triangle next to the paper clip in an outgoing message to reveal the attachments pane. An Encoding pop-up menu lets you choose among different formats including: Service default, No encoding, BinHex, Base64, uuencode, AppleSingle, and AppleDouble. The service default option is tricky, since it's necessary for Emailer's compatibility with CompuServe and AOL mail, but if you use it for Internet email, it picks up the encoding from the account settings, which default to BinHex. Emailer also tries to compress attachments automatically; you can disable that feature with a checkbox in the attachments pane. Note that Emailer happily lets you send - without warning - an attachment that requires its resource fork via uuencode or Base64 even though the file will be destroyed in the process.

<http://www.macemail.com/emailer/>

• Eudora: In all versions of Eudora, you set the default attachment format in the Attachments panel of the Settings dialog box. You can override that setting for each individual message using the attachment format pop-up menu in the upper left of an outgoing message window. Turn on balloon help before clicking that menu to see descriptions of each option. Eudora can send attachments using AppleDouble, AppleSingle, BinHex, and uuencode (Eudora Pro only). Eudora can also send in Base64 format as long as the file being sent doesn't require more protection for its resource fork. The easiest way to set Base64 is to choose AppleDouble as the encoding format, and then turn off the "Always include Macintosh info" button, which is the button in the outgoing message window's toolbar, next to the QP button. Turn on balloon help and point at it for more information.

<http://www.eudora.com/>

• Green 1.0b8.1: In Green, you set the attachment format in the Send tab of the Preferences dialog. You can choose among AppleDouble, Base64, and BinHex. Green is up front about Base64 sending only the data fork, but you can't change the encoding format for individual messages.

<http://www.eware.fr/dev/>

• Mailsmith: In Mailsmith, you set the default attachment format in the Preferences dialog, and you can override those settings on a per-attachment basis in the Enclosures tab of the outgoing message you're composing. Mailsmith supports AppleDouble, AppleSingle, Base64, BinHex, and uuencode and can compress attachments automatically with StuffIt (you can override that compression on a per-attachment basis).

<http://www.barebones.com/products/msmith/ msmith.html>

• Mulberry: Mulberry offers the standard formats, AppleDouble, AppleSingle, Base64, BinHex, and uuencode, and lets you set a default within the Attachment panel of the Preferences dialog, plus override that setting on either a per-message or per-attachment basis. Mulberry can also automatically switch formats to override the default setting (which is Base64 initially) when the attachment contains a resource fork that would otherwise be lost. Interestingly, Mulberry (and some other email programs) finds this information from the Advanced Options of an entry in File Mappings section of the Internet control panel.

<http://www.cyrusoft.com/mulberry/>

• Musashi: In the Account tab in Musashi's Preferences dialog, you can choose from "Base64 [AppleDouble]," Base64 [AppleSingle]," "Base64 [Data Fork]," BinHex, and uuencode. You can switch formats on a per-message basis in the Options tab within each outgoing message window. Musashi appears to be the only email program that explicitly says that the AppleDouble and AppleSingle binary packaging formats also use the Base64 transfer encoding format. (See the article "Macintosh Internet Format Primer" in TidBITS-445 for details on the distinction.)

<http://db.tidbits.com/article/05066>
<http://www.sonosoft.com/musashi/>

• Netscape Communicator 4.7: You don't have many options with Netscape Communicator; the only control over attachment format is in the third tab down in an outgoing message window. A checkbox labeled "Use uuencode instead of MIME for attachments" lets you toggle between uuencode and something Netscape is calling MIME. In this case, and based on some posts I've seen from Netscape employees, I suspect they're checking the attachment itself to see if it has a resource fork and using AppleDouble plus Base64 if it does, and just Base64 if it doesn't. Netscape loses points for failing to mention anything regarding attachment formats in the online help.

<http://www.netscape.com/computing/download/>

• Outlook Express 5.0: Like Emailer, click the Attachments disclosure triangle in an outgoing message to reveal the attachments pane. You can change the attachment format by clicking the text describing the attachment (it's one of Outlook Express's funny pop-up pseudo-dialog boxes) and then clicking the radio button corresponding to the format you want. Outlook Express 5.0 supports AppleDouble, BinHex, Base64, and uuencode. It can also compress attachments automatically, add Windows extensions to filenames, and optionally not send attachments to people in the Cc and Bcc lines. Outlook Express 5.0 also gets points for clear wording, since its options are labelled with plain English recommendations first, and format names second, as in "Any computer (AppleDouble)," "Macintosh (BinHex)," "Windows (MIME/Base64)," and "UNIX (uuencode)." And, if you attempt to send a file with a resource fork using Base64 or uuencode, Outlook Express warns you that it may be damaged.

<http://www.microsoft.com/mac/oe/>

• PowerMail 2.4v7: CTM Development's PowerMail supports AppleDouble, BinHex, Base64, and uuencode, and lets you set a default in the Encoding screen of the Preferences dialog, plus change the format on a per-message basis within outgoing message windows.

<http://www.ctmdev.com/>

• QuickMail Pro 2.0: Of the email programs mentioned here, QuickMail Pro 2.0 offers the most flexibility in dealing with attachment formats, plus it is the only program to differentiate between binary packaging (called File Format in the Edit Mail Encoding preferences dialog box) and transfer encoding (called Byte Encoding). You can choose among Data Only, AppleDouble, AppleSingle, and BinHex for binary packaging, and separately choose 8-bit (no encoding), Base64, or uuencode for transfer encoding. With these choices, you can create custom encoding settings, so you could define AppleDouble and Base64 as the encoding to use for "Modern Windows" and Data Only plus uuencode for "Old Windows," and so on. That's not all: within QuickMail Pro's address book, you can specify which of your custom encoding settings to use for each person, and if you're sending mail to people who aren't in your address book, you can change the encoding for each recipient of a message. Although this level of flexibility may seem like overkill, it's welcome as long as we have to cope with all of these formats.

<http://www.cesoft.com/quickmail/qmp.html>

Sending It Off -- As much as my head is reeling with all the details I've tried to bring together here, there are bound to be situations that defy logical explanation and everything you try. In those cases, remember that it's generally not your fault, if you're using one of the programs above, and the best course may simply be to encourage your recipient to try reading mail using a modern Internet email program using a true ISP rather than AOL or some standards-flouting LAN-based email package.

Hide full article

READERS LIKE YOU! Support TidBITS with a contribution today!
<http://www.tidbits.com/about/support/contributors.html>
Special thanks this week to John & Nichola Collins, Chris Williams,
John K. Lilley, and Honeymoons By Sunset for their generous support!