On Sep 10, 2009, at 1:21 PM, Peter Bunn wrote:
Does Base 64 work uniformly to send to Macs? If so, I'll change the
default in Emailer's prefs.
No... well, sort of... maybe... but not really.
Base64 only encodes the data fork portion of a Mac file. Today, this
is probably more fine then not as Apple has been trying to get rid of
the resource fork for a while. However, since we are talking about a
Classic app, and OS 9 and prior still readily used the resource fork
(although even there, for data files such as a word document, they
weren't all that important), it is possible using only Base64 to send
a Mac file attachment to a Mac user may render the file useless.
AppleDouble may be a better choice. AppleDouble creates two
attachments, both Base64 encoded, one for the data fork one for the
resource fork. Mac software (that knows what AppleDouble is, although
my guess is most Mac mail programs even today may still understand and
support it), will properly decode the file back into a Mac dual forked
file. Windows software that knows what AppleDouble is (there are a
few) will properly throw out the resource fork portion of the file
since Windows can't use that anyway (this will damage a file that
needs it, but then, if it needs it, it can't be used on Windows
anyway). Windows software (and Mac) that doesn't know what AppleDouble
is will simply show two file attachments to the email. One will have a
normal name, one will have the same name but preceded by an underscore
character. The normal named one is the data fork portion and on a file
that doesn't need the resource fork, that is all that is needed. The
underscore named one is the resource fork portion and can be safely
ignored.
So the point to this is, if you use AppleDouble you don't have to
think about if the email is going to a Mac or Windows user as either
will receive the attached file correctly. Beats changing between
Base64 for Windows and BinHex for Mac.
The trade off is, you may get Windows users that get confused as to
what the 2nd attached file is that they can't open. Unfortunately,
that underscore named file is usually the first of the two listed as
the attachments. And for some reason Windows users can't get past
looking at it. They try to open it, it won't open, and rather than
looking at the 2nd file, the one with a correct and normal name, the
one that if they tried to open it, it opens fine... they get hooked on
the underscore one and start complaining the attachment can't be opened.
All that said, if you are only sending OS X files via email, then
there is a good chance you can safely move to Base64 full time as OS X
has really for the most part done away with resource forks in files
(there are some hold outs still, like some AppleScripts, but most have
really stopped using the resource fork allowing it to be safely
omitted when the file is emailed). And if you zip or stuff your
attachments before sending, then the issue is irrelevant as both
formats "flatten" the file, that is, the resulting compressed file is
data fork only and can be safely sent using Base64 where it can be
decompressed on the other end restoring it to its dual fork original
state.
"Service Default" as you leave yours for Mac users will encode using
whatever method is set as your default, or whatever method is required
by the service being used (only relevant for AOL which uses their own
encoding method, all "Internet" service accounts, ie: all regular POP
email accounts as you are using right now will use the default method
set in your prefs when you have "Service Default" as the choice).
-chris
<www.mythtech.net>
___________________________________________________________________________
To unsubscribe send a mail message with a SUBJECT line of "unsubscribe" to
<[email protected]> or <[email protected]>
