WDS のプロトコル ハンドラーの実装
注意
Windows Desktop Search 2.x は、Windows XP および Windows Server 2003 のアドインとしてもともと使用されていた古いテクノロジです。 以降のリリースでは、代わりに Windows Search を使用してください。
プロトコル ハンドラーを作成するには、 ISearchProtocol を実装して UrlAccessor オブジェクトを管理し、 IUrlAccessor を実装して、データ ストア内のアイテムに関するメタデータを生成して識別し、IProtocolHandlerSite を使用して SearchProtocol オブジェクトをインスタンス化し、適切なフィルターを識別し、 IFilterを使用して独自のファイルをフィルター処理したり、階層的に格納されたファイルを列挙およびフィルター処理したりする必要があります。 プロトコル ハンドラーはマルチスレッドである必要があります。
このセクションには、次のトピックが含まれています。
URL に関する注意
Microsoft Windows Desktop Search (WDS) では、URL を使用して、ファイル システム、データベースのようなストア内、または Web 上のアイテムを一意に識別します。 エントリ ノードを定義する URL は、スタート ページと呼ばれます。WDS はその開始ページから開始し、データ ストアを再帰的にクロールします。 一般的な URL 構造は次のとおりです。
protocol://host/path/name.extension
Note
新しいデータ ストアを追加する場合は、現在のデータ ストアと競合しない名前を選択して識別する必要があります。 companyName.scheme という名前付け規則をお勧めします。
プロトコル ハンドラー インターフェイス
ISearchProtocol
ISearchProtocol インターフェイスは、UrlAccessor オブジェクトを呼び出し、初期化、および管理します。 ISearchProtocol インターフェイスの実装の詳細については、「 ISearchProtocol インターフェイス リファレンス」を参照してください。
IUrlAccessor
指定した URL の場合、 IUrlAccessor インターフェイスは、格納されている項目だけでなく、場所構造に関するメタデータを生成し、それらの項目をフィルターにバインドします。 IUrlAccessor オブジェクトは、SearchProtocol オブジェクトによってインスタンス化および初期化されます。ただし、内部初期化メソッドを実装して、IUrlAccessor オブジェクトがプロトコル ハンドラーに固有の初期化タスクを実行できるようにすることもできます。たとえば、アクセスされるアイテムの URL を検証したり、最終変更時刻を確認して、現在のクロールでファイルを処理する必要があるかどうかを判断したりできます。
注意
ディレクトリの変更時刻は無視されます。 IUrlAccessor オブジェクトは、変更または削除が行われたかどうかを判断するために、子オブジェクトを列挙する必要があります。
UrlAccessor オブジェクトの設計の多くは、構造が階層型かリンクベースかに依存します。 階層データ ストアの場合、 UrlAccessor オブジェクトは、その内容を列挙できるフィルターを見つける必要があります。 階層型とリンクベースのプロトコル ハンドラーのもう 1 つの違いは、IsDirectory メソッドの使用です。 リンク ベースのプロトコル ハンドラーでは、このメソッドはS_FALSEを返す必要があります。 階層型プロトコル ハンドラーは、コンテナーのS_OKを返す必要があります。
IUrlAccessor インターフェイスの実装手順については、IUrlAccessor インターフェイスのリファレンスを参照してください。
IProtocolHandlerSite
このインターフェイスは、 SearchProtocol オブジェクトをインスタンス化するために使用され、指定されたクラス ID (CLSID) に対する適切なフィルターを UrlAccessor オブジェクトに提供します。
コンテナーの IFilters
階層プロトコル ハンドラーを実装する場合は、コンテナーまたはフォルダーを表す URL を列挙するコンテナー IFilterコンポーネントを実装する必要があります。 列挙プロセスは、コンテナー内の各項目を表す URL の一覧を返す IFilter インターフェイスの GetChunk メソッドと GetValue メソッドをループ処理します。
最初に、 GetChunk は、プロパティが GATHER_PROPSETに設定された FULLPROSPEC を返します。次のいずれかを指定します。
- PID_GTHR_DIRLINK、最終変更時刻のないアイテムの URL、または
- PID_GTHR_DIRLINK_WITH_TIME、URL と最終変更時刻
GATHER_PROPSETのプロパティ セット GUID は 0B63E343-9CCC-11D0-BCDB-00805FCCCE04 です。 PROPSPEC プロパティは、PID_GTHR_DIRLINK=2 または PID_GTHR_DIRLINK_WITH_TIME = 12 decimal のいずれかです。
ISearchProtocol-CreateUrlAccessor() メソッドと IUrlAccessor-GetLastModified>>() メソッドを呼び出さずに、インデクサーがアイテムのインデックスを作成する必要があるかどうかをすぐに判断できるため、PID_GTHR_DIRLINK_WITH_TIMEを返す方が効率的です。
次 に、GetValue は URL の PROPVARIANT (および最後に変更された時刻を使用した場合) を次のように返します。
- VT_LPWSTR、子項目の URL、または
- URL の後に FILETIME が続くベクター
次のサンプル コードは、適切なPID_GTHR_DIRLINK_WITH_TIMEを構築する方法を示しています。
Note
このコードと情報は、商品性や特定の目的に対する適合性に関する黙示の保証を含むがこれらに限定されない、明示または黙示を問わず、いかなる種類の保証もなく「現状有姿」で提供されます。
Copyright (C) Microsoft。 All rights reserved.
// params are assumed to be valid
HRESULT GetPropVariantForUrlAndTime(PCWSTR pszUrl, const FILETIME &ftLastModified, PROPVARIANT **ppPropValue)
{
*ppPropValue = NULL;
// allocate the propvariant pointer
*ppPropValue = (PROPVARIANT *)CoTaskMemAlloc(sizeof(*ppPropValue));
HRESULT hr = *ppPropValue ? S_OK : E_OUTOFMEMORY;
if (SUCCEEDED(hr))
{
PropVariantInit(*ppPropValue); // zero init the value
// now allocate enough memory for 2 nested PropVariants.
// PID_GTHR_DIRLINK_WITH_TIME is an array of 2 PROPVARIANTs
PROPVARIANT *pVector = (PROPVARIANT *)CoTaskMemAlloc(sizeof(*pVector) * 2);
hr = pVector ? S_OK : E_OUTOFMEMORY;
if (SUCCEEDED(hr))
{
// set the container PROPVARIANT that it is a vector of 2 PROPVARIANTS
(*ppPropValue)->vt = VT_VARIANT | VT_VECTOR;
(*ppPropValue)->capropvar.cElems = 2;
(*ppPropValue)->capropvar.pElems = pVector;
PWSTR pszUrlAlloc;
hr = SHStrDup(pszUrl, &pszUrlAlloc);
if (SUCCEEDED(hr))
{
// now fill the array of PROPVARIANTS
// put the pointer to the URL into the vector
(*ppPropValue)->capropvar.pElems[0].vt = VT_LPWSTR;
(*ppPropValue)->capropvar.pElems[0].pwszVal = pszUrlAlloc;
// put the FILETIME into vector
(*ppPropValue)->capropvar.pElems[1].vt = VT_FILETIME;
(*ppPropValue)->capropvar.pElems[1].filetime = ftLastModified;
}
else
{
CoTaskMemFree(pVector);
}
}
if (FAILED(hr))
{
CoTaskMemFree(*ppPropValue);
*ppPropValue = NULL;
}
}
return S_OK;
}
注意
コンテナー IFilterコンポーネントは、子 URL が変更されていない場合でも、すべての子 URL を常に列挙する必要があります。これは、インデクサーが列挙プロセスを通じて削除を検出するためです。 DIR_LINKS_WITH_TIMEの日付出力がデータが変更されていないことを示している場合、インデクサーはその URL のデータを更新しません。
物理 URL は、 UrlAccessor オブジェクトが処理する URL です。 フィルターがユーザー フレンドリな DisplayUrl を出力しない場合、WDS は検索結果の一部としてユーザーへの物理 URL を表示します。 WDS スキーマには、次の表に示すように、エンド ユーザーに表示される内容を制御する 2 つのプロパティが含まれています。
| GUID | PROPSPEC | Description |
|---|---|---|
| D5CDD505-2E9C-101B-9397-08002B2CF9AE | DisplayFolder | 検索結果にユーザーに表示されるフォルダー パス |
| D5CDD505-2E9C-101B-9397-08002B2CF9AE | FolderName | 親フォルダーの表示名 |
コードで DisplayFolder または FolderName が出力されない場合、これらの値は DisplayUrl から計算されます。 URL のスラッシュは、ストアまたはファイル システム内のコンテナーを表します。
プロトコル ハンドラー オプション機能の追加
プロトコル ハンドラーに既定のスタート ページ (およびエントリ ノード URL) を設定するには、 ISearchProtocolOptions インターフェイスを実装する必要があります。 WDS の将来のバージョンでは、このインターフェイスは、ユーザー エクスペリエンスを向上させるために [オプション] ダイアログにフックを提供します。 このインターフェイスには、次の機能があります。
- プロトコル ハンドラーの要件が満たされているかどうかを判断します。 たとえば、プロトコル ハンドラーのストアでは、アプリケーションのデータに適切にインデックスを付けるために特定のアプリケーションへのアクセスが必要になる場合がありますが、そのアプリケーションは使用できません。
- プロトコル ハンドラーが項目を処理するために必要な最小要件を識別します。 要件は、"Microsoft Outlook 2000 以上" などのわかりやすいローカライズされた説明で表すことができます。
- プロトコル ハンドラーが既定で処理する URL を定義します。
ISearchProtocolOptions
次の表では、 ISearchProtocolOptions インターフェイスに実装する必要があるメソッドについて説明します。
| メソッド | 説明 |
|---|---|
| CheckRequirements | カスタム プロトコル ハンドラーの最小要件が満たされているかどうかを判断します |
| GetDefaultCrawlScope | カスタム プロトコル ハンドラーの指定されたストア内の既定の URL の一覧を返します |
| GetRequirements | カスタム プロトコル ハンドラーの最小要件に関するユーザー フレンドリでローカライズされた説明を識別します |
関連トピック
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示