Each file on a Macintosh OS has two components, a "data fork",
containing application specific data, and a separately stored user inaccessible
"resource fork" containing creation information, file comments, and most
importantly the application association information. Although this structure is efficient
and effective, it is not compatible with the Internet. Since both components are required
for operation, both components must be included when transferring files across the
Internet. Therefore, numerous methodologies of creating a "unified" file have
arisen into existence. In all cases, files must first be encoded. Encoding a file creates
this "unified" file consisting of the "resource fork" appended to the
"data fork". Once encoded the file is suitable for transmission over the
Internet. Please note: Compressed files must also be encoded prior to transferring
across the Internet.
The following methodologies are used for encoding: MacBinary, BinHex, UUencoding, and
Base64. When transferring files via email attachments from a Mac to a Mac, BinHex is the
clear choice. BinHex (.hqx), which stands for binary hexadecimal, converts the Macs 8-bit
"resource fork" "data forks" into one 7-bit file. If transferring via
browser or FTP client, you also can use MacBinary (.bin), which creates a smaller file
than BinHexing. MacBinary, however, is not for email attachments because it creates an
8-bit file, which, unlike a 7-bit file, has problems in the email gateways and can become
corrupted.
When sending files from Mac to Windows there are two common choices. Base64 seems to be
on its way to becoming the standard. Its useful for all Internet transfer and seems to
create the smallest file. The other option is UUencoding (.UU). As with other encoding,
both convert 8-bit files to 7-bit. However, neither is great when it comes to the Macs two
forks. Base64 may be your best choice, but its rather new and not all programs may
implement it the same. UUencoding definitely works with only the Macs data fork, losing
any information that may be stored in the resource fork. This is not always a problem
since not all files use the resource fork for critical information. For example,
youre OK with MS Word 97/98 or JPG files as well as with text files that
dont contain formatting. Applications arent candidates for this, but you
wouldnt send Mac programs to non-Mac users anyway. The best advice is to send a file
as a test to see if it will arrive intact.
Other encoding methods can convert both forks of a Mac file into one 8-bit file, then
uses Base64 encoding to convert that file to a 7-bit file. This is recommended as the best
format if youre sending files to a user whose mail client supports multipurpose
Internet mail extensions (MIME), as most do. MIME actually is not encoding but a mapping
scheme that lets you assign file types to appropriate applications for processing.
Netscape and other web Browsers have no built in file decompression or decoding
capabilities and rely on 'helper applications', such as MIME, to handle ALL file decoding
and decompression. The best Mac utility is Stuff-It Expander for decoding and
decompressing such files. This must be setup in your browser in order to do this upon
downloading.
Obtaining Stuff-It, or other decoding utilities, from the Internet presents a chicken
and the egg paradox. The decoding utilities would have to be encoded before transmitting
over the Internet, and you would need a decoding utility to decode the download. Email
clients that have been installed may have this decoding capability. Stuff-it is also
bundled with the Netscape Navigator, to beat this dilemma. Self-extracting files still
have a "resource fork" associated with them and they still need to be encoded
prior to transmission.