昔のMacintoshの仕組み2 リソースとファイルタイプ

一般的なコンピューターのファイルと言うものは、ファイル名で検索される単一データの塊である。「ファイル」の「中身」は当然一つであった。"readme.txt"というファイルはテキストファイルであり、その中身はユーザーに読んでもらうためのテキストであるのが当たり前と思うだろう。

 

ところがMacにおいてファイルと言うものは2つの「中身」からなっていた。あるファイル名で示されるファイルには2つの「中身」があった。それはデータフォークとリソースフォークである。データフォークは通常のデータであり、他のコンピューターでいう「ファイルの中身」である。一方リソースフォークには整理された任意の、様々な情報を格納できた。ファイルマネージャーがファイルのデータフォークを読み書きする。これは他のOSにおける基本的なファイルI/Oとだいたい同じで、オープンし、頭から読み書きし、あるいは任意のバイト数までシークし、クローズする。一方同じファイルをリソースマネージャーを通じてアクセスすると、4バイトのリソースタイプと、整数のリソースIDで管理されるデータの塊にアクセすることが出来た。リソースはバイト数での位置などを考慮することなく、様々なデータ、画像や文字の属性、アイコンなどといったものを名前で格納することができた。つまりリソースはもう一つのファイルシステムのように扱えたのだ。

 

アプリケーション・プログラムの実行コードはCODEリソースとして格納されていたし、アプリケーションや書類のアイコンはICONリソースだった。スプラッシュスクリーンに表示される画像などは「PICT」リソースとして格納されていた。

 

Macにおいてアプリケーションや書類のアイコンは、アプリケーションファイルのリソースフォークに収められていた。アプリケーションバイナリの収録されたフロッピーディスクMacに挿入すればマウントされているハードディスクなどの上にある「デスクトップファイル」もしくは「デスクトップデータベース」に「アプリケーションのアイコン」「そのアプリケーションで作成される書類のアイコン」「アプリケーションと書類の関係」がコピーされ、自動的に書類のアイコンも更新された。なのでファイルの関連付けを行うインストーラは不要で、アプリケーションファイルをハードディスクにコピーするだけでOKだったのだ。

昔のMacintoshにおいて、拡張子というものはなかった。書類の種類を示す情報はファイルのメタ情報である「ファイルタイプ」に収められていた。テキストファイルのファイルタイプは「TEXT」であり、アプリケーションファイルのファイルタイプは「APPL」と決められていた。デスクトップでアイコンをダブルクリックすると、ファインダーがそのファイルのタイプがなんであるかを調べ、「APPL」であれば実行ファイルとしてメモリに読み込み実行する。「TEXT」であれば、デスクトップデータベースを検索してテキストファイルを扱えるアプリケーションを探し、それを実行する。

 

このとき、テキストファイルを扱えるアプリケーションが複数あったらどうしたらいいのだろう。その場合、ファイルに付けられたもう一つのメタデータ「クリエイター」を調べる。「クリエイター」は、そのファイルを作成したアプリケーションのID情報である。すべてのアプリケーションは「クリエイター」をもち、それらは重なってはいけないものとされていた。たとえばPhotoshopのクリエイターコードは「8BIM」だった。なお、Photoshopが作成するPSDファイルのファイルタイプは「8BPS」である。クリエイターコードは、アプリケーションを開発したらAppleに登録する必要があった。ファイル保存時には、ファイルタイプと自分自身のクリエイターをメタデータに保存する。

 

なので、基本的にファイルをダブルクリックすれば、前回それを編集したアプリケーションが立ちあがって、それを開くことになっていた。

 

このような、複数の中身を持ち、ファイルタイプやクリエイターと言うメタデータを持つファイルはパソコン通信やインターネットでは扱いにくかった。Macにおいては当然保持すべき情報だが、他機種では無意味である。Mac拡張子を使わない文化だった(拡張子にあたる情報がファイルタイプだった)ため、ファイル名にいちいち「.txt」だの「.psd」だの付ける必要がなかった。ネットワークでファイルをやり取りする際にもメタデータやリソースフォークを保持するようにした。これがMacBinaryである。メタデータやリソースフォーク、データフォークをシリアル化して送受信する仕組みで、本来通信ソフトが勝手にエンコード、デコードすることを想定したものだった。つまりMacから送信時自動的にMacBinaryにエンコードされ、別のMacで受信する際Macファイルシステムに会うようにデコードされるはずだった。ところが、ただのJPEGGIFファイルみたいな汎用データにもメタデータがついてしまうため、これを他機種でダウンロードすると表示できないということになった。汎用の通信に出す場合MacBinaryエンコードせずに送信するなどの工夫が必要だったのだが、Mac初心者がよくわからないままMacBinaryデータをばらまき、他機種ユーザーに蛇蝎の如く嫌われることになったのだった。