Udostępnij za pośrednictwem

Implementowanie programów obsługi filtrów w usłudze Windows Search

  • Artykuł

Ważne jest, aby zrozumieć wymaganą strukturę bibliotek DLL programu obsługi filtrów (implementacja interfejsu IFilter).

Ten temat jest zorganizowany w następujący sposób:

Implementowanie i eksportowanie punktów wejścia biblioteki DLL

Każda biblioteka DLL IFilter (oznaczona przez Ifilter.dll w tej sekcji) musi implementować i eksportować następujące punkty wejścia. Te punkty wejścia są zwykle eksportowane przy użyciu pliku definicji modułu (def) dla interfejsu IFilter lub za pomocą słowa kluczowego __declspec(dllexport). Plik DLL można zarejestrować w dowolnym folderze, ale zwykle znajduje się w folderze %SystemRoot%\system32.

Punkty wejścia do bibliotek DLL są wymienione i opisane w poniższej tabeli.

Nazwa biblioteki DLL Opis biblioteki DLL
DllRegisterServer Punkt wejścia DllRegisterServer rejestruje bibliotekę DLL jako filtr w rejestrze. Bibliotekę DLL należy zarejestrować, uruchamiając program regsvr32.exe z nazwą pliku DLL interfejsu IFilter jako argumentem: regsvr32.exe %SystemRoot%\system32\Ifilter.dll
DllUnregisterServer, funkcja Funkcja DllUnregisterServer usuwa bibliotekę DLL jako trwały identyfikator w rejestrze w punkcie wejścia. Wyrejestruj bibliotekę DLL, uruchamiając program regsvr32.exe z flagą /u: regsvr32.exe /u %SystemRoot%\system32\Ifilter.dll
Funkcja DllGetClassObject Klient indeksowania zawartości wywołuje funkcję DllGetClassObject za pośrednictwem modelu obiektów składników (COM), aby utworzyć obiekt fabryki klas dla interfejsu IFilter i uzyskać wskaźnik do interfejsu fabryki klas tego obiektu.
Funkcja DllCanUnloadNow Klient indeksowania zawartości wywołuje funkcję DllCanUnloadNow punktu wejścia za pośrednictwem modelu COM w celu określenia, czy można zwolnić bibliotekę DLL IFilter. Interfejs IFilter jest zwalniany po upływie określonego czasu jego nieużywania, jak określono przez wartość rejestru FilterIdleTimeOut.

Implementowanie klasy IFilter i fabryki klas

Co najmniej dwie klasy, takie jak CFilter i CFilterCF, są zwykle implementowane przez każdą bibliotekę IFilter DLL. Klasa CFilter tworzy obiekt interfejsu IFilter, który implementuje funkcję filtrowania zawartości. Jego funkcje członkowskie implementują metody interfejsu IFilter. Każda klasa IFilter wymaga unikatowego identyfikatora klasy (CLSID), który generuje implementujący interfejs IFilter.

Klasa CFilterCF tworzy obiekt klasy factory dla interfejsu IFilter. Fabryka klas jest wywoływana za pośrednictwem interfejsu interfejsu interfejsu IClassFactory przez funkcję DllGetClassObject punktu wejścia biblioteki DLL. Klasa CFilterCF tworzy obiekt CFilter i zwraca wskaźnik do IUnknown. W bardziej złożonych przypadkach IFilter może zaimplementować hierarchię klas zamiast pojedynczej klasy CFilter.

Dziedziczenie interfejsów COM

Usługa Windows Search 3.0 lub nowsza wersja wymaga użycia IPersistStream z następujących powodów:

  • Aby zapewnić wydajność i zgodność w przyszłości.
  • Aby zwiększyć bezpieczeństwo. Filtry IFilters zaimplementowane za pomocą IPersistStream są bezpieczniejsze, ponieważ kontekst, w którym działa interfejs IFilter, nie wymaga uprawnień do otwierania plików na dysku lub przez sieć.
  • Podczas gdy usługa Windows Search używa tylko IPersistStream, klasa interfejsu IFilter może również dziedziczyć interfejsu IPersistFile i/lub implementację interfejsu IPersistStorage w celu zapewnienia zgodności z poprzednimi wersjami.

Te interfejsy są deklarowane w plikach uwzględnionych w katalogu mssdk\include i mają wstępnie zdefiniowane identyfikatory interfejsu (IID). Klient indeksowania zawartości wysyła zapytanie do interfejsu IFilter poprzez IUnknown, aby określić, które z tych interfejsów należy użyć podczas filtrowania zawartości.

Implementowanie metod interfejsu COM

InterfejsIFilterimplementuje metody IUnknown zarówno dla interfejsu klasy IFilter, jak i fabryki klas interfejsowych IFilter. W poniższej tabeli wymieniono w kolejności vtable interfejsy i metody specyficzne dla interfejsu IFilter, które powinny implementować interfejs IFilter. Interfejs IFilter musi implementować co najmniej IPersistStream, ale może implementować dodatkowe interfejsy wywodzące się z IPersist.

Interfejs COM Metoda
Interfejs IClassFactory CreateInstance, LockServer
Interfejs IClassFactory2 GetLicInfo, RequestLicKey, CreateInstanceLic
IFilter IFilter::Init, IFilter::GetChunk, IFilter::GetText, IFilter::GetValue, IFilter::BindRegion
IPersist, interfejs GetClassID
interfejs IPersistFile IsDirty, Load, Save, SaveCompleted, GetCurFile
interfejs IPersistStorage IsDirty, Load, Save, GetSizeMax
IPersistStream IsDirty, Load, Save, GetSizeMax

Strona referencyjna dla każdej metody określa parametry i zachowanie funkcjonalne dla tej metody. Każda strona referencyjna zawiera również kody wyników do zaimplementowania dla tej metody. Strony referencyjne dla metod IFilter podają kody wyników specyficzne dla interfejsu zawarte w kodach wyników FACILITY_ITF, a klient indeksowania zawartości może również obsługiwać wszelkie kody wyników ogólnych, takie jak FACILITY_NULL i FACILITY_WIN32. Aby uzyskać więcej informacji, zobacz Struktura kodów błędów COM.

Metody COM, które nie są implementowane

Interfejs IFilter musi implementować co najmniej IPersistStream, ale nie musi implementować dodatkowych interfejsów pochodnych IPersist.

Usługa Windows Search nie musi implementować metod COM wymienionych w poniższej tabeli.

Metoda, która nie jest wymagana Opis
IPersistStream::IsDirty Filtry powinny zwracać E_NOTIMPL.
IPersistStream::Save Filtry powinny zwracać E_NOTIMPL.
IPersistStream::GetSizeMax Filtry powinny zwracać E_NOTIMPL.
IFilter::BindRegion Filtry powinny zwracać E_NOTIMPL.

Dodatkowe zasoby

tworzenie programów obsługi filtrów

Zrozumienie obsługi filtrów w usłudze Windows Search

najlepsze rozwiązania dotyczące tworzenia programów obsługi filtrów w usłudze Windows Search

zwracanie właściwości z programu obsługi filtrów

programy obsługi filtrów dostarczane z systemem Windows

rejestrowanie programów obsługi filtrów

Testowanie programów obsługi filtrów