リソースフォーク

リソースフォークは、Appleのクラシック Mac OSオペレーティング システム上のファイルのフォークで、構造化データを保存するために使用されます。これは、オペレーティング システムが非構造化データとして扱うデータを保存するデータ フォークとともに、ファイルの 2 つのフォークの 1 つです。リソース フォーク機能は、互換性のために最新のmacOSに引き継がれています。

リソース フォークには、アイコン ビットマップ、ウィンドウの形状、メニューの定義とその内容、アプリケーション コード (マシン コード) などの詳細を含む特定の形式で情報が保存されます。たとえば、ワード プロセッサ ファイルでは、テキストをデータ フォークに保存し、埋め込まれたイメージを同じファイルのリソース フォークに保存する場合があります。リソース フォークは主に実行可能ファイルで使用されますが、どのファイルにもリソース フォークを含めることができます。

1986年の技術ノートで、Appleは開発者に対し、ファイルのリソースフォークに一般的なデータを入れないように強く推奨した。Appleによると、システムソフトウェアの一部は、有効なリソースマネージャ情報のみを含むリソースフォークに依存しているという。^[1]

リソース フォークは、Apple のプログラマーであるBruce Hornによって考案され、実装されました。

従来の Macintosh ファイル システムでは、リソース フォークには 3 つの目的があります。

• すべてのグラフィック データは、必要になるまでディスク上に保存され、必要なときに取り出され、画面に描画されてから破棄されます。この仮想メモリのソフトウェア バリアントにより、メモリ要件がLisaの 1 MB からMacintosh の 128 KB に削減されます。^{[引用が必要]}
• すべての画像とテキストがリソース フォークに別々に保存されるため、プログラマー以外のユーザーでも国際化とローカリゼーションを実行できます。
• これを使用すると、アプリケーションのほぼすべてのコンポーネントを 1 つのファイルに配布できるため、混乱が減り、アプリケーションのインストールと削除が簡単になります。

リソース フォークは、クラシック Mac OSのシステム ドライブに使用されるすべてのファイル システム( MFS、HFS、HFS Plus ) と、macOS専用のAPFSに実装されています。リソース フォークが存在すると、そのファイルに対してデスクトップに表示されるアイコンなど、さまざまな追加情報を簡単に保存できます 。データ フォークではその中の任意のオフセットにランダムにアクセスできますが、リソース フォークへのアクセスは、データベースから構造化レコードを抽出するような動作をします。( Microsoft Windowsにも「リソース」の概念がありますが、これらは Mac OS のリソースとはまったく関係ありません。)

Macintosh ファイル システムは、作成および変更のタイムスタンプ、ファイルの種類と作成者コード、フォークの長さなど、データ フォークまたはリソース フォークとは異なる メタデータを保存します。

一部のファイルにはリソース フォークしかありません。1 つの例は、クラシック Mac OS のフォント ファイルです。もう 1 つの例は、実行可能コードも 'CODE' タイプのリソースに含まれているクラシック68kアプリケーションです。後のPowerPCバイナリでは、実行可能コードはデータ フォークに格納されました。

リソース フォークは、MFS、HFS、HFS Plus、APFS などの Macintosh ファイル システムでのみサポートされていたため、他のオペレーティング システムのファイル システムにコピーすることはできませんでした。Mac BinHexおよびMacBinary形式は、システム間で転送できるように、リソース フォークとデータ フォークを 1 つのファイルにエンコードするために考案されました。A /UX は、AppleSingle および AppleDouble 形式を介して Unix ファイル システム上のリソース フォークをサポートしていました。Mac OS X Tiger以降、Windows SMB共有や FAT32 ( File Allocation Table ) ボリューム などのファイル システムにリソース フォークを保存するために AppleDouble が使用されました。

HFS Plusファイルシステムでは、データフォークとリソースフォークに加えて他のフォークを許可する設定を行って、「マルチフォーク」アプリケーションを作成することができます。^[2]

2002年8月7日現在、Appleは開発者に対し、Mac OS X上のMach-Oバイナリのリソースフォークにリソースを組み込まないよう推奨している^。[3]

各リソースには、OSType識別子 (4 バイト値)、ID (符号付き16 ビットワード)、およびオプションの名前があります。ダイアログ ボックス( DITL)、イメージ ( PICT)、サウンド ( snd )、および実行可能バイナリ ( ) の標準化されたリソース タイプがあり、これらは、 PowerPCプロセッサCODEが登場するまで、例外なくリソース フォークに格納されていました。ウィンドウをレンダリングするためのサブルーチンは、独自のタイプのリソース ( ) に格納され、メニューをレンダリングするためのサブルーチンは、独自のタイプのリソース ( ) に格納されます。この配置により、ユーザーは、ResEditなどのツールを使用してアプリケーション ファイルまたはシステム ファイルのリソースを変更することで、 個々のアプリケーションだけでなくオペレーティング システム自体も簡単にカスタマイズできるようになりました。 WDEFMDEF

アプリケーションまたは他のコード内では、リソース フォーク内の格納方法や格納場所に関係なく、リソースの種類、ID、または名前の組み合わせを使用するだけでリソースを読み込むことができます。クライアントには、読み込まれたリソースへのハンドルが返され、他のヒープベースのデータと同様にアクセスできます。これを実現する OS コンポーネントがリソース マネージャーです。リソース マネージャーは、データからデータ ストレージの詳細を抽象化するだけでなく、開いているリソース フォークのセットをスタックに配置し、最後に開いたファイルを一番上に配置します。リソースを読み込むときは、最初にスタックの一番上 (おそらく現在のドキュメントのリソース フォーク) を調べ、次に次の下 (アプリケーションのリソース フォーク)、さらに次の下 (システム リソース フォーク) を調べます。この配置は非常に強力で、ローカル リソースで下位のグローバル リソースをオーバーライドできるため、たとえば、アプリケーションは標準のシステム アイコンやフォントの代わりに独自のアイコンやフォントを提供できます。また、アプリケーションは、リソースがどこにどのように保存されているかに関係なく、他のリソースと同じ API を使用してシステムからリソースをロードできます。アプリケーションにとって、すべてのリソースは同じように利用可能で、簡単に使用できます。システムは、これに起因するリソースの競合を回避するために、特定の範囲のリソース ID を予約します。リソース マネージャー API を使用すると、プログラマーはスタックを操作して検索動作を変更できます。

リソースフォークはResEditなどのリソースエディタで編集できるため、ソフトウェアのローカライズやカスタマイズに利用できる。また、ほとんどのリソースエディタではデータを視覚的に編集できる。macOSでは、アプリケーションの開発時にリソースを利用することが可能である。ただし、アプリケーションをUFSで利用する必要がある場合は、 Raw Resource File設定^[要出典]を使用して、リソースフォーク全体をデータフォークに移動するように設定することもできる。Apple社が無償で配布している統合開発環境、たとえばMPWやApple Developer's Toolsには、 Rezと呼ばれるコンパイラが含まれている。これは、Rezと呼ばれる専用の言語を使用し、ソースコードをコンパイルすることでリソースフォークを作成することができる。リソースフォークをRezコードに戻すために使用できる逆コンパイラであるDeRezも含まれている。

リソース フォークの構造には、リソース データ項目の位置を格納する「リソース マップ」と呼ばれるデータがあります。これを使用すると、定義された ID と名前に基づいてリソース データにランダムにアクセスできます。リソース フォークは、基本的にリソース マップとリソース データ自体の 2 つのオブジェクトで構成されていると考えられますが、実際には各データ タイプは複数のデータ項目を格納する階層構造になっています。リソース データ内の情報が格納される形式は、情報の種類 (「リソース タイプ」と呼ばれる) に基づいて定義されます。リソース データは、他の種類のデータを参照することがよくあります。

macOS では、フォークはファイル/..namedfork/ forknameという名前が付けられます。たとえば、ファイル IMG_0593.jpg のリソース フォークは IMG_0593.jpg/..namedfork/rsrc です。このlsコマンドは、-l@ファイルのフォークを一覧表示するオプションをサポートしています。

リソースフォークは拡張属性com.apple.ResourceForkとして表示されます。^[4]

以前は、リソースフォークは「リソースマネージャー」APIを介してアクセスされていました。このAPIは現在非推奨です。^[5]

非推奨の API の場合:

1. リソース フォークにアクセスすると、リソース データの開始位置や長さ、リソース マップなどのデータがヘッダーから読み込まれます。
2. 読み込むリソース タイプが指定されている場合は、そのタイプがリソース リストに存在するかどうかを確認するチェックが実行され、そのタイプを含むデータの項目数と、リソース マップの開始位置からのリソース参照リスト内のオフセットが検索されます。
3. リソース ID、リソース名のオフセット、リソースのプロパティ、リソース データの開始位置からのデータのオフセットが見つかります。
4. リソースデータ内に指定されたIDまたは名前のリソースデータが存在する場合、上記で取得したオフセットにアクセスし、データ長を調べ、そこに格納されているデータをすべて読み込み、戻り値として返します。

などのファイル マネージャー APIPBOpenRF()も、生のリソース フォークへのアクセスを許可していますが、ファイルのコピーなどのアプリケーションにのみ使用する必要があります。Apple は、リソース フォークを「第 2 のデータ フォーク」として使用することに対して強く警告しています。

POSIXインターフェースからは、リソースフォークは またはfilename/..namedfork/rsrcとしてアクセスできましたがfilename/rsrc、短縮形はMac OS X v10.4で非推奨となり、Mac OS X v10.7で完全に削除されました。^[6]

リソース フォークを構成する最小の要素をデータ型といいます。データ型にはいくつかの種類があります。リソース フォークにアクセスすると、あらかじめ定義したデータ型に応じて読み込んで内容を調べることができます。プログラム内にデータの扱い方を記述する定義を配置することで、TMPL リソースと呼ばれるリソースも格納できます。この方法を使用すると、ResEdit などのプログラムで表示したときにデータの可視性が向上し、後で編集しやすくなります。Macintosh プラットフォームは Motorola ベースのプロセッサ (68k および PPC) から始まったため、データはビッグ エンディアン形式でディスクにシリアル化されます。

以下は、アルファベット順の主要なデータ型のリストです。

以下のタイプ コードは、上記のデータ型と同様に、リソース フォーク自体のタイプ識別子としてだけでなく、ファイル自体を識別したり、クリップボード内のデータを記述したりするために使用されます。

型は 4 バイトの長さである必要があるため、snd や STR などの型には実際には末尾にスペース (0x20) が付きます。

ResEdit

Apple が無料で配布しています。リソース データの視覚的な編集に使用できます。データの構造がわかっていれば、さまざまなタイプのデータを視覚的な形式で表示できます。最新の macOS では動作しません。

リソーサー

高価ですが、ResEdit よりも多くの種類のデータを視覚的に編集できるため、人気があります。

16進数編集

バイナリ エディター。実際には、通常はリソース フォークではなくデータ フォークの編集に使用されます。

レスナイフ

Mac OS X用のオープンソース エディター。メンテナンスされなくなりました。

レジクル

リソースフォークからリソースを個別のバイナリ ファイルに抽出し、多くのタイプを最新の開発に適した形式に変換する macOS ツールです。

リソース_dasm

macOSとLinux用のオープンソースのリソース抽出ツール。多くのリソースを最新の形式に変換することもできます。^[7]

レスフォージ

macOS用のリソースエディタ。クラシックリソースフォークファイルや関連フォーマットを編集できます。macOS 10.14以降と互換性があります。64ビットIntelとApple Siliconの両方でネイティブに動作します。^[8]

リソースフォークを使ったプログラミングの複雑さは、 AFP、SMB、NFS、FTPなどのファイル共有プロトコルを介して他のファイルシステムにアクセスする場合、非 HFS ボリュームに保存する場合、または他の方法 (電子メール経由など) で他のシステムにファイルを転送する場合に互換性の問題を引き起こしました。 AFP プロトコルはリソースフォークをネイティブにサポートしているため、リソースフォークは通常、これらのボリュームにそのまま送信され、サーバーによってクライアントに透過的に保存されます。 SMB プロトコルは、代替データストリーム(以下、ADS) と呼ばれる Macintosh フォークに似たファイルメタデータシステムをサポートしています。 macOS は、 Mac OS X v10.6まで、SMB ボリューム上の ADS へのリソースフォークの保存をデフォルトでサポートしていませんでした。 10.6 のアップグレードバージョンを含む以前のバージョンの OS では、パラメータを変更するか、特別なファイルを作成することでこの機能を有効にすることができます。^[9]

NFSv3 や FTP などのネットワーク ファイル共有プロトコルにはファイル メタデータの概念がないため、リソース フォークをネイティブに保存する方法はありません。これは、UFS などの特定の種類のローカル ファイル システムや、代替データ ストリームのサポートが有効になっていない SMB ボリュームに書き込む場合にも当てはまります。これらの場合、macOS はメタデータとリソース フォークをAppleDouble と呼ばれる手法を使用して保存します。この手法では、データ フォークは 1 つのファイルとして書き込まれ、リソース フォークとメタデータは「._」命名規則が先頭に付いた完全に別のファイルとして書き込まれます。たとえば、ExampleFile.psdにはデータ フォークが含まれ、._ExampleFile.psd にはリソース フォークとメタデータが含まれます。

macOS は、macOS のバージョン、設定、およびファイル システムの種類に応じて、リソース フォークの保存方法が異なるため、互換性の問題が発生する可能性があります。たとえば、10.5 と 10.6 のクライアントが混在する SMB ネットワークの場合です。新しくインストールされた 10.6 クライアントは、SMB ボリューム上のリソース フォークを ADS で検索して保存しますが、10.5 クライアントは (デフォルトで) ADS を無視し、フォークの処理にAppleDouble形式を使用します。ファイル サーバーが AFP と NFS の両方をサポートしている場合、NFS を使用するクライアントはファイルをAppleDouble形式で保存しますが、AFP ユーザーはリソース フォークをネイティブに保存します。このような場合、クライアントにAppleDouble形式の 使用を強制するか、使用しないようにすることで、互換性を維持できることがあります。

AFP サポートを提供するファイルサーバーの多くは、ローカル ファイル システム上のリソース フォークをネイティブにサポートしていません。このような場合、フォークは特別な名前のファイル、特別なディレクトリ、または代替データ ストリームなどの特別な方法で保存されることがあります。

もう 1 つの課題は、リソース フォークを認識しないアプリケーションや、電子メールや FTP などの特定の転送方法を使用してファイルを転送するときに、リソース フォークを保持することです。これに対応するために、 MacBinaryやBinHexなどのいくつかのファイル形式が作成されています。コマンド ライン システム ツールを使用するSplitForksと、FixupResourceForksリソース フォークを手動でフラット化およびマージできます。さらに、Macintosh クライアントにファイル システムを提供するファイル サーバーは、ファイルのリソース フォークだけでなくデータ フォークにも対応する必要があります。AFPサポートを提供するUNIXサーバーは、通常、隠しディレクトリを使用してこれを実装します。

Carbon APIで作成された古いアプリケーションは、現在のIntel Macに移植すると潜在的な問題を抱えることになります。リソース マネージャーとオペレーティング システムは、' snd ' や ' moov' などの一般的なリソースのデータを正しく逆シリアル化する方法を認識していますが、TMPL リソースを使用して作成されたリソースは、PPC と Intel ベースのアプリケーション バージョン間のファイルの相互運用性を確保するために手動でバイト スワップする必要があります。(リソース マップとその他の実装の詳細はビッグ エンディアンですが、リソース マネージャー自体は汎用リソースの内容を認識していないため、バイト スワップを自動的に実行することはできません。)

Mac OS X v10.4が登場するまで、macOS の標準 UNIX コマンドライン ユーティリティ (やなどcp)はmvリソース フォークを尊重しませんでした。リソース フォークを含むファイルをコピーするには、または CpMac と MvMac を使用する必要がありましたditto。

メモリを節約するためのグラフィックス オブジェクト用のリソース マネージャーの概念は、Smalltalk-76 のXerox Altoの OOZE パッケージに由来しています。 ^[10]この概念は、現在ではすべての最新のオペレーティング システムでほぼ共通しています。ただし、リソース フォークの概念は Macintosh に特有です。ほとんどのオペレーティング システムでは、リソースを含むバイナリ ファイルを使用しており、これは既存のプログラム ファイルの末尾に「追加」されます。このソリューションは、たとえばMicrosoft Windowsで使用されており、同様のソリューションがX Window Systemでも使用されていますが、リソースは別のファイルとして残されることがよくあります。

Windows NT NTFS はフォークをサポートできるため (Mac ファイルのファイル サーバーとしても使用可能)、そのサポートを提供するネイティブ機能は代替データ ストリームと呼ばれます。Windows オペレーティング システムの機能 (Office 以外のファイルのプロパティ ページの標準の概要タブなど) と Windows アプリケーションはそれらを使用しており、Microsoft はこの種の機能を基盤とする 次世代ファイル システムを開発していました。

BeOSの初期バージョンでは、ファイル システム内にデータベースが実装されており、リソース フォークに似た方法で使用できました。パフォーマンスの問題により、後のリリースでは複雑なファイル システム属性のシステムに変更されました。このシステムでは、リソースは Mac に似た方法で処理されました。

AmigaOS はフォークされたファイルを使用しません。その実行ファイルは、内部的に、コード、データ、および追加情報を格納できる大きな部分 (ハンク)のモジュール構造に分割されます。同様に、データ ファイルとプロジェクト ファイルには、 IFF標準でコード化されたチャンク構造があります。他のファイル タイプは、他のオペレーティング システムと同様に格納されます。厳密にはリソース フォークではありませんが、AmigaOS はファイルと呼ばれるファイルにメタデータを格納します。ファイルは拡張子で識別できます。たとえば、プロジェクトをディスクに保存すると、2 つのファイルが保存され、.が実際のプロジェクト データで、プロジェクト アイコン、プロジェクトを開くために必要なプログラムに関する情報 (AmigaOS にはアプリケーション バインディングがないため)、特別なプロジェクト オプション、およびユーザー コメントが含まれます。ファイルは、Amiga のデスクトップ ( Workbench ) では表示されません。デスクトップ上のアイコンは 自体から取得され、ユーザーがプロジェクト自体とそれに関連付けられたファイルの両方と対話するためのインターフェイス メタファーです。アイコンを右クリックすると表示されるダイアログ ボックスで、ファイルに存在するメタデータを表示および変更できます。ファイルは、コマンドライン インターフェイスまたはファイル マネージャーで個別のファイルとして表示できます。最新の AmigaOS クローン ( AROS、MorphOS、AOS4 ) は、古い AmigaOS バージョンのファイルの構造 (メタデータを含む) を継承し、ファイル内のアイコン ビットマップとして標準のPNGグラフィック ファイルも受け入れることができます。 .info.info.infoMyProjectMyProject.infoMyProjectMyProject.info.info.info.info.info.info.info.info

NeXTオペレーティングシステムNeXTSTEPとOPENSTEP、その後継であるmacOS、およびRISC OSなどの他のシステムでは、別のソリューションが実装されています。これらのシステムでは、リソースは元の形式のまま残されます。たとえば、画像は、何らかのコンテナーにエンコードされるのではなく、完全なTIFFファイルとして含まれています。これらのリソースは、実行可能コードと「生データ」とともにディレクトリに配置されます。ディレクトリ (「バンドル」または「アプリケーションディレクトリ」と呼ばれます) は、アプリケーション自体としてユーザーに提示されます。このソリューションは、リソースフォークと同じ機能をすべて提供しますが、リソースを任意のアプリケーションで簡単に操作できるようにします。「リソースエディター」( ResEditなど) は必要ありません。コマンドラインインターフェイスからは、バンドルは通常のディレクトリのように見えます。このアプローチは、ファイルシステム ( MFS ) が個別のカタログディレクトリをサポートしていなかったため、従来の Mac OSではオプションではありませんでした。カタログファイルのサポートが Mac OS に含まれ、HFS ファイルシステムが導入されたとき、リソースフォークは保持されました。 macOS では、下位互換性を保つために、従来のリソース マネージャーAPI がCarbonライブラリの一部として保持されています。ただし、リソース自体はファイル システム内の別のデータ ファイルに保存できるようになりました。リソース マネージャーは、この実装の変更をクライアント コードから隠すようになりました。

• フォーク（ファイルシステム）

• リソースファイル形式の説明
• Apple Developer リソースライブラリ: リソース マネージャー リファレンス
• Apple Developer リソースライブラリ: リソース管理、バンドル
• 大統一モデル - リソースフォークの歴史、folklore.org より
• Rezycle – リソース抽出ツール
• Mac OS X サービス – コンテキスト メニューからファイルのリソース フォークを削除する Mac OS X サービス
• Mac OS X のリソースフォーク、拡張属性、NTFS ストリーム、ドットアンダースコアファイルはどうなっているのでしょうか?
• SMB プロトコルを使用してファイルを保存すると、「ドット アンダースコア」(._) ファイルにはどのような情報が保存されますか? この情報は NTFS ファイル システムではどのように保存されますか?