Loading article…
リソースフォークは、Appleの従来のMac OSオペレーティングシステム上のファイルのフォークであり、構造化データを格納するために使用されます。これは、オペレーティングシステムが非構造化データとして扱うデータを格納するデータフォークとともに、ファイルの2つのフォークの1つです。[ 1 ] : 1-4リソースフォーク機能は、互換性のために最新のmacOSにも引き継がれています。
リソースフォークは、アイコンビットマップ、ウィンドウの形状、メニューとその内容の定義、アプリケーションコード（マシンコード）などの詳細情報を特定の形式で格納します。リソースフォークはアプリケーションだけでなく、あらゆるファイルに存在することができます。例えば、ドキュメントウィンドウの画面上の位置は、ドキュメントの内容がデータフォークに格納されているのとは別に、ドキュメントのリソースフォークにリソースとして格納される場合があります。[ 1 ]： 1-5
リソースとリソースフォークの概念は、Appleのプログラマーであるブルース・ホーンによって考案され、実装されました。[ 2 ]これは、Smalltalkの動的でオブジェクト指向のプログラミング環境、特にテッド・ケーラーによって設計されたオブジェクト指向の仮想メモリシステムOOZEに触発されたものです。[ 3 ]
従来のMac OSでは、リソースとリソースフォークはいくつかの目的を果たしていました。
リソースフォークは、従来の Mac OS のシステム ドライブで使用されるすべてのファイルシステム( MFS、HFS、HFS Plus ) とmacOS専用のAPFS (ただし、初期の Mac OS X バージョンでシステム ドライブとしてサポートされていた UFS [ 5 ]ではサポートされていません) でネイティブにサポートされています。リソースフォークが存在すると、デスクトップにそのファイルに対して表示するアイコンなど、さまざまな追加情報を簡単に保存できます。データ フォークではその中の任意のオフセットにランダムにアクセスできますが、リソース フォークへのアクセスは、データベース から構造化されたレコードを抽出するのと似ています。
Macintoshのファイルシステムは、データフォークやリソースフォークとは別に、作成日時や変更日時、ファイルの種類や作成者コード、フォークの長さなどのメタデータを保存します。
ファイルによっては、リソースフォークのみを持つものもあります。例えば、従来のMac OSのフォントファイルが挙げられます。また、Classic 68kアプリケーションでは、実行可能コードさえも「CODE」タイプのリソースに格納されています。後のPowerPCバイナリでは、実行可能コードはデータフォークに格納されるようになりました。
リソースフォークは、MFS、HFS、HFS Plus、APFSなどのMacintoshファイルシステムでのみサポートされていたため、他のオペレーティングシステムのファイルシステムにコピーすることはできませんでした。Mac BinHexおよびMacBinaryフォーマットは、リソースフォークとデータフォークを1つのファイルにエンコードしてシステム間で転送するために考案されました。A /UXは、AppleSingleおよびAppleDoubleフォーマットを介してUnixファイルシステム上のリソースフォークをサポートしました。Mac OS X Tiger以降、AppleDoubleは、Windows SMB共有やFAT32ボリュームなどのファイルシステムにリソースフォークを保存するために使用されるようになりました。
HFS Plusファイルシステムでは、データフォークとリソースフォークに加えて他のフォークも許可するように設定して、「マルチフォーク」アプリケーションを作成できます。[ 6 ]
2002年8月7日現在、Appleは開発者に対し、Mac OS X上のMach-Oバイナリのリソースフォークにリソースを組み込まないよう推奨している。 [ 7 ]
各リソースには、OSType識別子 (4 バイトの値)、ID (符号付き16 ビットワード)、およびオプションの名前があります。ダイアログボックス( DITL)、画像 ( PICT)、サウンド ( ) 、および実行可能バイナリ ( ) には標準化されたリソース タイプがあり、 PowerPCプロセッサが登場するまでは、例外なくリソース フォークに格納されていました。ウィンドウをレンダリングするサブルーチンは独自のタイプのリソース ( ) に格納され、メニューをレンダリングするサブルーチンは独自のタイプ ( ) に格納されます。この構成により、ユーザーはResEditなどのツールを使用してアプリケーション ファイルまたはシステム ファイルのリソースを変更することで、個々のアプリケーションだけでなくオペレーティングシステム自体も簡単にカスタマイズできました。snd CODEWDEFMDEF
アプリケーションやその他のコード内では、リソースは、リソースフォーク内でどのように、どこに格納されているかに関係なく、そのタイプ、ID、または名前の組み合わせを使用して簡単にロードできます。クライアントにはロードされたリソースへのハンドルが返され、他のヒープベースのデータと同様にアクセスできます。これを可能にするOSコンポーネントはリソースマネージャです。リソースマネージャは、データストレージの詳細をデータから抽象化するだけでなく、開いているリソースフォークのセットをスタックに配置し、最後に開いたファイルを最上位にします。リソースをロードしようとすると、まずスタックの最上位（おそらく現在のドキュメントのリソースフォーク）を参照し、次にその下（アプリケーションのリソースフォーク）、さらにその下（システムのリソースフォーク）を参照します。この構成は非常に強力で、ローカルリソースが下位のグローバルリソースを上書きできるため、たとえばアプリケーションは標準のシステムアイコンやフォントの代わりに独自のアイコンやフォントを提供できます。また、アプリケーションは、リソースがどこに、どのように保存されているかに関係なく、他のリソースと同じ API を使用してシステムからリソースをロードできます。アプリケーションにとって、すべてのリソースは等しく利用可能で、簡単に使用できます。システムは、リソースの競合を回避するために、特定の範囲のリソース ID を予約します。リソースマネージャ API を使用すると、プログラマはスタックを操作し、検索動作を変更できます。
リソースフォークはResEditなどのリソースエディタで編集できるため、ソフトウェアのローカライズやカスタマイズに使用できます。さらに、ほとんどのリソースエディタではデータのビジュアル編集が可能です。macOS では、アプリケーション開発時にリソースを使用できます。ただし、アプリケーションをUFSで使用する必要がある場合は、Raw Resource File 設定を使用して、リソースフォーク全体をデータフォークに移動するように構成することもできます。Apple Inc.が無料で配布している統合開発環境(MPWやApple Developer's Toolsなど)には、Rez と呼ばれるコンパイラが含まれています。 [ 1 ] : 1-3これは、ソースコードをコンパイルしてリソースフォークを作成するために使用できる、Rez と呼ばれる専用言語を使用します。リソースフォークを Rez コードに戻すために使用できる逆コンパイラ DeRez も含まれています。
リソースフォークの構造には、リソースデータ項目の位置を格納する「リソースマップ」と呼ばれるデータがあります。[ 1 ] : 1-8これは、定義されたIDと名前に基づいてリソースデータへのランダムアクセスを可能にするために使用できます。リソースフォークは、リソースヘッダー、リソースマップ、リソースデータ自体の3つのオブジェクトで構成されていると考えることができますが、[ 1 ] : 1-4、1-5実際には、各データタイプは複数のデータ項目を格納する階層構造です。リソースデータ内の情報が格納される形式は、「リソースタイプ」として知られる情報のタイプに基づいて定義されます。リソースデータは、他のタイプのデータを参照することがよくあります。
リソースフォークは拡張属性com.apple.ResourceForkとして表示されます。[ 8 ]
以前は、リソースフォークは「リソースマネージャ」APIを介してアクセスされていました。このAPIは現在非推奨です。[ 9 ]
非推奨APIの場合：
ファイルマネージャAPIなどもPBOpenRF()生のリソースフォークへのアクセスを許可していましたが、ファイルのコピーなどのアプリケーションにのみ使用すべきです。Appleはリソースフォークを「2番目のデータフォーク」として使用することを強く警告しています。[ 10 ] [ 1 ]： 1-5
POSIXインターフェースからは、リソース フォークは またはfilename/..namedfork/rsrcとしてアクセスできましたfilename/rsrc。短い形式はMac OS X v10.4で非推奨となり、 Mac OS X v10.7で完全に削除されました。[ 11 ]
以下の型コードは、上記のデータ型と同様に、リソースフォーク自体だけでなく、ファイル自体の識別、クリップボード内のデータの記述など、さまざまな用途で型識別子として使用されます。
型は4バイト長でなければならないため、sndやSTRのような型は実際には末尾にスペース（0x20）を持ちます。
リソースフォークはMac固有の機能であるため、FATなどのリソースフォークをネイティブにサポートしていないファイルシステムにMacファイルを保存したり、ネットワーク共有に保存したり、電子メールなどを介してネットワーク経由で送信したりする場合、互換性の問題が発生します。
AFPはリソースフォークをネイティブにサポートしています。多くのAFPサーバーは内部的にリソースフォークをサポートしていないファイルシステムを使用しているため、リソースフォークは特別なファイルやディレクトリ、あるいは別のデータストリームなど、別の方法で保存されます。ただし、これはサーバー側で内部的に行われるため、クライアントから見ると、AFP共有上のファイルにはネイティブのリソースフォークが存在することになります。
SMBプロトコルは、 Macフォークに似たファイルメタデータシステムである代替データストリームをサポートしており、macOSはSMBサーバーがサポートしていれば、 Mac OS X 10.6以降、これをデフォルトで使用します。10.6のアップグレード版を含む以前のバージョンのMac OS Xでは、この機能はデフォルトで無効になっていますが、手動で有効にすることができます。[ 15 ]
リソースフォーク、拡張属性、または代替データストリームをネイティブにサポートしないボリューム（ローカルFATファイルシステムやNFSv3ネットワーク共有など）では、macOSはAppleDoubleと呼ばれる手法を使用してリソースフォークやその他のMac固有のメタデータを保存します。この場合、データフォークは通常のファイルとして書き込まれ、リソースフォークとメタデータは、元のファイル名の先頭に「._」を付加した別の隠しファイルに書き込まれます。たとえば、「ExampleFile.psd」にはデータフォークが、「._ExampleFile.psd」には対応するリソースフォークとメタデータが含まれます。
同じネットワーク共有に接続するMacクライアントが、リソースフォークの保存方法が異なる場合、互換性の問題が発生する可能性があります。たとえば、一方のクライアントがAFPのようにネイティブでリソースフォークをサポートするプロトコルを使用しているのに対し、もう一方のクライアントがAppleDoubleを使用してリソースフォークを保存するNFSv3などのプロトコルで接続している場合、同じファイルに対して2つのクライアントで異なるリソースフォークの内容が表示される可能性があります。
もう一つの課題は、リソースフォークを認識しないアプリケーションを使用したり、電子メールやFTPなどの特定の転送方法を使用したりしてファイルを転送する際に、リソースフォークを保持することです。これに対応するために、MacBinaryやBinHexなどのファイル形式がいくつか作成されています。コマンドラインシステムツールを使用するSplitForksと、FixupResourceForksリソースフォークを手動でフラット化およびマージできます。
Intelアーキテクチャ用にコンパイルされたCarbonアプリケーションは、リソースを扱う際にバイト順序の問題が発生する可能性があります。これは、ほとんどのリソースデータが68000およびPowerPCアーキテクチャで使用されるビッグエンディアンのバイト順序で格納されており、Intelアーキテクチャのリトルエンディアンのバイト順序と一致しないためです。オペレーティングシステムは、リソースフォーク全体の形式や「snd 」や「moov」などの標準リソースタイプについてはこれらのバイト順序の違いを自動的に処理しますが、非標準タイプのリソースについては、アーキテクチャに関係なく一貫した動作を保証するために、データのバイトスワップを手動で行う必要があります。[ 16 ]
Mac OS X v10.4が登場するまで、macOSの標準的なUNIXコマンドラインユーティリティ（やなどcp）mvはリソースフォークを尊重しませんでした。リソースフォークを含むファイルをコピーするには、またはCpMacとMvMacを使用する必要がありましたditto。
メモリを節約するためのグラフィックス オブジェクトのリソースマネージャの概念は、Smalltalk-76 のXerox Altoの OOZE パッケージで生まれました。 [ 17 ]この概念は現在、すべての最新のオペレーティングシステムでほぼ普遍的です。ただし、リソース フォークの概念は Macintosh に特有のものです。ほとんどのオペレーティングシステムは、リソースを含むバイナリ ファイルを使用し、それを既存のプログラム ファイルの末尾に「追加」します。このソリューションは、たとえば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では選択肢になりませんでした。HFSファイルシステムでカタログファイルのサポートがMac OSに組み込まれると、リソースフォークが維持されました。macOSは、後方互換性のために、 Carbonライブラリの一部として従来のResource Manager APIを保持しています。しかし、リソース自体はファイルシステム内の個別のデータファイルに保存できるようになりました。リソースマネージャは、この実装変更をクライアントコードから隠蔽します。