Общие сведения о обработчиках протоколов
Некоторые приложения хранят свои элементы в базах данных или пользовательских типах файлов. Хотя поиск Windows может индексировать имя и свойства файла, Windows не знает о содержимом файла. В результате такие элементы нельзя индексировать или предоставлять в оболочке Windows. Создав обработчик протокола, вы можете сделать эти элементы доступными для индексирования. Можно также индексировать составной формат файла, например ZIP-файл.
Этот раздел организован следующим образом:
- Индексирование хранилищ данных с помощью обработчиков протоколов
- Индексирование составного формата файла
- Связанные статьи
Индексирование хранилищ данных с помощью обработчиков протоколов
Когда пользователям нужно искать устаревшие базы данных, почтовые хранилища или другие структуры данных, которые не поддерживаются поиском Windows, сначала следует определить, существует ли обработчик протокола для этого хранилища данных, возможно, для использования с другим приложением, таким как SharePoint Server. В таком случае можно установить этот обработчик протокола в системе. Обработчики протокола Поиска Windows используют спецификации проектирования, аналогичные SharePoint Server, и часто их можно использовать взаимозаменяемо.
Дополнительные сведения о развертывании Search Server 2008 с Office SharePoint Server 2007 см. в статье "Федеративный поиск" [Search Server 2008].
Хранилища данных оболочки
Прежде чем сторонний разработчик новых форматов файлов и хранилищ данных может получить эти форматы и хранилища для отображения в результатах запроса в Windows Обозреватель, разработчик должен реализовать источник данных Оболочки. Источник данных Оболочки — это компонент, который используется для расширения пространства имен оболочки и предоставления элементов в хранилище данных. Хранилище данных — это репозиторий данных. Хранилище данных можно предоставить модели программирования Оболочки в качестве контейнера, использующего источник данных Оболочки. Элементы в хранилище данных можно индексировать системой поиска Windows с помощью обработчика протокола. Обработчик протокола реализует протокол для доступа к источнику содержимого в собственном формате. Интерфейсы ISearchProtocol и ISearchProtocol2 используются для реализации пользовательского обработчика протокола для расширения источников данных, которые можно индексировать.
Если вы хотите, чтобы результаты запроса отображались в Windows Обозреватель, необходимо реализовать источник данных оболочки, прежде чем создать обработчик протокола для расширения индекса. Однако если все запросы будут программными (например, с помощью OLE DB) и интерпретируются кодом приложения, а не оболочкой, пространство имен оболочки в то время как по-прежнему не требуется строго.
Примечание.
Источник данных Оболочки иногда называется расширением пространства имен оболочки. Иногда обработчик называется расширением оболочки или обработчиком расширений оболочки.
Если вы хотите, чтобы пользователи просматривали результаты поиска из 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-файлов с возможностью привязки к исходному файлу. Дополнительные сведения см. в разделе "Установка и регистрация обработчиков протокола".
Например, можно использовать escape-путь к 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-адресах корневого 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-файлы не обязательно находятся в пространстве имен: пространство имен и может быть URL-адрес типа MAPI, указывающий на ZIP-файл как вложение, например.
Чтобы зарегистрировать корневой каталог в качестве начальной страницы:
Зарегистрируйте корневой каталог, например .zip:/// в качестве начальной страницы, чтобы все ZIP-файлы запускались там. При обработке корневого ZIP-адреса обработчик протокола должен создать список дочерних URL-адресов, которые будут выдаваться путем запроса поиска Windows для всех 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-файл только в том случае, если он изменился.
Чтобы URL-адреса ZIP-файла индексировались сразу после их создания или изменения, и не придется ожидать добавочного обхода, чтобы обнаружить новое состояние, вы можете отслеживать файловую систему самостоятельно для изменения ZIP-файла. Однако такой подход не будет работать для других хранилищ данных, таких как MAPI.
Чтобы индексировать URL-адреса ZIP при их создании или изменении, выполните следующие действия.
- Создайте фильтр (и реализацию интерфейса IFilter ) для типа ZIP-файла. Дополнительные сведения см. в статье "Разработка обработчиков свойств для поиска Windows".
- Всякий раз, когда вызывается реализация IFilter , это связано с тем, что этот URL-адрес обнаружен или изменен. Затем создайте событие для ZIP-URL-адреса, соответствующего исходному URL-адресу, через интерфейс IGatherNotifyInline. Это дает возможность немедленно сообщить индексатору, что есть новые данные для индексирования, не ожидая добавочного обхода.
См. также