So what is MacBinary and why is important? You have to handle MacBinary to allow uploads from most Macintosh browsers. Many other upload components claim to be able to support MacBinary but their support consists of stripping out what they consider relevant and then throwing away everything else.
So how come we're 120% MacBinary compatible? Well we're the only people to use all the information available. If you upload a Macintosh file to a server running Services for Macintosh (SFM) your Mac file will appear just like it left your client - icons, previews and file name completely intact. We're the only people to do this so we gave ourselves an extra 10%. Additionally while we were doing this we discovered that Internet Explorer sometimes incorrectly codes the MacBinary so we had to read the incorrect file. As this happens about 10% of the time we gave ourselves another 10%. ABCUpload - 120% MacBinary compatible.
So let's be more specific...
Macintosh files are different from Windows or Unix files in three main ways:
- Every file consists of two separate streams or forks. The data fork holds the basic file information that you would find in a Windows file. The resource fork contains a database of other associated information such as picture previews, notes and icons. So a BMP image might contain the BMP in the data fork and a icon, preview and copyright note in the resource fork.
- Macintosh files do not contain a file type extension. Instead they have a hidden type and creator code.
- Macintosh file names can contain almost any character except for the colon character. This means that it is common to have Macintosh files containing slashes, question marks and asterisks.
When Internet Explorer uploads a file from a Macintosh it chooses to put all this information together into one big stream encoded as MacBinary. You can just rip out the data fork and this is what most MacBinary compatible upload components do. However if you do this you loose all sense of what type of file was uploaded (remember it won't have a file name extension) and any other associated information. In particular some types of files such as EPSFs and QuickTime movies can be completely destroyed by this process.
At a basic level we use the creator and type properties to infer the file type. Then we took this one step further. Microsoft has given us the ability to handle this kind of file completely correctly. So if you use ABCUpload to save a MacBinary file to an NTFS formatted disk you can maintain complete integrity of data fork, resource fork, file type and creator. If you look at such a file from Windows it will look like a standard file (e.g. JPEG, DOC etc.) but if you serve this file to Macintosh users using Services for Macintosh (SFM) they will see the original file completely intact.