瞭解通訊協定處理常式
某些應用程式會將其專案儲存在資料庫或自訂檔案類型中。 雖然 Windows 搜尋可以編制檔案的名稱和屬性的索引,但 Windows 並不知道檔案的內容。 因此,這類專案無法在 Windows 殼層中編制索引或公開。 藉由建立通訊協定處理常式,您可以讓這些專案可供編制索引。 您也可以為複合檔案格式編制索引,例如 .zip 檔案。
本主題的組織方式如下:
使用通訊協定處理常式編制資料存放區的索引
當使用者需要搜尋舊版資料庫、電子郵件存放區或其他 Windows 搜尋不支援的資料結構時,您應該先判斷該資料存放區的通訊協定處理常式是否已經存在,或許可與 SharePoint Server 等其他應用程式搭配使用。 如果是,您可以在系統上安裝該通訊協定處理常式。 Windows 搜尋通訊協定處理常式會使用類似于 SharePoint Server 的設計規格,而且通常可以交替使用。
如需使用 Office SharePoint Server 2007 部署 Search Server 2008 的詳細資訊,請參閱 同盟搜尋 [Search Server 2008] 。
Shell 資料存放區
在新的檔案格式和資料存放區的協力廠商開發人員可以取得這些格式和資料存放區,才能在 Windows 檔案總管中出現在查詢結果中,開發人員必須實作 Shell 資料來源。 Shell 資料來源是用來擴充 Shell 命名空間並公開資料存放區中專案的元件。 資料存放區是資料的存放庫。 資料存放區可以公開至 Shell 程式設計模型,做為使用 Shell 資料來源的容器。 資料存放區中的專案可以使用通訊協定處理常式,由 Windows 搜尋系統編制索引。 通訊協定處理常式會實作通訊協定,以原生格式存取內容來源。 ISearchProtocol 和 ISearchProtocol2 介面可用來實作自訂通訊協定處理常式,以擴充可編制索引的資料來源。
如果您想要讓查詢結果出現在 Windows 檔案總管中,您必須先實作 Shell 資料來源,才能建立通訊協定處理常式來擴充索引。 不過,如果所有查詢都會以程式設計方式進行(例如透過 OLE DB),並由應用程式的程式碼而非 Shell 解譯,則不需要絕對需要殼層命名空間。
注意
Shell 資料來源有時稱為 Shell 命名空間延伸模組。 處理常式有時稱為殼層延伸模組或 Shell 延伸模組處理常式。
如果您想要讓使用者從 Windows 檔案總管中檢視其搜尋結果,則必須建立通訊協定處理常式和下列一或多個增益集:
- 快顯功能表處理常式
- 圖示處理常式
- 一些其他類型的檔案處理常式
如需您嘗試達成之開發人員案例所識別的處理常式清單,請參閱 Windows 搜尋即開發平臺 中的 「處理常式概觀」。 如需建立處理常式的資訊,請參閱 註冊殼層延伸模組 、 操作功能表 和 檔案類型處理常式 。
通訊協定處理常式
如果資料存放區也是容器(例如檔系統資料夾),您必須實作篩選來列舉容器中的 URL。 如果資料存放區包含 Windows 搜尋所支援之 200 個檔案類型之一以外的資料或檔案類型,您必須實作篩選來存取和編制存放區中專案內容的索引。 Windows 搜尋會使用通訊協定處理常式和 IFilter 技術,類似于 SharePoint Server 所使用的技術。 如果您已經針對要編制索引的系統上已安裝特定存放區和檔案類型的篩選,Windows 搜尋可能會使用現有的介面來編制此資料的索引。
如需編制索引程式的概觀,請參閱 編制索引程式 。 如需篩選處理常式的概念資訊,請參閱 開發篩選處理常式 。
篩選和通訊協定處理常式
通訊協定處理常式可讓 Windows 搜尋服務索引子存取資料存放區,讓索引子能夠編目資料存放區的節點,並將相關資訊擷取至索引。 例如,Windows 搜尋隨附檔案系統存放區的通訊協定處理常式,以及 Microsoft Outlook 資料存放區的某些版本。 編制 Outlook 電子郵件索引時,通訊協定處理常式會編目一組 Outlook 資料夾中的所有郵件,並從每個郵件和附件擷取資訊。 這項資訊會傳遞至索引子,以包含在 Windows 搜尋目錄中。
如需目錄管理員和編目範圍管理員的概觀,請參閱 使用目錄管理員 和使用 編目範圍管理員 。
編制複合檔案格式的索引
複合檔案格式可以編制索引,以便將檔案中的個別專案當做個別結果傳回。 複合檔案格式,例如副檔名為 .zip 的壓縮檔案,基本上是資料存放區,因此可以視為索引編制目的。 下列範例會在檔案系統命名空間 (FILE://c:/test/test.zip) 中顯示 .zip 檔案,其中同時有子資料夾和個別專案。
Test.zip
|-folder1
| |-folder2
| |- FileX.txt
|- FileY.doc
FILE 通訊協定處理常式會藉由監視檔案系統變更記錄來探索何時 FILE://c:/test/test.zip 變更,而且會在 檔案變更時叫用該檔案上為 .zip 檔案註冊的 IFilter ,但不知道 .zip 檔案本身的內部結構。
您必須通知索引子複合檔案格式是資料存放區。 若要將個別專案編制索引並擷取為唯一實體,就必須這麼做。 實作 Shell 資料來源並執行下列步驟之後,您將會有一個通訊協定處理常式,可將複合檔案格式 (.zip 檔案) 中的資料當作個別專案來處理和公開。
若要通知索引子複合檔案是資料存放區:
針對能夠系結至原始程式檔的 .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
請確定您的通訊協定處理常式符合下列兩個條件:
- .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 搜尋需要通訊協定的起始頁,才能知道要累加編目哪些 URL,以及找到 URL 時應該忽略哪些 URL。 但是我們無法從每個 .zip 檔案的 URL 開始,因為我們不知道每個 .zip 檔案的位置。 因此,.zip 通訊協定處理常式的起始頁 URL 必須能夠列舉所有 .zip 檔案之逸出路徑根目錄的所有專案。 例如,這些 .zip 檔案不一定位於 FILE:命名空間中,而且可能是指向 .zip 檔案作為附件的 MAPI 類型 URL。
若要將根目錄註冊為起始頁:
將 .zip:/// 之類的根目錄註冊為起始頁,讓所有 .zip 檔案都從該處開始,實際上。 處理根 .zip:URL 時,您的通訊協定處理常式應該會藉由查詢 Windows Search 來查詢 System.FileExtension = 「.zip」 的所有 URL,以產生要發出的子 URL 清單。
請逸出這些 URL 以移除斜線,並以子 URL 傳回它們。 擷取您想要類型的範例查詢,如下所示。
SELECT system.itemurl, System.DateModified FROM SystemIndex WHERE System.FileExtension='.zip' OR System.MimeType='mimetypefor.zip'
當 Windows 搜尋會定期對 .zip:/// 根 URL 執行累加編目時,您必須反映 Windows 搜尋已維護為 .zip URL 的 URL 清單。 如果在儲存 .zip 檔案的原生存放區中探索刪除,它就不會出現在您的列舉中,而且會移除 .zip 中樹狀結構的該分支。
若要系結至另一個通訊協定處理常式的 .zip 資料,您應該最好透過 IShellFolder 讓該 URL 系結至物件的儲存體,而不是假設它一律是檔案。 例如,這樣做可讓您彈性地處理郵件存放區中的附件。
針對每個 .zip 檔案發出子 URL 時,您應該使用 PKEY_Search_UrlToIndexWithModificationTime ( System.Search.UrlToIndexWithModificationTime ) 傳遞實際 .zip 檔案的 PKEY_DateModified ( System.DateModified ),讓索引子只有在變更時才能編目 .zip 檔案。
若要在建立或修改 .zip URL 之後立即編制索引,而不需要等候累加編目探索其新狀態,您可以自行監視檔案系統是否有 .zip 檔案變更。 不過,這種方法不適用於 MAPI 等其他資料存放區。
若要在建立或修改 .zip URL 時編制索引:
- 為 .ZIP 檔案類型建立篩選準則(以及 IFilter 介面的實作 )。 如需詳細資訊,請參閱 開發 Windows 搜尋 的屬性處理常式。
- 每當呼叫您的 IFilter 實作時,這是因為該 URL 已探索或變更。 然後,透過 IGatherNotifyInline 介面,為適用于來源 URL 的 .zip URL 產生事件。 這麼做可讓您立即告訴索引子有新的資料要編制索引,而不需要等候累加編目。
相關主題