リソースフォーク
リソースフォーク(resource fork)は、Classic Mac OS特有のの構造であり、実際のデータを表すデータフォークとは別に、アイコンやウィンドウの形状、メニューの内容や定義、古くはアプリケーションコード(機械語)などといった、フォーマットがある程度定型化された情報を持つ。また、情報そのもののことをとくに「リソースデータ」という。リソースフォークの存在によりデータにさまざまな付加情報を簡単に記録することができる。これに対して、実際のデータ部をとくに「データフォーク」と呼ぶ。データフォークは、Windowsにおけるメインデータストリームなど、Classic Mac OS以外のオペレーティングシステム (OS) でデータを記録する部分と同じである。Windowsにも似た機能を持つリソースという概念はあるが、Classic Mac OSのそれとは異質のものである。
Classic Mac OSではこの他にもFinder情報と呼ばれるメタデータがある。現在のmacOSではリソースフォークとFinder情報を拡張属性 (EA) として扱うようになった。
リソースフォークはHFSやHFS+と呼ばれるやAFPと呼ばれるプロトコルだけがサポートしている。これらのファイルシステムやファイル共有プロトコルは現在のところClassic Mac OSだけがサポートしているため、事実上Classic Mac OSだけの機能になっている。一方、Classic Mac OSはUFSと呼ばれるファイルシステムにインストールして使用することもできる。この場合、リソースフォークを実際のデータとは別のファイルに分離することにより管理している。
現在のMac OSで最も利用されているHFS+では、データフォークとリソースフォーク以外のフォークも扱えるように設計されており(マルチフォーク)、macOS(v10.3以降)では、マルチフォークの機能を利用して、ファイルに拡張属性を付加したり、アクセス制御リストによるセキュリティ機能が提供されている。
Windows NT以降で採用されたファイルシステムであるNTFSでは、代替データストリームが利用出来るため、これを用いてリソースフォークを保存する事が出来る。SFM (Service for Macintosh) を使ってClassic Mac OSからWindowsにファイルを転送した場合、これが利用される。
リソースフォークはResEditなどのリソースエディタと呼ばれる部類のエディタで編集することが出来るため、ソフトウェアのローカライズやカスタマイズが行える。また、大抵のリソースエディタは視覚的にデータを編集できる。また、Appleが無償で提供する統合開発環境、Macintosh Programmer's Workshop (MPW) やApple Developers ToolsにはRezと呼ばれるコンパイラが存在し、Rez専用の言語(これもRezと呼ばれる)で記述されたソースコードをコンパイルすることでリソースフォークを作成することも出来る。逆に、リソースフォークからRezコードに戻すための逆コンパイラ、DeRezも同梱されている。
ただし、リソースフォークの編集は、場合によってはファイルを破壊しかねないので、構造を理解したうえで、自己責任で行う必要がある。
リソースフォークの構造は、リソースデータの配置を記録する「リソースマップ」と呼ばれるデータがあり、これによりリソースデータに定義されたIDや名前によってランダムアクセスを容易にしている。それとは別に実際のデータとなるリソースデータが記録され、大まかに分けてこの二つで構成されているが、実際には一つのタイプに複数のデータを記録できる階層構造になっている。リソースデータは、記録する情報の種類によって情報の記録形式が定義されており、その種類のことを「リソースタイプ」という。なお、リソースタイプは自分で自由に定義できる。また、リソースデータは他のタイプのデータを参照していることがよくある。
ヘッダ(リソースデータおよびリソースマップの開始位置や長さなどを記録)
リソースデータ(実際のデータ。データの先頭4バイトにデータ長を記録している。データごとに複数個存在する)
リソースマップ(リソースデータがどこに記録されているかなどを記録。内部は以下のようになっている)
リソースタイプリスト(どのようなリソースタイプが使用されているかなどを記録)
リソース参照リスト(指定IDが持つリソースデータの開始位置とそのリソースにつけられた名前への位置を記録)
リソース名リスト(リソースデータに対して名前でアクセスする際に利用する名前を記録)
リソースフォークへのアクセスは「リソースマネージャ」と呼ばれるプログラムを介して行う。
リソースフォークにアクセスされると、ヘッダからリソースデータおよびリソースマップの開始位置や長さなどを読み込む。
読み込むべきリソースタイプが指定されると、リソースタイプリストからそのタイプが存在するかのチェックと、そのタイプが含むデータの個数とリソースマップの開始位置から数えたリソース参照リストへのオフセットを調べる。
リソース参照リストから、リソースID、リソース名へのオフセット、リソースの属性、リソースデータの開始位置から数えたデータのオフセットを調べる。
指定されたIDあるいは名前のリソースデータが存在したら、先ほど得たオフセットにアクセスし、データ長を調べ、そこに記録された分だけデータを読み込み、戻り値として返す。
リソースフォークを構成する最小単位のことをデータタイプという。データタイプとは、その名の通りデータの種類 を表すもので、複数種類が存在する。リソースフォークにアクセスした後は、あらかじめ定義しておいたデータタイプ通りに読み込んでいくことで内容を把握できる。データをどのように扱うかはプログラム内部であらかじめ定義しておくことも、TMPLリソースと呼ばれるリソースに記録しておくことも可能である。後者の方法であればResEditなどで見たときにある程度視覚化されるため、後から編集しやすくなる。
以下に、主なデータタイプを、アルファベット順に並べ替えて挙げる。
これ以外にも非常に細かくデータタイプが用意されている。
名前はすべて半角4文字で表される。"snd "や"STR "など、見た目が3文字のリソースタイプ名は、最後に半角スペースを要する。
ResEdit(レスエディット)
Appleが無償で配布している。一般的なリソースデータを視覚的に編集できる。構造がわかれば、さまざまなリソースデータを視覚化できる。
Resorcerer(リソースラ)
高価ながらも、ResEdit以上に多くのリソースデータを視覚的に編集できるため人気は高い。
HexEdit(ヘックスエディット)
一般に言うバイナリエディタで、実際はリソースフォークよりもデータフォークの編集に多く使われる。
リソースフォークはファイル本体とは別の情報であるため、別のOSに転送したり、HFSやHFS+以外のファイルシステムに保存する場合などは手当てが必要である(これはClassic Mac OSに特有な話といったものではなく、どんなOSの場合でも、ファイル本体とは別になっている情報(たとえばそのファイルの最終変更時刻など、といった情報など)については配慮が必要である)。
リソースフォークを使用している古いClassicアプリケーションを配布したり、サムネイルアイコンの付いた画像を転送するには、MacBinary、BinHex、AppleSingle、AppleDoubleといったフォーマットを用いる必要がある。またこういったフォーマットではほぼ全てがリソースフォークだけではなくFinder情報も扱う。
実際にはアーカイブファイルに纏めたり、ディスクイメージとして配布する方法が浸透した。これらの方法では複数のファイルを1つに纏める事が出来るし、エイリアスも扱う事が出来る。更にデータの圧縮が可能であるという利点もある。
圧縮アーカイブとしては、Compact ProやStuffItが利用された。MacLHAではMacBinaryにしてからLHAアーカイブに格納する手法が取られた。ディスクイメージとしてはIMGフォーマットが利用された。
現在のmacOSでは、Appleがzip形式やtar形式を拡張してリソースフォークやその他のメタデータを保存出来るようにしている。これはAppleDoubleフォーマットを用い、データフォーク (AppleDouble Data file) とそれ以外のメタデータ (AppleDouble Header file) に分けてアーカイブに格納する手法である。また、DMGと呼ばれる新たなディスクイメージも採用している。
インターネットが浸透した現在、ほかのOSのユーザとファイルを共有することが当たり前になってくると、リソースフォークの存在によりほかのOSのユーザを困惑させることがたびたび起こるようになってしまった。そこでmacOSでは、リソースフォークの使用を極力控えることになった。これによりほかのOSでリソースフォークが邪魔することがなくなり、ファイル共有も容易になった。一方で、リソースフォークの代替としてバンドルと呼ばれる、フォルダ階層の中に、リソースフォークにあたるデータをデータフォーク側に格納するようにもした。定型化された情報が多いアプリケーションでとくに多用されている。
こういった改良のおかげでファイル共有が容易になったばかりでなく、リソースフォークのないUNIXのソフトウェアも簡単に移植できるようになった。
macOSではファイルに拡張子を付けることが推奨されているが、プロパティリストを使って、ユーザがなるべく拡張子を意識することがないように工夫されている。