プロトコル ハンドラーについて

  • [アーティクル]

アプリケーションによっては、項目がデータベースまたはカスタム ファイルの種類に格納されます。 Windows Search ではファイルの名前とプロパティにインデックスを付けることができますが、Windows ではファイルの内容を認識できません。 その結果、このような項目のインデックスを作成したり、Windows シェルで公開したりすることはできません。 プロトコル ハンドラーを作成することで、これらの項目をインデックス作成に使用できるようになります。 また、.zip ファイルなどの複合ファイル形式のインデックスを作成することもできます。

このトピックは次のように構成されています。

プロトコル ハンドラーを使用したデータ ストアのインデックス作成

Windows Search でサポートされていないレガシ データベース、メール ストア、またはその他のデータ構造を検索する必要がある場合は、まず、SharePoint Server などの別のアプリケーションで使用するために、そのデータ ストアのプロトコル ハンドラーが既に存在するかどうかを確認する必要があります。 もし存在する場合は、そのプロトコル ハンドラーをシステムにインストールできます。 Windows Search プロトコル ハンドラーでは、SharePoint Server と同様の設計仕様が使用されているため、多くの場合、同じように使用できます。

Office SharePoint Server 2007 での Search Server 2008 の展開の詳細については、「フェデレーション検索 [Search Server 2008]」を参照してください。

シェル データ ストア

新しいファイル形式とデータ ストアを開発するサード パーティが、これらの形式とデータ ストアを Windows エクスプローラーのクエリ結果に表示できるようにするには、シェル データ ソースを実装する必要があります。 シェル データ ソースは、シェル名前空間を拡張し、データ ストア内の項目を公開するために使用されるコンポーネントです。 データ ストアは、データのリポジトリです。 データ ストアは、シェル データ ソースを使用するコンテナーとしてシェル プログラミング モデルに公開できます。 データ ストア内の項目は、プロトコル ハンドラーを使用して Windows Search システムによってインデックスを作成できます。 プロトコル ハンドラーは、コンテンツ ソースにネイティブ形式でアクセスするためのプロトコルを実装します。 ISearchProtocol インターフェイスと ISearchProtocol2 インターフェイスは、カスタム プロトコル ハンドラーを実装して、インデックスを作成できるデータ ソースを拡張するために使用されます。

クエリ結果を Windows エクスプローラーに表示させたい場合は、インデックスを拡張するプロトコル ハンドラーを作成する前に、シェル データ ソースを実装する必要があります。 ただし、すべてのクエリが (たとえば OLE DB を介して) プログラム的に実行され、シェルではなくアプリケーションのコードによって解釈される場合は、シェル名前空間が望ましいですが、厳密には絶対に必要というわけではありません。

Note

シェル データ ソースは、シェル名前空間拡張機能と呼ばれることもあります。 ハンドラーは、シェル拡張機能またはシェル拡張ハンドラーと呼ばれることもあります。

 

Windows エクスプローラー内から検索結果を表示させたい場合は、プロトコル ハンドラーと、次のアドインを 1 つ以上作成する必要があります。

  • ショートカット メニュー ハンドラー
  • アイコン ハンドラー
  • その他のファイル ハンドラー

実現しようとしている開発者のシナリオによって識別されるハンドラーの一覧については、開発プラットフォームとしての Windows Search の「ハンドラーの概要」を参照してください。 ハンドラーの作成の詳細については、「シェル拡張機能の登録」、「コンテキスト メニュー」、 および「ファイルの種類のハンドラー」を参照してください。

プロトコル ハンドラー

また、データ ストアがコンテナー (ファイル システムのフォルダーなど) でもある場合は、コンテナー内の URL を列挙するフィルターを実装する必要があります。 データ ストアに、Windows Search でサポートされている 200 種類のファイルの種類以外のデータまたはファイルの種類が含まれている場合は、ストア内の項目の内容にアクセスしてインデックスを作成するフィルターを実装する必要があります。 Windows Search では、SharePoint Server で使用されるのと同様のプロトコル ハンドラーと IFilter の技術が使用されています。 インデックスを作成するシステムに特定のストアとファイルの種類のフィルターが既にインストールされている場合、Windows Search は既存のインターフェイスを使用してこのデータのインデックスを作成できる可能性があります。

インデックス作成プロセスの概要については、「インデックス作成プロセス」を参照してください。 フィルター ハンドラーのコンセプトについては、「フィルター ハンドラーの開発」を参照してください。

フィルターとプロトコル ハンドラー

プロトコル ハンドラーは、Windows Search インデクサーにデータ ストアへのアクセス権を付与し、インデクサーがデータ ストアのノードをクロールし、インデックスに関連する情報を抽出できるようにします。 たとえば、Windows Search には、ファイル システム ストアと一部のバージョン向けの、両方の Microsoft Outlook データ ストアのプロトコル ハンドラーが同梱されています。 Outlook メールのインデックス作成時に、プロトコル ハンドラーは一連の Outlook フォルダー内のすべてのメッセージをクロールし、各メッセージと添付ファイルから情報を抽出します。 この情報は、Windows Search カタログに含めるためにインデクサーに渡されます。

カタログ マネージャーとクロール スコープ マネージャー (CSM) の概要については、「カタログ マネージャーの使用」および「クロール スコープ マネージャーの使用」を参照してください。

複合ファイル形式のインデックス作成

複合ファイル形式のインデックスは、ファイル内の個々の項目を個々の結果として返すようにインデックスを作成できます。 .zip ファイル名拡張子を持つ圧縮ファイルなどの複合ファイル形式は、本質的にデータ ストアであるため、インデックス作成の目的ではデータ ストアとして扱うことができます。 次の例では、サブフォルダーと個々の項目の両方があるファイル システム名前空間 (FILE://c:/test/test.zip) に .zip ファイルを表示します。

Test.zip 

    |-folder1 

    |    |-folder2 

    |           |- FileX.txt 

    |- FileY.doc

FILE プロトコル ハンドラーは、ファイル システムの変更ログを監視することで FILE://c:/test/test.zip がいつ変更されたかを検出し、ファイルが変更されたときにそのファイルの .zip ファイルに登録されている IFilter を呼び出しますが、.zip ファイル自体の内部構造は認識されません。

複合ファイル形式がデータ ストアであることをインデクサーに通知する必要があります。 個々の項目にインデックスを作成し、一意のエンティティとして取得するには、これを行う必要があります。 シェル データ ソースを実装し、次の手順を実行すると、複合ファイル形式 (.zip ファイル) のデータを個々の項目として処理して公開できるプロトコル ハンドラーが作成されます。

複合ファイルがデータ ストアであることをインデクサーに通知するには、次の手順を実行します。

  1. ソース ファイルにバインドできる .zip ファイルのプロトコル ハンドラー (ISearchProtocol または ISearchProtocol2 を使用) を作成します。 詳細については、「プロトコル ハンドラーのインストールと登録」を参照してください。

    たとえば、.zip ファイルへのエスケープされたパスをルート フォルダー名として使用し、他のファイル形式と同様に階層構文を使用できます。

    .zip:///escapedPathTo.zipFile/.zipfolder/.../.zipfile

    上記の c:\test\test.zip のサンプル データを使用すると、一意の URL は次のようになります。 これらの URL を使用すると、プロトコル ハンドラーには、.zip ファイルにバインドし、内部ファイルを含む子 URL を列挙するために必要な情報が含まれているため、.doc フィルターと .txt フィルターにバインドしてインデックスを作成できます。

    

.zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/ 

.zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/FileY.Doc 

.zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/folder1 

.zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/folder1/folder2 

.zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/folder1/folder2/FileX.txt

  2. プロトコル ハンドラーが次の 2 つの条件を満たしていることを確認します。

    • .zip ファイルのルート URL は、ルート .zip ファイルの URL である URL にPKEY_Search_IsClosedDirectory (System.Search.IsClosedDirectory) を出力する必要があります。 たとえば、.zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/ は IsClosedDirectory = TRUE を出力する必要があります。 これにより、インデクサーには、この URL の日付が変更されていなければ、子 URL を処理する必要はないことが伝わります。
    • その URL のすべての子 URL は、ルート .zip URL の子 URL に PKEY_Search_IsFullyContained (System.Search.IsFullyContained) を出力する必要があります。 通常、インデクサーは増分クロールの終了時に、すべての未確認の URL を削除する必要がある項目として扱います。 ただし、ルート .zip ファイルでは、何も変更されていないため、ルート URL を処理をする必要がありません。 このプロパティを TRUE として出力することで、この URL 増分クロールが最後まで処理されていない場合は削除しないことをインデクサーに伝えることができます。 ルート項目が変更され、アクセスされていない場合にのみ削除されます。

Windows Search では、増分クロールする URL と、見つかったときに無視する URL を把握するために、プロトコルのスタート ページが必要です。 ただし、それぞれの .zip ファイルの格納場所がわからないため、各 .zip ファイルの URL から始めることはできません。 そのため、.zip プロトコル ハンドラーの開始ページの URL は、すべての .zip ファイルのエスケープされたパスのルートにあるすべてのものを列挙できる必要があります。 これらの .zip ファイルは、必ずしも FILE: 名前空間内にあるとは限らず、たとえば添付ファイルとして .zip ファイルを指す MAPI 型の URL である可能性もあります。

ルートをスタート ページとして登録するには、次の手順を実行します。

  1. .zip:///のようなルートをスタートページとして登録し、実質的にすべての.zipファイルがそこから始まるようにします。 ルート .zip: URL を処理する場合、プロトコル ハンドラーは、System.FileExtension = ".zip" ですべての URL を Windows Search に照会することで、出力する子 URL の一覧を生成する必要があります。

  2. これらの URL をエスケープしてスラッシュを削除し、子 URL として返します。 必要な型を取得するクエリの例を次に示します。

    SELECT system.itemurl, System.DateModified FROM SystemIndex 
WHERE System.FileExtension='.zip' OR System.MimeType='mimetypefor.zip'

  3. Windows Search が定期的に .zip:/// ルート URL に対して増分クロールを実行する場合は、Windows Search が既に保持している .zip URL の URL の一覧を反映する必要があります。 .zip ファイルが格納されているネイティブ ストアで削除が検出された場合、削除は列挙には表示されず、.zip 内のツリーのブランチは削除されます。

  4. 別のプロトコル ハンドラーの .zip データにバインドするには、その URL の IShellFolder を使用してオブジェクトのストレージにバインドするのが理想的であり、常にファイルであるとは限りません。 そうすることで、たとえばメール ストアの添付ファイルを柔軟に操作できます。

  5. 各 .zip ファイルの子 URL を出力する場合は、PKEY_Search_UrlToIndexWithModificationTime (System.Search.UrlToIndexWithModificationTime) を使用して、実際の .zip ファイルのPKEY_DateModified (System.DateModified) を渡して、インデクサーが .zip ファイルが変更された場合にのみクロールするようにする必要があります。

.zip URL が作成または変更された直後にインデックスを作成し、新しい状態が検出するために増分クロールを待つ必要がない場合は、.zip ファイルについては自分でファイルシステムを監視できます。 ただし、このような方法は、MAPI などの他のデータ ストアでは機能しません。

.zip URL が作成または変更されたときにインデックスを作成するには、次の手順を実行します。

  1. .zip ファイルの種類のフィルター (および IFilter インターフェイスの実装) を作成します。 詳細については、「Windows Search のプロパティ ハンドラーの開発」を参照してください。
  2. IFilter 実装が呼び出されるたびに、その URL が検出または変更されたことが原因です。 次に、IGatherNotifyInline インターフェイスを使用して、ソース URL に適した .zip URL のイベントを生成します。 これにより、増分クロールを待たずにインデックスを作成する新しいデータがあることをすぐにインデクサーに伝えることができます。

プロトコル ハンドラーの開発

プロトコル ハンドラーのインストールと登録

インデックスの変更通知

アイコンとコンテキスト メニューの追加

コード サンプル: プロトコル ハンドラーのシェル拡張機能

プロトコル ハンドラーのインストールと登録

プロトコル ハンドラーの検索コネクタの作成

プロトコル ハンドラーのデバッグ