Сначала вам нужно будет закодировать сам IFilter.
Эта статья довольно хорошая , и она также ссылается на некоторые хорошие статьи.
IFilter.org
Также смотрите этот набор статей
Далее следует вопрос о предварительной обработке.
Самый простой способ, который я могу придумать, - это создать FileSystemWatcher , чтобы начать предварительную обработку документа.
Препроцессор может анализировать текст из документа и сохранять его где-то.
Это "где-то" становится следующей проблемой, и это в первую очередь деловое решение.
Если каталог для документов можно добавить, я бы добавил каталог Index в каждую папку при анализе документов и сохранял внутри файл, например [OriginalFilenameSansExtemsion] _index.txt.
Если это невозможно, создайте папку Index на каждом диске и при необходимости отразите структуру каталогов.
В конце концов, все, что вам нужно, - это чтобы IFilter мог определить, основываясь на имени файла индексируемого файла, где искать текстовый документ с предварительно обработанным содержимым.
Когда работает IFilter, вызывается Init. Когда это происходит, просто загрузите текстовый документ и верните его содержимое при вызове функций GetChunk, GetText и GetValue.
Это решение приведет к неявной зависимости между препроцессором и IFilter, так как они оба будут хранить свой собственный способ «поиска» индексного документа.
Должно быть возможно хранить расположение индексных документов в некотором общем расположении конфигурации.
Обновление
Как будет вызываться метод IFilter в поисковом сервере?
После создания IFilter должен быть установлен на сервере индексирования (т.е. соответствующая dll должна быть зарегистрирована).
Используя эту статью в качестве руководства, как часть вашей реализации, вы дадите своему фильтру уникальное руководство для его CLSID.
Процесс регистрации будет аналогичен этому, только с использованием другого расширения и guid.
ШАГ 1: КОМ-РЕГИСТРАЦИЯ
1.Добавить ключ реестра: HKEY_CLASSES_ROOT \ CLSID \
ThreadingModel: Оба
ШАГ 2: РЕГИСТРАЦИЯ IFILTER С ОС
Для регистрации
отображение расширения фильтра с ОС:
- HKEY_CLASSES_ROOT \ <. Ext> (по умолчанию) ->
- HKEY_CLASSES_ROOT \ (по умолчанию)
->
- HKEY_CLASSES_ROOT \\ PersistentHandler (по умолчанию)
->
- HKEY_CLASSES_ROOT \\ PersistentHandler \ PersistentAddinsRegistered \ IID_IFilter \
(По умолчанию) ->
Теперь все готово для
продукт с WSS (Windows Sharepoint
Службы) или MOSS (Microsoft Office
Сервер Sharepoint).
ШАГ 3: РЕГИСТРАЦИЯ ПРОДЛЕНИЯ ФИЛЬТРА С
MOSS
Добавить расширение фильтра к типам файлов для обхода: Пуск ->
Программа -> Microsoft Office Server ->
Центр администрирования SharePoint 3.0
-> -> Настройки поиска -> Типы файлов -> Новый
Тип файла (Добавить расширение здесь)
Добавьте следующие ключи реестра:
[HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Office
Server \ 12,0
\ Поиск \ Приложения \\ Собрать \ Portal_Content \ Extensions \ ExtensionList]
[HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Office
Server \ 12.0 \ Search \ Setup \ Filters.ext]
По умолчанию = (значение не установлено)
Расширение =
FileTypeBucket REG_DWORD = 0x00000001 (1)
MimeTypes =
[HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Office
Server \ 12.0 \ Search \ Setup \ ContentIndexCommon \ Filters \ Extension.ext]
По умолчанию REG_MULTI_SZ = IFIlter CLASSID
Наконец, перезапустите службу поиска, выполнив следующую команду
из командного окна:
D:> net stop osearch
D:> net start osearch
Передает ли поисковый сервер URL-адрес, а не локальное имя файла?
Функция LoadIFilter - это то, где у вас будет путь к файлу. Именно здесь вы создаете экземпляр IFilter, который читает индексированный текст вместо фактического файла.
Что я буду делать, если он вызовет IFilter :: Init для URL, который еще не проиндексирован?
Если индексированный файл не существует, вы не сможете выполнить индексирование, поэтому верните один из доступных кодов ошибок .
Приложение предварительной обработки должно будет извлечь текст из документа, если это занимает много времени. Текст должен быть сохранен там, где IFilter может получить к нему доступ, когда дело доходит до обработки файла во время функции LoadIFilter (которая передается в url / filepath файла приложением поиска). Используя url / filepath файла, Ifilter должен уметь определять, где находится ранее извлеченный текст.
Когда IFilter тогда может загружать текст и анализировать его вместо «фактического» файла. Отказ от необходимости длительного поиска обхода.
Если вы не собираетесь использовать препроцессор для создания целых сайтов, потребуется несколько проходов поискового искателя, чтобы получить то, что вам нужно.
Предположим, что сканер выполняет пошаговое сканирование каждый вечер.
В первый день добавления файла инкрементный обход берет файл и передает его в LoadIFilter. Функция ищет и не видит предварительно обработанный текст для файла, поэтому добавляет путь к файлу конфигурации (или списку) и возвращает код ошибки.
Файл не добавляется в результаты поиска.
Препроцессор в другое время просматривает список конфигурации, видит, что существует файл для обработки, и начинает работу. когда он закончил, он сохраняет текст и удаляет файл из списка конфигурации.
При следующем запуске искатель найдет файл и сохраненный текст для анализа.
Этот процесс начинает становиться немного сложным, и я бы беспокоился о том, чтобы сканер и препроцессор так хорошо взаимодействовали. Кроме того, при инкрементном сканировании может потребоваться предварительный процессор, чтобы «прикоснуться» к файлу после извлечения текста.
На данный момент, может быть, лучше что-то разработать и посмотреть, как это происходит, поскольку пока это просто теоретический алгоритм.
Надеюсь, это полезно.