Macバイナリ
Macバイナリ (MacBinary) はClassic Mac OSのファイルシステム中のファイルを、そのマルチフォーク（データフォークとリソースフォーク）とメタデータ（Finder情報）を全て含んだバイナリファイルにまとめる形式（フォーマット）のひとつ。かつては7ビットテキスト転送用のBinHexと並んでインターネット上でも多用されたが、現在はあまり使われなくなってきている。
| 拡張子 | .bin |
|---|---|
| MIMEタイプ | application/macbinary application/x-macbinary |
| UTI | com.apple.macbinary-archive |
| マジック ナンバー | なし（III以前） mBIN（III、102バイト目より） |
概要
編集
Mac OSのファイルシステムでは、一般的なファイルシステムにおける﹁ファイルの中身﹂に相当する﹁データフォーク﹂の他、リソースフォークという二つのフォークがある。またその他に、生成時刻などが含まれたメタデータ[注釈1]である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でも不十分であるため、あまり使われなくなっている。
パソコン通信の時代において、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月にAppleが公開したMac OS 8の拡張Finder情報を先頭128バイトの未使用領域に格納出来るようにしたものである。ファイル名の長さは31バイト以内でなければならないと明確化されたが、これは当時のClassic Mac OSと同じ制限であるため妥当であった。
このとき既にApple Computerにより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でも不十分である。この問題の打開策としては、Apple Computerが自ら作ったAppleSingleやAppleDoubleがある。これらはUnicodeファイル名や各種メタデータを取り扱う事が出来る。ただしAppleSingleは単一のファイルなので対応ソフトが必要となる。AppleDoubleはその名前が示す通りClassic Mac OS固有のデータとデータフォークの2つのファイルにわけてやりとりする方法なので、Classic Mac OS以外のOSではデータフォークのみを扱う事が出来る。
現在のmacOSでは、AppleDoubleをtarやzipでアーカイブしたり、HFS+をそのままイメージ化したdmgフォーマット等も使われている。
脚注
編集注釈
編集- ^ マルチフォークと違い、ファイルに関してそのようなメタデータがあることは、他のOSのファイルシステムでも普通のことである。
出典
編集関連項目
編集外部リンク
編集- MacBinarySpecs - theunarchiver - Mirror of the three MacBinary specs - Project Hosting on Google Code
- 通信用語の基礎知識「マックバイナリ」（通信用語の基礎知識 [1]）
 | この項目は、コンピュータに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。 |