リソースフォーク

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

リソースフォークはあるフォークやセクションファイルアップル古いMac OS オペレーティング・システムも、現代に引き継がれた、MacOSの中に保存された非構造化データと一緒に構造化データを格納するために使用される互換性のために、データフォークを

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

Macintoshファイルシステム

もともとプログラマーのブルースホーンによって考案され実装されたリソースフォークは、Macintoshファイルシステムで3つの目的に使用されました

  • これは、必要になるまですべてのグラフィカルデータをディスクに保存し、取得して画面に描画し、破棄するために使用されていました。このソフトウェアバリアント仮想メモリは、 Appleがで1メガバイトからメモリ要件を減らすために役立ったアップルリサマッキントッシュで128キロバイトに。
  • すべての写真とテキストはリソースフォークに別々に保存されていたため、プログラマー以外の人がアプリケーションを外国市場向けに翻訳できるようにするために使用できます。これは、国際化とローカリゼーションと呼ばれるプロセスです。
  • これを使用して、アプリケーションのほぼすべてのコンポーネントを1つのファイルに分散し、煩雑さを軽減し、アプリケーションのインストールと削除を簡素化できます。

リソースフォークはMacintoshのシステムドライブに使用されるすべてのファイルシステムMFSHFS、およびHFS Plus)に実装されています。リソースフォークの存在により、システムがファイルの正しいアイコンを表示し、ファイル名にファイル拡張子を付けなくても開くことができるようにするなど、さまざまな追加情報を簡単に保存できます。データフォークへのアクセスは、他のオペレーティングシステムでのファイルアクセスと同じように機能します(ファイルの選択、バイトオフセットの選択、データの読み取り)が、リソースフォークへのアクセスは、データベースから構造化レコードを抽出するのと同じように機能します。 (Microsoft Windowsリソース」の概念もありますが、これらはMac OSのリソースとはまったく関係ありません。)

リソースフォークは、ファイルメタデータを保存するために使用されることがありますが、従来のMacオペレーティングシステムのフォントファイルの場合のように、実際のデータを保存するためにも使用できます。 Macintoshファイルシステムには、データフォークまたはリソースフォークとは異なるメタデータ用の個別の領域もあることに注意してください。ファイルのカタログエントリの一部であるため、これにアクセスする方がはるかに高速です。ただし、ここに保存されるデータの量は最小限であり、作成と変更のタイムスタンプ、ファイルの種類と作成者のコード、フォークの長さ、ファイル名だけです。一部のファイルにはリソースフォークしかありません。従来の68kアプリケーションはその一例であり、実行可能コードでさえ「CODE」タイプのリソースに含まれています。後でPowerPC バイナリは、実行可能コードをデータフォークに格納します。

リソースフォークはファイルシステムHFS、HFS Plus、およびAPFSでのみサポートされているため、他のファイルシステムを使用するオペレーティングシステムでは使用できません現在、HFSはMacintoshオペレーティングシステムでのみサポートされています。つまり、MacOSを実行しているマシンのみがリソースフォークを使用できます。Mac OSシステムでも、Unixファイルシステムインストールされている場合、リソースフォークは使用できません。現在MacOSで最も一般的に使用されているシステムであるHFSPlusファイルシステムでは、データフォークとリソースフォークに加えて他のフォークが「マルチフォーク」アプリケーションを作成できるように設定できます。ただし、フォークによって他のオペレーティングシステムとのファイル交換が困難になる可能性があるため、この機能は一般的に使用されていません。macOSでも、リソースフォークはほとんど使用されなくなりました。

現在、macOSは、データフォークファイルと同じディレクトリに、ファイル名の先頭に文字「._」を追加した隠しファイルを作成することにより、WindowsSMB共有でのリソースフォークをサポートしています。

リソース識別子

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

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

リソースフォークの

リソースフォークはResEditなどのリソースエディタで編集できるため、ソフトウェアのローカライズとカスタマイズに使用できます。さらに、ほとんどのリソースエディタでは、データを視覚的に編集できます。ではMacOSのは、アプリケーションを開発するときにリソースを使用することが可能です。ただし、アプリケーションをUFS使用する必要がある場合は、Raw Resource File設定を使用して、リソースフォーク全体がデータフォークに移動するようにアプリケーションを構成することもできます。統合開発環境で無料で配布されたApple Inc.などが、MPWAppleの開発者向けツールは、含まれるコンパイラをRezと呼ばれます。これは、Rezとも呼ばれる専用言語を使用します。この言語を使用して、ソースコードをコンパイルすることでリソースフォークを作成できます。リソースフォークをRezコードに戻すために使用できる逆コンパイラーDeRezも含まれています。

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

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

リソースフォークへのアクセス方法

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

以前は、リソースフォークは「ResourceManager」APIを介してアクセスされていましたこのAPIは非推奨になりました。[2]

非推奨のAPIの下で:

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

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

POSIXのインタフェース、リソースフォークはとしてアクセスすることができfilename/..namedfork/rsrc、またはとしてfilename/rsrc短い形式はで廃止されましたのMac OS X 10.4とで完全に除去するMac OS X v10.7[3]

リソースフォークのデータ型

リソースフォークを構成する最小の要素は、データ型と呼ばれます。いくつかのデータ型があります。リソースフォークにアクセスした後、事前に定義されたデータ型に応じてリソースフォークを読み込むことにより、その内容を見つけることができます。プログラム内にデータの処理方法を示す定義を配置すると、TMPLリソースと呼ばれるリソースも格納できます。この方法を使用すると、ResEditなどのプログラムで表示したときのデータの可視性が高まり、後の編集が簡単になります。Macintoshプラットフォームはモトローラベースのプロセッサ(68kおよびPPC)で作成されたため、データはビッグエンディアン形式でディスクにシリアル化されます。

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

データ・タイプ 実名 説明
BBIT バイナリビット 単一のブールビット(trueまたはfalse)を表します。通常、BBITの数は8の倍数でなければなりません。
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文字列 Pascal文字列を表し、最初のバイトが文字列の長さを示します。
TNAM タイプ名 作成者コードなどの値を表す文字列。常に4バイトの長さです。
RECT 矩形 長方形の角の座標(上、左、下、右)を表します。常に8バイトの長さ。

主なリソースタイプ

以下のタイプコードは、上記のデータタイプと同様に、リソースフォーク自体以外のタイプ識別子として使用されます。これらは、ファイル自体の識別、クリップボード内のデータの記述などに使用されます。

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

リソースタイプの名前 実名 説明
alis エイリアス 「alias」属性ビットが設定されているファイルのリソースフォークに、別のファイルへのエイリアスを格納します
ALRT アラート アプリケーションアラートボックスの形状を定義します
APPL 申し込み アプリケーション情報を保存します
BNDL バンドル アプリケーションで使用されるファイルタイプアイコンなどのデータを定義します
cicn カラーアイコン データで使用されるカラーアイコンを定義します
clut カラールックアップテーブル データで使用されるカラーパレットを定義します
CNTL コントロール ウィンドウに配置されたコンポーネントの詳細を定義します
コード コードリソース プログラムのマシンコードを保存します
CURS カーソル モノクロカーソルの形状を定義します(8×8ビットの正方形)
DITL ダイアログアイテムリスト ウィンドウのコンポーネントを定義します
DLOG ダイアログ アプリケーションのダイアログボックスの形状を定義します
FREF ファイルリファレンス アプリケーションによって処理されるファイルタイプを定義します
hfdr アイコンバルーンヘルプ カーソルがFinderのファイルの上にあるときに表示されるバルーンヘルプの内容と形状を定義します
icl8 8ビットアイコンリスト Finderに表示されるアイコンを定義します
icns 32ビットアイコンリスト Finderに表示されるアイコンを定義します
アイコン アイコン データで使用されるモノクロアイテムを定義します
親切 ファイル説明 ファイルタイプの説明を定義します
MBAR メニューバー アプリケーションのメニューとメニューバーを定義します
MDEF メニュー定義 アプリケーションのメニューを定義します。カラーパレットなどの複雑な形状のメニューを定義するためにも使用できます。
メニュー メニュー アプリケーションのメニュー項目を定義します
MooV 映画 QuickTimeムービーを保存します
開いた 開いた アプリケーションが開くことができるファイルタイプを定義します
PICT 写真 ファイルに含まれるPICT画像を保存します
PREF 好み アプリケーションの環境設定を保存します
snd ファイルで使用されているサウンドを保存します
STR ストリング ファイルで使用される文字列または16進データを格納します
STR# 文字列リスト ファイルで使用される複数の文字列を格納します
スタイリング スタイル テキストのフォント、色、サイズなどのスタイル情報を定義します
文章 文章 テキストを保存します
TMPL レンプレート リソースデータの形式を定義します
バージョン ファイルの使用バージョンまたは使用地域を定義します
WDEF ウィンドウ定義 アプリケーションのウィンドウを定義します。不特定の形状の窓も定義できます。
アプリケーションウィンドウの形状を定義します

主要なリソースエディター

ResEdit
Appleから無料で配布されています。リソースデータの視覚的な編集に使用できます。データの構造がわかっている場合は、さまざまな種類のデータを視覚的な形式で表示できます。最新のmacOSでは動作しません。
リソーサラー
ResEditよりもはるかに多くの種類のデータの視覚的な編集に使用できるため、高価ですが人気があります。
HexEdit
バイナリエディタ。実際には、通常、リソースフォークではなく、データフォークの編集に多く使用されます。
ResKnife
Mac OSX用のオープンソースエディタ; もはや維持されていません。
Rezycle
多くのタイプを最新の開発に適した形式に変換しながら、リソースフォークからリソースを個別のバイナリファイルに抽出するmacOSツール。
resource_dasm
macOS用のオープンソースのリソースエクストラクタ。多くのリソースを最新の形式に変換することもできます。

互換性の問題

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

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

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

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

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

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

登場するまでのMac OS X 10.4、MacOSの中に標準的なUNIXのコマンドラインユーティリティは、(などcpmv)リソースフォークを尊重しませんでした。リソースフォークを使用してファイルをコピーするにはditto、CpMacとMvMacを使用する必要がありました。

その他のオペレーティングシステム

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

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

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

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

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

も参照してください

参考文献

  1. ^ 「MacOSXリソースフォーク」2012年1022日取得
  2. ^ 「リソースマネージャーリファレンス」2012年1022日取得
  3. ^ 「パス名の使用」development.apple.com2002-12-18。2002年12月18日にオリジナルからアーカイブされました2002年12月18日取得CS1 maint:bot:元のURLステータスが不明です(リンク
  4. ^ 「OSXv10.5、v10.6:SMBマウントされたNAS、OS X、およびWindowsサーバー上の名前付きストリームについて」2010年4月19日取得
  5. ^ 「Smalltalkの初期の歴史」2008年7月24日取得

外部リンク