Windows 搜尋服務中的編制索引程式
本主題描述編制索引程式的三個階段和每個相關的主要元件、說明編制索引活動的時機，並為想要為其資料存放區或檔案格式編制索引的協力廠商開發人員提供一些注意事項。
本主題的組織方式如下：
概觀
Windows 搜尋支援從不同檔案格式的檔案編制屬性和內容索引，例如.doc或 .jpeg 格式，以及資料存放區，例如檔案系統或 Windows Outlook 信箱。 有兩種索引：值索引允許依屬性的整個值進行篩選和排序，以及索引文字屬性或內容內單字的反轉索引。 如果您有自訂檔案格式或資料存放區，您必須瞭解 Windows 搜尋索引如何編制索引，才能正確編制專案索引。
索引程式會在三個階段中執行，由稱為收集程式的 Windows 搜尋元件所控制。 在第一個階段中，收集程式會將 URL 新增至佇列。 URL 會識別要編制索引的專案，而且佇列只是 URL 的優先順序清單。 在第二個階段中，收集程式會協調其他 Windows 搜尋和協力廠商元件，以存取專案並收集其相關資料。 最後，在第三個階段中，收集的資料會新增至索引。
下圖顯示透過編制索引程式的主要元件和資料流程。 一些元件涉及收集索引的資料。 其中有些是 Windows 搜尋的一部分，有些來自協力廠商應用程式。 如果您有自訂資料存放區或檔案格式，Windows 搜尋會依賴您的通訊協定處理常式和篩選準則來存取 URL，併發出屬性以供編制索引。 Windows 搜尋元件會以藍色顯示，而協力廠商元件則會以綠色顯示。
階段 1：佇列索引的 URL
在編制索引的第一個階段中，收集程式會收集資料存放區更新的相關資訊、將該資訊與已知的編目範圍進行比較，然後建置 URL 佇列以周遊以收集索引的資料。 對於不是以通知為基礎的來源，例如 FAT 磁片磁碟機，收集程式會定期起始編目範圍的完整周遊，讓索引中的資料保持最新狀態。 對於 NTFS 之類的來源，只有單一編目，而其他所有專案則由 USN 變更日誌的通知處理。 Microsoft Outlook 也沒有任何編目。 下圖顯示非編目索引的佇列程式高階檢視。
本節的其餘部分說明 Windows 搜尋如何決定要編目哪些 URL，並定義一些重要的字詞。
編目範圍 編目範圍是一組 URL，Windows 搜尋會周遊以收集使用者想要編制索引以取得更快速搜尋之專案的相關資料。 Windows 搜尋預設會將一些 URL 新增至編目範圍，例如使用者 [檔 ] 和 [ 圖片] 資料夾的路徑。 協力廠商應用程式、使用者和群組原則可以新增其他 URL。 最後，使用者和群組原則都可以明確地排除 URL。 Windows 搜尋會採用所有新增的 URL，並移除排除的 URL 以判斷編目範圍。 這是收集程式開始其工作的一組工作 URL。
採集 收集程式是 Windows 搜尋元件，可收集編目範圍內 URL 的相關資訊，並建立索引子要編目的 URL 佇列。 新增、刪除或更新編目範圍中的專案時，資料存放區的通知提供者會通知收集程式。 收集程式會從編目範圍根目錄開始進行初始搜耙。 URL 會傳遞至通訊協定處理常式，然後傳遞至適當的 IFilter。 篩選通常是會產生更多 URL 的目錄列舉。 通知是穩定狀態。 一般而言，每個資料存放區都有自己的通訊協定處理常式，可提供這些通知。 例如，在本機檔案系統上， USN 變更日誌 會作為 file:// 通訊協定下所有 URL 的通知提供者。 同樣地，Microsoft Outlook 可作為 mapi:// 通訊協定下所有 URL 的通知提供者。 當使用者收到、移動或刪除電子郵件時，Outlook 會通知收集者電子郵件的變更狀態。 從這些通知中，收集程式會建立要編目之 URL 的索引佇列。
編制佇列的索引 索引佇列是 URL 的清單，可識別需要編制索引或重新編制索引的專案。 收集程式會比較它從通知提供者收到的 URL 與編目範圍中的 URL。 來自屬於編目範圍之通知提供者的每個 URL 都會新增至收集程式用來排定下一個 URL 的優先順序的佇列。
有三個佇列：高優先順序通知、一般通知和定期搜耙。 高優先順序佇列適用于應立即處理的通知。 例如，當使用者在 Windows 檔案總管中變更專案的標題屬性時，必須在變更之後立即更新 Windows 檔案總管檢視。 一般通知佇列適用于所有剩餘的變更通知。 通知佇列會在編目佇列之前處理，因為變更的專案較可能對使用者感興趣。 收集程式會先存取每個佇列上 URL 的資料，先 (FIFO) 順序。
如需有關 Windows 7 中引進之優先順序和事件 API 的詳細資訊，請參閱 在 Windows 7 中編制優先順序和資料列集事件索引。 如需編目範圍管理和通知的詳細資訊，請參閱 提供變更通知 和使用 編目範圍管理員。
階段 2：編目 URL
在編制索引的第二個階段中，收集程式會透過佇列進行編目、存取資料存放區和擷取專案資料流程。 首先，收集程式會尋找每個 URL 的適當通訊協定處理常式。 然後，收集程式會將 URL 傳遞至通訊協定處理常式。 通訊協定處理常式會存取專案，並將專案中繼資料傳回收集程式。 收集程式會使用中繼資料來識別正確的篩選。
下圖顯示 URL 編目程式的高階檢視。 此階段包含元件之間的大量協調和通訊。
本節的其餘部分說明 Windows 搜尋如何存取專案以進行編制索引，並說明涉及之每個元件的角色。
採集 在階段 2 中，搜耙階段的收集程式會處理佇列中的 URL，從高優先順序佇列開始。 系統會檢查每個 URL 以識別其通訊協定。 然後，收集程式會查閱註冊該通訊協定的通訊協定處理常式，並在搜尋通訊協定主機進程中具現化它。
搜尋通訊協定主機 搜尋通訊協定主機只是用於通訊協定處理常式的 Boxed 主機進程。 一般而言，Windows 搜尋會建立兩個這類主機進程，一個是在系統安全性內容中執行，另一個是在使用者安全性內容中執行。 此區隔可確保使用者特定的資料永遠不會在系統內容中執行。
Windows 搜尋也會使用主機進程，將通訊協定處理常式的實例與其他進程或應用程式隔離。 如此一來，外部應用程式就無法存取通訊協定處理常式的特定實例，如果通訊協定處理常式意外失敗，則只會影響編制索引進程。 由於主機進程會執行協力廠商程式碼 (通訊協定處理常式) ，Windows 搜尋會定期回收程式，以將成功攻擊必須在程式中惡意探索資訊的時間降到最低。 除此之外，搜尋通訊協定主機不會影響 URL 的編目或專案的索引編制。
通訊協定處理常式 通訊協定處理常式會使用資料存放區的通訊協定來存取資料存放區中的專案。 例如，NTFS 通訊協定處理常式會使用 file:// 通訊協定來存取本機磁片磁碟機上的檔案。 通訊協定處理常式知道如何周遊資料存放區、識別新的或更新的專案，以及通知收集程式。 然後，當編目開始時，通訊協定處理常式會將 IUrlAccessor 物件提供給收集程式，以系結至專案的基礎資料流程，並傳回專案中繼資料，例如安全性限制和上次修改時間。
注意
通訊協定處理常式不是 Windows 搜尋元件;它們是特定通訊協定的元件，以及其設計用來存取的資料存放區。 如果您有想要編制索引的自訂資料存放區，則需要實作通訊協定處理常式。 如需通訊協定處理常式以及如何實作的詳細資訊，請參閱 開發通訊協定處理常式。
中繼資料和資料流程 使用通訊協定處理常式 的 IUrlAccessor 物件所傳回的中繼資料，收集程式會識別 URL 的正確篩選。 收集程式會剖析專案的副檔名，並查閱為該副檔名註冊的篩選。 如果收集程式找不到篩選準則，Windows 搜尋會使用中繼資料來衍生一組最少的系統屬性資訊， (例如 System.ItemName) 並更新索引。 否則，如果收集程式找到篩選準則，就會開始編制索引的第三個階段。
階段 3：更新索引
在編制索引的第三個階段中，收集程式會具現化 URL 的正確篩選，並使用 來自 IUrlAccessor 物件的資料流程來初始化篩選。 篩選接著會存取專案，並傳回索引的內容。 如果您有自訂檔案格式，Windows 搜尋會依賴您的篩選來存取 URL，併發出內容和屬性以進行編制索引。
下圖顯示資料存取程式的高階檢視。 此階段包含元件之間的大量協調和通訊。
本節的其餘部分說明 Windows 搜尋如何存取專案資料以進行編制索引，並說明涉及之每個元件的角色。
採集 在這個階段開始時，收集程式的角色是具現化專案的正確篩選，並將專案資料流程傳遞給它。 在這個階段結束時，收集程式會取得篩選和屬性處理常式所發出的內容和屬性，並更新索引。
篩選主機 篩選主機只是篩選和屬性處理常式的主機進程，而且用途類似于搜尋通訊協定主機。 主機進程會基於搜尋通訊協定主機進程隔離通訊協定處理常式的相同安全性和穩定性原因，將篩選和屬性處理常式與系統的其餘部分隔離。 主機進程會以最低許可權執行， (甚至無法存取檔案系統) ，而且偶爾會回收以防範安全性攻擊。 Windows 搜尋也會監視資源使用量，因此，如果篩選準則耗用太多資源，則會回收主機進程。
過濾 器 篩選準則是編制索引程式中的重要元件，會發出收集程式的專案資訊。 篩選會命名為在其實作中使用的主體介面、 IFilter 介面，因此有時稱為 IFilters。 有兩種篩選：一種會與檔案等個別專案互動，另一種會與資料夾等容器互動。 兩者都提供索引的資料。
使用通訊協定處理常式 的 IUrlAccessor 物件所傳回的中繼資料，收集程式會識別特定 URL 的正確篩選，並將其傳遞至資料流程。 收集程式會透過通訊協定處理常式或副檔名、MIME 類型或類別識別碼來識別正確的篩選， (CLSID) 。 如果 URL 指向容器，篩選會發出容器的屬性，並列舉容器中的專案 (子 URL) 。 如果 URL 指向專案，則篩選準則會傳回文字內容，如果屬性的任何讀取且比屬性處理常式更複雜。 一般而言，我們建議篩選會在屬性處理常式發出專案屬性時發出專案內容。 不過，如果您的篩選準則需要使用無法辨識屬性處理常式的繼承應用程式，您也可以實作篩選來發出屬性。
注意
篩選不是 Windows 搜尋元件;它們是與特定檔案格式或容器相關的元件，其設計目的是要存取。 如需篩選以及如何針對自訂檔案格式或容器實作篩選的詳細資訊，請參閱 在 Windows 搜尋中建立篩選處理常式的最佳做法。
下表列出收集程式在編制索引過程中從篩選 (IFilter) 和屬性處理常式 (IPropertyStore) 接收的結果。
| IFilter | IPropertyStore | |
|---|---|---|
| 允許寫入 | 否 | 是 |
| 混合內容和屬性 | 是 | 否 |
| 多 語種 | 是 | 否 |
| 發出連結 | 是 | 否 |
| Mime | 是 | 否 |
| 文字界限 | 句子、段落、章節 | 無 |
| 用戶端/ 伺服器 | 兩者 | Client |
| 實作 | Complex | 簡單 |
屬性處理常式 屬性處理常式是可讀取和寫入特定檔案格式之屬性的元件。 它們會以篩選對內容所做的相同方式來存取專案併發出收集程式的屬性。 屬性處理常式比篩選更容易實作。 如果以文字為基礎的檔案格式非常簡單，或預期檔案非常小，則屬性處理常式可以發出屬性和內容。
注意
屬性處理常式不是 Windows 搜尋元件;它們是與設計來存取之特定檔案格式相關的元件。 如需屬性處理常式以及如何實作自訂檔案格式的詳細資訊，請參閱 開發 Windows 搜尋的屬性處理常式。
性能 Windows 搜尋提供 包含大型屬性程式庫的屬性系統 。 任何屬性都可以出現在篩選或屬性處理常式所定義的任何專案上。 如果您有自訂檔案格式，您可以將檔案格式的屬性對應至這些系統屬性，也可以建立新的自訂屬性。 當您的篩選或屬性處理常式發出這些屬性時，收集程式會更新索引，讓使用者可以使用您的屬性進行搜尋。 如需建立及註冊檔案格式之自訂屬性的詳細資訊，請參閱 屬性系統。
SystemIndex 名為 SystemIndex 的索引會儲存索引資料，並且由屬性存放區組成，並針對專案屬性的屬性和內容編制索引，以及文字內容和屬性的反轉索引。 收集程式更新索引之後，Windows 搜尋和其他應用程式即可查詢索引。 如需查詢索引方式的詳細資訊，請參閱 以程式設計方式查詢索引。
注意
請記住，當您重新註冊架構時，索引子可能不會遵守對先前定義屬性的屬性所做的變更。 解決方案是重建索引，或引進反映變更的新屬性，而不是更新舊屬性， (不建議) 。 如需詳細資訊，請參閱屬性系統概觀中的實作者注意事項。
如何排程索引
第一次安裝 Windows 搜尋時，它會執行編目範圍的完整索引，並在高 I/O 和使用者活動期間暫停。 預設編目範圍包含預設媒體櫃位置，例如 檔、 音樂、 圖片和 影片。 即使在完成初始編目之前，也會處理通知。 有時候，收集程式會從完整編目範圍搜耙 URL。 這些完整編目可確保索引中的資料是全新的。 例如，如果通知提供者無法傳送通知，或 Windows 搜尋服務意外終止，則收集程式不會知道新的或已變更的專案，而且不會編制這些專案的索引。 有兩種來源：僅限通知和啟用通知。 在這兩個來源中，收集程式一開始會編目索引。 在初始搜耙之後，除非發生失敗，例如 USN 變更日誌 變換，否則通知專用來源永遠不會再次執行完整編目。 啟用通知的來源會在索引子啟動時執行累加搜耙，但在執行時接聽通知。 NTFS 和 Microsoft Outlook 只是通知。 Internet Explorer 和 FAT 已啟用通知。
給實施者的注意事項
索引中的資料品質，以及編制索引程式的效率，主要取決於您的篩選和屬性處理常式實作。 由於每次 URL 識別檔案格式時都會呼叫篩選準則，因此如果您的篩選效率不佳，索引程式可能會大幅降低速度。 如果您的屬性處理常式未正確將所有檔案屬性對應至系統屬性，或未正確發出這些屬性，索引中的資料將會不正確，而稍後搜尋這些屬性會傳回不正確的結果。 如果您的篩選或屬性處理常式失敗，索引子將無法為數據編制索引。
Windows 搜尋服務以外的應用程式和進程依賴通訊協定處理常式、篩選和屬性處理常式。 您的實作可能會以您不預期的方式影響這些應用程式。 Windows 搜尋開發指南提供設計選擇和測試每個元件的建議。
相關主題
意見反應
即將登場：在 2024 年，我們將逐步淘汰 GitHub 問題作為內容的意見反應機制，並將它取代為新的意見反應系統。 如需詳細資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交並檢視相關的意見反應