Общие сведения о обработчиках протоколов
Некоторые приложения хранят свои элементы в базах данных или пользовательских типах файлов. Хотя поиск Windows может индексировать имя и свойства файла, Windows не знает о содержимом файла. В результате такие элементы нельзя индексировать или отображать в оболочке Windows. Создав обработчик протокола, вы можете сделать эти элементы доступными для индексирования. Можно также индексировать составной формат файла, например файл .zip.
Этот раздел организован следующим образом:
- индексирование хранилищ данных с помощью обработчиков протоколов
- индексирование составного формата файлов
- Связанные темы
Индексирование хранилищ данных с помощью обработчиков протоколов
Когда пользователям нужно искать устаревшие базы данных, почтовые хранилища или другие структуры данных, которые не поддерживаются поиском Windows, сначала следует определить, существует ли обработчик протокола для этого хранилища данных, возможно, для использования с другим приложением, таким как SharePoint Server. В таком случае можно установить этот обработчик протокола в системе. Обработчики протокола Поиска Windows используют спецификации проектирования, аналогичные SharePoint Server, и часто их можно использовать взаимозаменяемо.
Дополнительные сведения о развертывании Search Server 2008 с Office SharePoint Server 2007 см. в разделе Федеративный Поиск [Search Server 2008].
Оболочечные хранилища данных
Прежде чем сторонний разработчик новых форматов файлов и хранилищ данных сможет сделать так, чтобы эти форматы и хранилища отображались в результатах запроса в Проводнике, он должен реализовать источник данных оболочки. Источник данных Shell — это компонент, который используется для расширения пространства имен оболочки и предоставления элементов в хранилище данных. Хранилище данных — это репозиторий данных. Хранилище данных можно предоставить программной модели Shell в качестве контейнера, использующего источник данных Shell. Элементы в хранилище данных можно индексировать системой поиска Windows с помощью обработчика протокола. Обработчик протокола реализует протокол для доступа к источнику содержимого в собственном формате. Интерфейсы ISearchProtocol и интерфейсы ISearchProtocol2 используются для реализации пользовательского обработчика протоколов для расширения источников данных, которые можно индексировать.
Если вы хотите, чтобы результаты запроса отображались в проводнике Windows, необходимо реализовать источник данных оболочки, прежде чем создать обработчик протокола для расширения индекса. Однако если все запросы будут программными (например, с помощью OLE DB) и будут интерпретироваться кодом приложения, а не оболочкой, то пространство имен оболочки, хотя и предпочтительно, не является строго обязательным.
Заметка
Источник данных Shell иногда называется расширением пространства имен Shell. Иногда обработчик называется расширением оболочки или обработчиком расширений оболочки.
Если вы хотите, чтобы пользователи просматривали результаты поиска из проводника Windows, необходимо создать обработчик протокола и одну или несколько следующих надстроек:
- Обработчик контекстного меню
- Обработчик значков
- Другой тип обработчика файлов
Список обработчиков, определенных сценарием разработчика, который вы хотите реализовать, см. в разделе "Обзор обработчиков" в Поиск Windows в качестве платформы разработки. Сведения о создании обработчиков см. в регистрации расширений оболочки, обработчиков контекстного менюи обработчиков типов файлов.
Обработчики протоколов
Если хранилище данных также является контейнером (например, папкой файловой системы), необходимо реализовать фильтр для перечисления URL-адресов в контейнере. Если хранилище данных содержит данные или типы файлов, отличные от одного из 200 типов файлов, поддерживаемых поиском Windows, необходимо реализовать фильтр для доступа к содержимому элементов в хранилище и индексировать его содержимое. Поиск Windows использует обработчик протокола и технологии IFilter, аналогичные технологии SharePoint Server. Если у вас уже есть фильтры для определенного хранилища и типа файлов, установленных в системе, поиск Windows может использовать существующие интерфейсы для индексирования этих данных.
Для получения обзора о процессе индексирования, см. Процесс индексирования. Общие сведения о обработчиках фильтров см. в разработки обработчиков фильтров.
Фильтры и обработчики протоколов
Обработчики протоколов предоставляют индексатору Windows Search доступ к хранилищам данных, что позволяет индексатору выполнять обход узлов хранилища данных и извлекать соответствующие сведения для индексирования. Например, поиск Windows поставляется с обработчиками протоколов для хранилищ файловой системы и для некоторых версий обоих хранилищ данных Microsoft Outlook. При индексировании электронной почты Outlook обработчик протокола выполняет обход всех сообщений в наборе папок Outlook и извлекает информацию из каждого сообщения и вложения. Эти сведения передаются индексатору для включения в каталог поиска Windows.
Общие сведения о диспетчере каталогов и диспетчере областей обхода контента (CSM) см. в использовании диспетчера каталогов и с помощью диспетчера областей обхода.
Индексирование составного формата файла
Составной формат файла можно индексировать таким образом, чтобы отдельные элементы в файле могли быть возвращены в виде отдельных результатов. Составной формат файла, например сжатый файл с расширением имени файла .zip, по сути, является хранилищем данных и может рассматриваться как такое для индексирования. В следующем примере отображается файл .zip в пространстве имен файловой системы (FILE://c:/test/test.zip), в котором есть как вложенные папки, так и отдельные элементы.
Test.zip
|-folder1
| |-folder2
| |- FileX.txt
|- FileY.doc
Обработчик протокола FILE замечает, когда в FILE://c:/test/test.zip происходят изменения, отслеживая журналы изменений файловой системы, и вызывает IFilter, зарегистрированный для .zip файлов, когда файл изменяется, но он не обладает информацией о внутренней структуре файла .zip.
Вы должны сообщить индексатору, что составной формат файла является хранилищем данных. Это необходимо сделать для индексирования и извлечения отдельных элементов в виде уникальных сущностей. После реализации источника данных оболочки и выполнения следующих действий у вас будет обработчик протокола, который может обрабатывать и предоставлять данные из составного формата файла (.zip файла) в виде отдельных элементов.
Чтобы сообщить индексатору, что составной файл является хранилищем данных:
Создайте обработчик протокола (с помощью ISearchProtocol или ISearchProtocol2) для файлов .zip с возможностью привязки к исходному файлу. Для получения дополнительной информации см. раздел «Установка и регистрация обработчиков протоколов».
Например, можно использовать экранированный путь к файлу .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Убедитесь, что обработчик протокола соответствует следующим двум условиям:
- Корневые URL-адреса для файла .zip должны выдавать PKEY_Search_IsClosedDirectory (System.Search.IsClosedDirectory) на URL-адресах, которые являются URL-адресами корневого .zip файла. Например, .zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/ должен выдавать IsClosedDirectory = TRUE. Это сообщает индексатору, что если дата на этом URL-адресе не изменилась, не нужно обрабатывать какие-либо дочерние URL-адреса.
- Каждый дочерний URL-адрес этого URL-адреса должен выдавать PKEY_Search_IsFullyContained (System.Search.IsFullyContained) на дочерних URL-адресах корневого .zip URL-адреса. Обычно в конце добавочного обхода индексатор обрабатывает все невидимые URL-адреса как элементы, которые следует удалить. Но корневой .zip-файл не должен обрабатывать корневые URL-адреса, так как ничего не изменилось. При установке этого свойства как TRUE это сигнализирует индексатору, что если этот URL-адрес не будет обработан к концу добавочного обхода, его не следует удалять. Он будет удален только в том случае, если корневой элемент изменился, и он не посещается.
Для поиска Windows требуется начальная страница для протокола, чтобы определить, какие URL следует сканировать постепенно, и какие URL игнорировать при их обнаружении. Но мы не можем начать с URL-адреса для каждого .zip файла, так как мы не знаем, где находится каждый .zip файл. Таким образом, URL-адрес начальной страницы обработчика протокола .zip должен быть в состоянии перечислить все в корне экранированных путей всех файлов .zip. Эти файлы .zip не обязательно находятся в пространстве имен FILE и могут представлять собой URL-адрес типа MAPI, например, указывающий на файл .zip в виде вложения.
Зарегистрировать главную страницу в качестве стартовой страницы:
Зарегистрируйте корень, например .zip:///, в качестве стартовой страницы, чтобы все файлы .zip загружались оттуда. При обработке корневого .zip: URL-адреса, обработчик протокола должен создать список дочерних URL-адресов, который будет выдаваться, запрашивая Windows Search о всех URL-адресах с расширением System.FileExtension =.zip.
Избежать этих URL-адресов, чтобы удалить косую черту и вернуть их в качестве дочерних URL-адресов. Пример запроса для получения нужных типов может выглядеть следующим образом.
SELECT system.itemurl, System.DateModified FROM SystemIndex WHERE System.FileExtension='.zip' OR System.MimeType='mimetypefor.zip'Когда поиск Windows периодически выполняет инкрементный обход корневого URL-адреса .zip:///, необходимо отразить список URL-адресов, которые поиск Windows уже поддерживает и которые являются URL-адресами .zip. Если в собственном хранилище, где хранится файл .zip, обнаруживается удаление, оно не отображается в перечислении, и эта ветвь дерева в .zip удаляется.
Чтобы привязаться к данным .zip для другого обработчика протокола, в идеале следует использовать IShellFolder, чтобы связать URL с хранилищем объекта, а не предполагать, что это всегда файл. Это обеспечивает гибкость работы с вложениями в почтовых магазинах, например.
При создании дочерних URL-адресов для каждого файла .zip следует использовать PKEY_Search_UrlToIndexWithModificationTime (System.Search.UrlToIndexWithModificationTime) для передачи PKEY_DateModified (System.DateModified) фактического .zip файла, чтобы индексатор обходил файл .zip только в том случае, если он изменился.
Чтобы .zip URL-адреса индексировались сразу после их создания или изменения и вам не пришлось ждать, пока добавочный обход обнаружит их новое состояние, вы можете самостоятельно отслеживать файловую систему на предмет .zip изменений файлов. Однако такой подход не будет работать для других хранилищ данных, таких как MAPI.
Чтобы url-адреса .zip индексировались при их создании или изменении:
- Создайте фильтр (и реализацию интерфейса IFilter) для типа файла .zip. Для получения дополнительной информации см. раздел о разработке обработчиков свойств для Windows Search.
- Всякий раз, когда вызывается реализация IFilter, это связано с тем, что этот URL-адрес был обнаружен или изменен. Затем создайте событие для URL-адреса .zip, подходящего для исходного URL-адреса, с помощью интерфейсаIGatherNotifyInline. Это дает возможность немедленно сообщить индексатору, что есть новые данные для индексирования, не ожидая добавочного обхода.
Связанные разделы