Macバイナリ

Macバイナリ

拡張子	.bin
MIMEタイプ	application/macbinary application/x-macbinary
UTI	com.apple.macbinary-archive
マジック ナンバー	なし（III以前） mBIN（III、102バイト目より）

Macバイナリ (MacBinary) はClassic Mac OSのファイルシステム中のファイルを、そのマルチフォーク（データフォークとリソースフォーク）とメタデータ（Finder情報）を全て含んだバイナリファイルにまとめる形式（フォーマット）のひとつ。かつては7ビットテキスト転送用のBinHexと並んでインターネット上でも多用されたが、現在はあまり使われなくなってきている。

概要

Mac OSのファイルシステムでは、一般的なファイルシステムにおける「ファイルの中身」に相当する「データフォーク」の他、リソースフォークという二つのフォークがある。またその他に、生成時刻などが含まれたメタデータであるFinder情報がある。Finder情報にはクリエータとファイルタイプ、Finderフラグ、ウインドウ位置等が含まれている。データフォークがない場合やリソースフォークがない場合(サイズがゼロ)もある。

パソコン通信の時代において、Ward ChristensenによるXMODEMやMODEM7、Kermit、CompuServeでのAやBといったプロトコルで転送する事を仮定していた。日本でもパソコン通信等で多用された。これらには128バイト単位でデータを転送するものがあるため、MacBinaryも128バイト単位で扱えるような工夫がされている。

以下は余談であるが、利用形態としては、送信元の端末がMacBinaryフォーマットで転送し、転送先の端末がそれを展開してローカルのファイルシステムに保存するような方法を想定していた。実際には拡張子.binを付けたMacBinaryフォーマットのファイルに保存し、パソコン通信のサイトに置いたり電子メールで送信する方法も取られた。この場合は受信後に対応ソフトで展開した。

その後、Apple Computer（当時）によるHFSの仕様拡張にあわせて、MacBinary II、MacBinary IIIが公開されている。

現在のmacOSのHFS+ではMacBinary IIIでも不十分であるため、あまり使われなくなっている。

フォーマットの遍歴

最初のMacBinaryは、1985年にMacBinary Working Groupによって公開された。 先頭の128バイト (MacBinary Header) 内にファイル名、Finder情報、ファイル作成時刻、ファイル更新時刻等を詰め込み、その後にデータフォーク、リソースフォークが続くフォーマットである。データフォークとリソースフォークはパディングして128バイト単位で格納する。ファイル名は63バイト迄扱う事が出来たが、当時のClassic Mac OSには31バイト制限があったので必要以上であった。日本語環境ではファイル名はMacJapaneseで保管される。 この時点ではClassic Mac OSのファイルを8ビットで転送するためには十分なフォーマットであった。

7ビット経路でASCIIに変換して転送する方式としてはBinHexがあり、MacBinaryとBinHexのどちらかを使えば十分であった。

MacBinary IIは1987年にMacBinary II Conferenceで合意された。先頭128バイトの未使用だった領域に拡張されたFinderフラグを格納するようにし、更にリソースフォークの後にコメントを追加出来るように改良された。

MacBinary IIIは1997年に発行された。1996年11月にアップルが公開したMac OS 8の拡張Finder情報を先頭128バイトの未使用領域に格納出来るようにしたものである。ファイル名の長さは31バイト以内でなければならないと明確化されたが、これは当時のClassic Mac OSと同じ制限であるため妥当であった。 このとき既にアップルコンピュータによりAppleSingleの仕様が公開されていたが普及に至らなかったため、既に浸透しているMacBinaryを拡張したわけである。

問題点

日本製のMacLHAというアーカイバでは、ファイルをMacBinaryフォーマットにしてからLHA書庫に格納するという手法を取った。これを考慮しないLHA用ソフトで展開した場合、拡張子.binの付かないMacBinaryフォーマットのファイルが出力されてしまう。

MacBinaryフォーマットのファイルは拡張子.binを付けるのが一般的であるため、ユーザはこれを展開することで本来のファイルを得ることが出来る。しかし、拡張子.binを付けず元のファイル名のままで保存されるケースもある。前述のMacLHAもこのケースに当たる。こうした場合、ユーザはMacBinaryである事に気付かず、そのままアプリケーションで開こうとしてしまう。アプリケーションによってはMacBinaryであることを自動判別して先頭128バイトを読み飛ばしてデータフォークのみを読み取るが、通常のアプリケーションではエラーになってしまう。

MacBinaryを解除するソフトウェアが多数あったが、中には先頭128バイトのMacBinary Headerを取り除くだけのものがあった。この処理法だとデータフォークの後のパディングが残っており、更にその後にリソースフォークとコメントも残ったままになるため、正しい処理とは言えない。

データフォークのみを取り出して保存するソフトウェアも多数あった。また、データフォークの他にリソースフォークを別ファイルとして保存するソフトウェアも多数あった。処理方法としてこれらは正しいと言える。しかしながら、元々リソースフォークが重要なファイルであった場合、Classic Mac OS以外のOSでは正常に扱う事が出来ない。これはMacBinaryの問題というよりも、Classic Mac OSと他のOSとの間の互換性の問題と言える。

単にClassic Mac OS間でファイルの交換するという目的では、データフォークのみを取り出す必要はなく、如何にして全ての情報を転送出来るかが問題となる。この意味ではCompact Pro、StuffIt、MacLHAといったアーカイバが有用であった。

MacBinaryではファイル名の長さは63バイト或は31バイト迄表現出来るが、現在のmacOSのHFS+では更に長いファイル名をUnicodeで扱っており、更に多くのメタ情報が追加されているため、たとえ最新のMacBinary IIIでも不十分である。この問題の打開策としては、アップルコンピュータが自ら作ったAppleSingleやAppleDoubleがある。これらはUnicodeファイル名や各種メタデータを取り扱う事が出来る。ただしAppleSingleは単一のファイルなので対応ソフトが必要となる。AppleDoubleはその名前が示す通りClassic Mac OS固有のデータとデータフォークの2つのファイルにわけてやりとりする方法なので、Classic Mac OS以外のOSではデータフォークのみを扱う事が出来る。

現在のmacOSでは、AppleDoubleをtarやzipでアーカイブしたり、HFS+をそのままイメージ化したdmgフォーマット等も使われている。

関連項目

• AppleSingle
• AppleDouble
• BinHex
• リソースフォーク

外部リンク

• MacBinarySpecs - theunarchiver - Mirror of the three MacBinary specs - Project Hosting on Google Code