MacBinary
別名:Macバイナリ
MacBinaryとは、Mac OSにおいて、ファイルを転送するなどの用途に用いられるMac OS独自のバイナリ形式のファイルのことである。
初期のMac OSのファイルは、リソースフォーク、データフォーク、ヘッダと呼ばれる3つの部分で構成されていた。パソコン通信などで、WindowsやUNIXといった他のOSとMac OSのファイルをやり取りした場合、データフォーク以外の情報が失われる場合があった。MacBinaryでは、リソースフォーク、データフォーク、ヘッダの3つを一つにまとめて扱うことで、一般的な形式でファイルを転送しても情報が失われることがないようにされている。
MacBinaryは、後にMacBinary II、MacBinary IIIと拡張版が開発されている。今日では、ファイルシステムが拡張され、Mac OS XもUNIXを土台として開発されたなどの理由から、別のファイル形式が用いられることが多く、MacBinaryが使われる機会は少なくなっている
Macintosh: | 機能拡張 コントロールパネル LED Cinema Display MacBinary Macintosh Mac OS Mac OS Web共有 |
Macバイナリ
(MacBinary から転送)
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/06/19 02:05 UTC 版)
ナビゲーションに移動 検索に移動この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。2018年2月) ( |
拡張子 | .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のファイルシステムでは、一般的なファイルシステムにおける「ファイルの中身」に相当する「データフォーク」の他、リソースフォークという二つのフォークがある。またその他に、生成時刻などが含まれたメタデータ[注釈 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でも不十分であるため、あまり使われなくなっている。
フォーマットの遍歴
最初の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のファイルシステムでも普通のことである。
出典
関連項目
外部リンク
- MacBinaryのページへのリンク