了解协议处理程序
某些应用程序将其项存储在数据库或自定义文件类型中。 虽然 Windows Search 可以为文件的名称和属性编制索引，但 Windows 不知道文件的内容。 因此，无法在 Windows Shell 中为此类项编制索引或将其公开。 通过创建协议处理程序，可以使这些项可用于索引编制。 还可以为复合文件格式（如 .zip 文件）编制索引。
本主题的组织方式如下：
使用协议处理程序为数据存储编制索引
当用户需要搜索旧数据库、电子邮件存储或其他 Windows Search 不支持的数据结构时，应首先确定该数据存储的协议处理程序是否已存在，可以与其他应用程序（如 SharePoint Server）一起使用。 如果存在，可以在系统上安装该协议处理程序。 Windows Search 协议处理程序使用与 SharePoint Server 类似的设计规范，并且它们通常可以互换使用。
有关使用 Office SharePoint Server 2007 部署 Search Server 2008 的详细信息，请参阅联合搜索 [Search Server 2008]。
Shell 数据存储
开发新文件格式和数据存储的第三方开发人员能够在 Windows 资源管理器的查询结果中显示这些格式和存储之前，开发人员必须实现 Shell 数据源。 Shell 数据源是一个组件，用于扩展 Shell 命名空间并公开数据存储中的项。 数据存储是数据的存储库。 数据存储可以作为使用 Shell 数据源的容器公开给 Shell 编程模型。 数据存储中的项可以由 Windows Search 系统使用协议处理程序编制索引。 协议处理程序实现以本机格式访问内容源的协议。 ISearchProtocol 和 ISearchProtocol2 接口用于实现自定义协议处理程序，以便扩展可编制索引的数据源。
如果希望查询结果显示在 Windows 资源管理器中，必须先实现 Shell 数据源，然后才能创建协议处理程序来扩展索引。 但是，如果所有查询都采用编程方式（例如通过 OLE DB），并由应用程序的代码而不是 Shell 来解释，那么 Shell 命名空间仍然是首选，但不严格要求。
注意
Shell 数据源有时称为 Shell 命名空间扩展。 处理程序有时称为 Shell 扩展或 Shell 扩展处理程序。
如果希望用户从 Windows 资源管理器中查看其搜索结果，则必须创建协议处理程序及以下一个或多个加载项：
- 快捷菜单处理程序
- 图标处理程序
- 一些其他类型的文件处理程序
有关由尝试实现的开发人员场景标识的处理程序列表，请参阅 Windows Search 作为开发平台中的“处理程序概述”。 有关创建处理程序的信息，请参阅注册 Shell 扩展、快捷菜单和文件类型处理程序。
协议处理程序
如果数据存储也是容器（如文件系统文件夹），则必须实现筛选器来枚举容器中的 URL。 如果数据存储包含的数据或文件类型不是 Windows Search 支持的 200 种文件类型之一，则必须实现筛选器来访问存储中项的内容并为其编制索引。 Windows Search 使用的协议处理程序和 IFilter 技术与 SharePoint Server 所用的类似。 如果在要编制索引的系统上安装了针对存储和文件类型的特定筛选器，Windows Search 可能能够使用现有接口为此数据编制索引。
有关索引编制过程的概述，请参阅索引过程。 有关筛选器处理程序的概念信息，请参阅开发筛选器处理程序。
筛选器和协议处理程序
借助协议处理程序，Windows Search 索引器可以访问数据存储，使索引器能够对数据存储的节点进行爬网，并将相关信息提取到索引。 例如，Windows Search 附带了用于文件系统存储和 Microsoft Outlook 数据存储的某些版本的协议处理程序。 为 Outlook 电子邮件编制索引时，协议处理程序将爬网一组 Outlook 文件夹中的所有邮件，并从每个邮件及附件中提取信息。 此信息将传递给索引器以包含在 Windows Search 目录中。
有关 Catalog Manager 和 Crawl Scope Manager (CSM)的概述，请参阅使用 Catalog Manager 和使用 Crawl Scope Manager。
为复合文件格式编制索引
复合文件格式可以编制索引，以便文件中的各个项可以作为单个结果返回。 复合文件格式（如扩展名为 .zip 的压缩文件）实质上是数据存储，因此可以将其视为数据存储来编制索引。 以下示例显示文件系统命名空间中的一个 .zip 文件 (FILE://c:/test/test.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 筛选器并由 .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/ should emit 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 文件的 URL 开始，因为不知道每个 .zip 文件的位置。 因此，.zip 协议处理程序的起始页 URL 必须能够枚举所有 .zip 文件的转义路径根目录下的所有内容。 这些 .zip 文件不一定位于 FILE: 命名空间中，例如可以是指向 .zip 文件作为附件的 MAPI 类型 URL。
将根目录注册为起始页的步骤：
将根目录（例如 .zip:///）注册为起始页，以便所有 .zip 文件都从此处开始生效。 处理根 .zip: URL 时，协议处理程序应生成要发出的子 URL 列表，方法是查询 Windows Search 以查找所有包含 System.FileExtension =“.zip”的 URL。
转义这些 URL 以删除斜杠并将其作为子 URL 返回。 检索所需类型的示例查询如下所示。
SELECT system.itemurl, System.DateModified FROM SystemIndex WHERE System.FileExtension='.zip' OR System.MimeType='mimetypefor.zip'当 Windows Search 定期对 .zip:/// 根 URL 执行增量爬网时，必须返回 Windows Search 已经维护的 .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 Search 的属性处理程序。
- 只要调用 IFilter 实现，都是因为该 URL 已被发现或更改。 然后，通过 IGatherNotifyInline 接口为适用于源 URL 的 .zip URL 生成事件。 这样能够立即告知索引器有新数据需要编制索引，而无需等待增量爬网。
相关主题
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈