リソースフォーク(英: 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が持つリソースデータの開始位置とそのリソースにつけられた名前への位置を記録)
  - リソース名リスト(リソースデータに対して名前でアクセスする際に利用する名前を記録)

## リソースフォークにアクセスする仕組み

リソースフォークへのアクセスは「リソースマネージャ」と呼ばれるプログラムを介して行う。

1. リソースフォークにアクセスされると、ヘッダからリソースデータおよびリソースマップの開始位置や長さなどを読み込む。
2. 読み込むべきリソースタイプが指定されると、リソースタイプリストからそのタイプが存在するかのチェックと、そのタイプが含むデータの個数とリソースマップの開始位置から数えたリソース参照リストへのオフセットを調べる。
3. リソース参照リストから、リソースID、リソース名へのオフセット、リソースの属性、リソースデータの開始位置から数えたデータのオフセットを調べる。
4. 指定されたIDあるいは名前のリソースデータが存在したら、先ほど得たオフセットにアクセスし、データ長を調べ、そこに記録された分だけデータを読み込み、戻り値として返す。

## リソースフォークにおけるデータタイプ

リソースフォークを構成する最小単位のことをデータタイプという。データタイプとは、その名の通りデータの種類 を表すもので、複数種類が存在する。リソースフォークにアクセスした後は、あらかじめ定義しておいたデータタイプ通りに読み込んでいくことで内容を把握できる。データをどのように扱うかはプログラム内部であらかじめ定義しておくことも、TMPLリソースと呼ばれるリソースに記録しておくことも可能である。後者の方法であればResEditなどで見たときにある程度視覚化されるため、後から編集しやすくなる。

### 主なデータタイプ

以下に、主なデータタイプを、アルファベット順に並べ替えて挙げる。
これ以外にも非常に細かくデータタイプが用意されている。

| データタイプ(実際の名前) | 概要 |
| --- | --- |
| BBIT(バイナリビット) | 真偽値(真か偽か)を1ビットで表す。常に8の倍数個のBBITが必要。 |
| BOOL(ブーリアン) | 真偽値を表す。2バイトで構成され、256が真、0が偽。 |
| CHAR(キャラクタ) | 1バイトの文字を表す。 |
| CSTR(Cストリング) | C言語の文字列と同じ文字列を表す。 |
| DLNG(10進ロングワード整数) | 10進数のロングワード(4バイト)整数。およそ-21億〜21億までの整数を表す。 |
| HEXD(16進数ダンプ) | このタイプが現れた位置から末尾までを16進数で表す。コードリソースや圧縮されたデータなどを表す際に用いられる。 |
| HLNG(ロングワード16進数) | データを4バイト分の16進数値として扱う。C言語でいうunsigned longで21億以上の整数を表した場合などに用いられる。 |
| PSTR(Pascalストリング) | 最初の1バイトに文字列の長さを記録したPascalストリングを表す。 |
| TNAM(タイプ名) | 常に4バイトで構成される、クリエータコードなどを表す文字列(内部的には数値として扱う)。 |
| RECT(矩形) | 矩形の各辺の座標を表す。常に8バイトで構成される。 |

### 主なリソースタイプ

名前はすべて半角4文字で表される。"snd "や"STR "など、見た目が3文字のリソースタイプ名は、最後に半角スペースを要する。

| リソースタイプの名前(実際の名前) | 概要 |
| --- | --- |
| ALRT(アラート) | アプリケーションのアラートボックスの形状を定義する |
| APPL(アプリケーション) | アプリケーションの情報を格納する |
| BNDL(バンドル) | アプリケーションで扱えるファイルタイプのアイコンなどを定義する |
| cicn(カラーアイコン) | データで利用するカラーアイコンを定義する |
| clut(カラーパレット) | データで利用する色を定義する |
| CNTL(コントロール) | ウィンドウに配置する部品の詳細を定義する |
| CODE(コードリソース) | プログラムの機械語を格納する |
| CURS(カーソル) | モノクロのカーソルの形状を定義する |
| DITL(ダイアログアイテムリスト) | ウィンドウの部品を定義する |
| DLOG(ダイアログ) | アプリケーションのダイアログボックスの形状を定義する |
| FREF(ファイル参照) | アプリケーションで扱えるファイルタイプを定義する |
| hfdr(アイコンバルーンヘルプ) | Finderで、ファイルにカーソルを重ねた際に表示させるバルーンヘルプの内容や形式の定義 |
| icl8(8ビットアイコンリスト) | Finderで表示するアイコンを定義する |
| icns(32ビットアイコンリスト) | Finderで表示する大型アイコンを定義する |
| ICON(アイコン) | データで利用するモノクロアイコンを定義する |
| kind(ファイル概要) | ファイルタイプの概要を定義する |
| MBAR(メニューバー) | アプリケーションのメニューバーとメニューを定義する |
| MDEF(メニュー定義) | アプリケーションのメニューを定義する。カラーパレットのような複雑な形状のメニューも定義できる |
| MENU(メニュー) | アプリケーションのメニュー項目を定義する |
| MooV(ムービー) | QuickTimeムービーを格納する |
| open(オープン) | アプリケーションが開けるファイルタイプを定義する |
| PICT(ピクチャ) | ファイルに含まれているPICT画像を格納する |
| PREF(プレファレンス) | アプリケーションの環境設定を記録する |
| snd (サウンド) | ファイルで利用するサウンドを格納する |
| STR (文字列) | ファイルで利用する文字列と16進データを格納する |
| STR#(文字列リスト) | ファイルで利用する文字列を複数格納する |
| styl(スタイル) | テキストの書体や文字の色、大きさといったスタイル情報を定義する |
| TEXT(テキスト) | テキストを格納する |
| TMPL(テンプレート) | リソースデータのフォーマットを定義する |
| vers(バージョン) | そのファイルのバージョンや使用する地域を定義する |
| WDEF(ウィンドウ定義) | アプリケーションのウィンドウを定義する。不定形ウィンドウなども定義できる |
| WIND(ウィンドウ) | アプリケーションのウィンドウの形状を定義する |

## リソースフォークの転送及び保存

リソースフォークはファイル本体とは別の情報であるため、別の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ではファイルに拡張子を付けることが推奨されているが、プロパティリストを使って、ユーザがなるべく拡張子を意識することがないように工夫されている。