Macバイナリ
テンプレート:Infobox file format Macバイナリ (MacBinary) はMac OSのファイルを電話回線等でバイナリ転送プロトコルを使って転送するためのフォーマット。かつては7ビットテキスト転送用のBinHexと並んでインターネット上でも多用されたが、現在はあまり使われなくなってきている。
概要
初期のMac OSでは、1つのファイルがデータフォークとリソースフォークという二つのフォークで構成されており、それ以外のメタデータとしてFinder情報やファイル時刻があった。Finder情報にはクリエータとファイルタイプ、Finderフラグ、ウインドウ位置等が含まれている。データフォークがない場合やリソースフォークがない場合(サイズがゼロ)もある。
当時の他のOSではマルチフォーク（マルチデータストリーム、代替データストリーム）の概念がなかったため、電話回線等でファイルを送ろうとするとデータフォーク以外が欠落してしまう。そのままでも問題とならないことはあるが、リソースフォークやクリエータ、ファイルタイプが重要な場合はファイルが壊れていることになる。
そこでこの問題の対策として、1つにまとめて転送するMacBinaryが考案された。 当時はWard ChristensenによるXMODEMやMODEM7、Kermit、CompuServeでのAやBといったプロトコルで転送する事を仮定していた。日本でもパソコン通信等で多用された。これらには128バイト単位でデータを転送するものがあるため、MacBinaryも128バイト単位で扱えるような工夫がされている。
利用形態としては、送信元の端末がMacBinaryフォーマットで転送し、転送先の端末がそれを展開してローカルのファイルシステムに保存するような方法を想定していた。実際には拡張子.binを付けたMacBinaryフォーマットのファイルに保存し、パソコン通信のサイトに置いたり電子メールで送信する方法も取られた。この場合は受信後に対応ソフトで展開した。
その後、アップルコンピュータ（当時）によるHFSの仕様拡張にあわせて、MacBinary II、MacBinary IIIが公開されている。
現在のMac OS XのHFS+ではMacBinary IIIでも不十分であるため、あまり使われなくなっている。
フォーマットの遍歴
最初のMacBinaryは、1985年にMacBinary Working Groupによって公開された。 先頭の128バイト(MacBinary Header)内にファイル名、Finder情報、ファイル作成時刻、ファイル更新時刻等を詰め込み、その後にデータフォーク、リソースフォークが続くフォーマットである。データフォークとリソースフォークはパディングして128バイト単位で格納する。ファイル名は63バイト迄扱う事が出来たが、当時のMac OSには31バイト制限があったので必要以上であった。日本語環境ではファイル名はMacJapaneseで保管される。 この時点ではMac OSのファイルを8ビットで転送するためには十分なフォーマットであった。
7ビット経路でASCIIに変換して転送する方式としてはBinHexがあり、MacBinaryとBinHexのどちらかを使えば十分であった。
MacBinary IIは1987年にMacBinary II Conferenceで合意された。先頭128バイトの未使用だった領域に拡張されたFinderフラグを格納するようにし、更にリソースフォークの後にコメントを追加出来るように改良された。
MacBinary IIIは1997年に発行された。1996年11月にAppleが公開したMac OS 8の拡張Finder情報を先頭128バイトの未使用領域に格納出来るようにしたものである。ファイル名の長さは31バイト以内でなければならないと明確化されたが、これは当時のMac OSと同じ制限であるため妥当であった。 このとき既にアップルコンピュータによりAppleSingleの仕様が公開されていたが普及に至らなかったため、既に浸透しているMacBinaryを拡張したわけである。
問題点
日本製のMacLHAというアーカイバでは、ファイルをMacBinaryフォーマットにしてからLHA書庫に格納するという手法を取った。これを考慮しないLHA用ソフトで展開した場合、拡張子.binの付かないMacBinaryフォーマットのファイルが出力されてしまう。
MacBinaryフォーマットのファイルは拡張子.binを付けるのが一般的であるため、ユーザはこれを展開することで本来のファイルを得ることが出来る。しかし、拡張子.binを付けず元のファイル名のままで保存されるケースもある。前述のMacLHAもこのケースに当たる。こうした場合、ユーザはMacBinaryである事に気付かず、そのままアプリケーションで開こうとしてしまう。アプリケーションによってはMacBinaryであることを自動判別して先頭128バイトを読み飛ばしてデータフォークのみを読み取るが、通常のアプリケーションではエラーになってしまう。
MacBinaryを解除するソフトウェアが多数あったが、中には先頭128バイトのMacBinary Headerを取り除くだけのものがあった。この処理法だとデータフォークの後のパディングが残っており、更にその後にリソースフォークとコメントも残ったままになるため、正しい処理とは言えない。
データフォークのみを取り出して保存するソフトウェアも多数あった。また、データフォークの他にリソースフォークを別ファイルとして保存するソフトウェアも多数あった。処理方法としてこれらは正しいと言える。しかしながら、元々リソースフォークが重要なファイルであった場合、Mac OS以外のOSでは正常に扱う事が出来ない。これはMacBinaryの問題というよりも、Mac OSと他のOSとの間の互換性の問題と言える。
単にMac OS間でファイルの交換するという目的では、データフォークのみを取り出す必要はなく、如何にして全ての情報を転送出来るかが問題となる。この意味ではCompact Pro、StuffIt、MacLHAといったアーカイバが有用であった。
MacBinaryではファイル名の長さは63バイト或は31バイト迄表現出来るが、現在のMac OS XのHFS+では更に長いファイル名をUnicodeで扱っており、更に多くのメタ情報が追加されているため、たとえ最新のMacBinary IIIでも不十分である。この問題の打開策としては、アップルコンピュータが自ら作ったAppleSingleやAppleDoubleがある。これらはUnicodeファイル名や各種メタデータを取り扱う事が出来る。ただしAppleSingleは単一のファイルなので対応ソフトが必要となる。AppleDoubleはその名前が示す通りMac OS固有のデータとデータフォークの2つのファイルにわけてやりとりする方法なので、Mac OS以外のOSではデータフォークのみを扱う事が出来る。
現在のMac OS Xでは、AppleDoubleをtarやzipでアーカイブしたり、HFS+をそのままイメージ化したdmgフォーマット等も使われている。
