Partager via

Développement de compléments IFilter

  • Article

Notes

Windows Desktop Search 2.x est une technologie obsolète qui était initialement disponible en tant que complément pour Windows XP et Windows Server 2003. Sur les versions ultérieures, utilisez plutôt Recherche Windows .

Vous pouvez étendre La Recherche de bureau Microsoft Windows (WDS) avec des compléments de filtre, composants qui implémentent l’interface IFilter, pour inclure de nouveaux types de fichiers. Les filtres sont responsables de l’accès et de l’analyse des données dans les fichiers et du retour des paires de propriétés et de valeurs, ainsi que des blocs de texte à des fins d’indexation. Pendant le processus d’indexation, WDS appelle le filtre approprié avec l’URL de chaque fichier ou élément. Le filtre extrait d’abord les métadonnées qui correspondent aux propriétés qui sont marquées récupérables dans le schéma WDS, telles que le titre, la taille du fichier et la date de la dernière modification. Ensuite, il décompose le contenu de l’élément en blocs de texte. WDS ajoute les propriétés et le texte retournés par le filtre au catalogue. WDS peut indexer n’importe quel type de fichier pour lequel il a un filtre inscrit.

Dans certaines circonstances, vous n’avez pas besoin d’écrire un nouveau filtre. WDS 2.x contient des filtres pour plus de 200 types d’éléments (y compris les éléments en texte clair tels que les fichiers HTML, XML et code source) et utilise la même technologie IFilterque SharePoint Services. Si vous avez déjà installé des filtres pour vos types de fichiers, WDS peut utiliser ces filtres existants pour indexer ces données. En outre, WDS inclut un filtre général pour les types de fichiers basés en texte clair. Si vous avez un type de fichier qui peut être traité par un filtre SharePoint Services existant ou par le filtre en texte clair, vous pouvez ajouter l’extension de nom de fichier et le GUID de filtre au Registre afin que WDS puisse le localiser et l’utiliser (pour plus d’informations, voir Pour inscrire un complément de filtre).

Si, toutefois, vous disposez d’un format de données ou de fichier non en texte en clair et propriétaire, l’écriture d’une implémentation de filtre personnalisée est la seule façon de garantir que WDS peut indexer le format de fichier dans le catalogue. Vous ne pouvez avoir qu’un seul complément de filtre pour un type de fichier. Il est donc possible de remplacer un filtre existant ou d’avoir un autre filtre qui remplace le vôtre pour un type de fichier spécifique.

Cette section contient les rubriques suivantes :

Interfaces de filtre requises

Un complément de filtre doit implémenter l’interface IFilteret l’une des interfaces suivantes :

  • IPersistStream : pour charger des données à partir d’un flux. C’est plus sécurisé que l’utilisation de fichiers, car rien n’est écrit sur le disque. L’interface IPersistStream est la méthode préférée pour la compatibilité descendante avec Windows Vista.
  • Interface IPersistFile : pour charger des données à partir d’un fichier. Cette interface n’est pas prise en charge dans Windows Vista.
  • Interface IPersistStorage : pour charger des données à partir d’un stockage structuré OLE COM.

Un complément de filtre utilise ces interfaces pour obtenir le contenu de l’élément et les renvoyer de manière itérative à l’index jusqu’à ce que la fin du fichier soit atteinte. Un complément de filtre doit être aussi robuste que possible pour gérer les fichiers endommagés et ceux qui ne répondent pas aux formats d’entrée attendus.

IFilter Interface

Il s’agit d’une interface obligatoire pour une implémentation de filtre. Pour plus d’informations, consultez les informations de référence sur l’interface IFilter.

Méthode Description
Init() Initialise une session de filtrage.
GetChunk() Positionne le filtre au début du premier segment ou du segment suivant et retourne un descripteur.
GetText() Récupère le texte du segment actuel.
GetValue() Récupère les valeurs de propriété du segment actuel.
BindRegion() Actuellement réservé à un usage interne ; n’implémentent pas. Cette méthode retourne E_NOTIMPL.

 

IPersistStream

Cette interface charge un fichier à partir d’un flux pour un traitement plus sécurisé que l’interface IPersistFile , car le contexte dans lequel s’exécute un filtre IPersistStream n’a pas besoin des droits pour ouvrir des fichiers sur le disque ou sur le réseau. Parmi les deux méthodes permettant d’accéder à un seul fichier, il s’agit de la méthode préférée pour la compatibilité descendante avec Windows.

Méthode Description
IsDirty() Vérifie s’il y a eu une modification. Cette méthode retourne E_NOTIMPL dans les filtres.
InitNew() Crée un stockage. Cette méthode retourne E_NOTIMPL dans les filtres.
Load() Initialise un objet à partir du flux ayant été précédemment enregistré.
Save() Enregistre un objet dans le flux spécifié et indique si l’objet doit réinitialiser son indicateur de sale. Cette méthode retourne E_NOTIMPL dans les filtres.
GetSizeMax() Retourne la taille en octets du flux requis pour enregistrer l'objet. Cette méthode retourne E_NOTIMPL dans les filtres.

 

IPersistFile

Cette interface charge un fichier par chemin absolu et n’est pas prise en charge dans Windows Vista.

Méthode Description
GetCurFile() Obtient le nom actuel du fichier associé à l’objet. Retourne le chemin spécifié dans Load().
Load() Ouvre le fichier spécifié et initialise un objet à partir du contenu du fichier. Vous pouvez retarder l’ouverture du fichier jusqu’à ce que vous en ayez besoin.
GetClassID() Retourne l’identificateur de classe (CLSID) du nouveau type de fichier. Vous devez utiliser uuidgen.exe pour générer un CLSID unique.
IsDirty() Vous devez uniquement retourner E_NOTIMPL dans les filtres
Save() Vous devez uniquement retourner E_NOTIMPL dans les filtres
SaveCompleted() Vous devez uniquement retourner E_NOTIMPL dans les filtres

 

IPersistStorage

Cette interface prend en charge le modèle de stockage structuré, dans lequel chaque objet contenu a son propre stockage imbriqué dans le stockage du conteneur. Comme l’interface IPersistFile, cette interface se charge par chemin absolu et n’est pas prise en charge dans Windows Vista.

Méthode Description
IsDirty() Vérifie s’il y a eu un changement. Cette méthode retourne E_NOTIMPL dans les filtres.
InitNew() Crée un stockage. Cette méthode retourne E_NOTIMPL dans les filtres.
Load() Enregistre le stockage. Cette méthode retourne E_NOTIMPL dans les filtres.
Save() Retourne la taille en octets du flux requis pour enregistrer l'objet. Cette méthode retourne E_NOTIMPL dans les filtres.
SaveCompleted() Réservé à un usage interne. Cette méthode retourne E_NOTIMPL dans les filtres.
HandsOffStorage() Réservé à un usage interne. Cette méthode retourne E_NOTIMPL dans les filtres.

 

Sortie de propriétés avec des filtres

L’objectif d’un filtre est d’extraire le contenu et les propriétés des fichiers pour les inclure dans l’index de recherche en texte intégral. WDS appelle d’abord la méthode Load sur les implémentations IPersistFile, IPersistStream ou IPersistStorage, puis appelle la méthode Init de l’implémentation IFilter. GetChunk est appelé pour récupérer des blocs de données de valeur de texte ou de propriété, puis GetText ou GetValue est appelé autant de fois que nécessaire pour récupérer toutes les valeurs de texte ou de propriété associées au bloc. Ce processus se répète jusqu’à ce que GetChunk signale qu’il n’y a plus de blocs dans le document.

La méthode GetChunk récupère des informations sur le premier ou le prochain bloc logique d’informations à partir du fichier filtré et retourne ces informations dans une structure de STAT_CHUNK, y compris un ID de bloc à augmentation monotone, status des informations sur la façon dont le bloc actuel est lié au bloc précédent, un indicateur indiquant si le bloc contient du texte ou une valeur, les paramètres régionaux du bloc et la spécification de propriété du bloc. La spécification de propriété est un FULLPROPSPEC constitué d’un CLSID et d’un identificateur de propriété entier ou chaîne (par exemple, D5CDD505-2E9C-101B-9397-08002B2CF9AE/PerceivedType). Il identifie le type de propriété plutôt que la valeur de propriété elle-même.

L’identificateur de paramètres régionaux de bloc est utilisé pour choisir un analyseur lexical approprié, et il est très important que vous l’identifiez correctement. Si le filtre ne peut pas déterminer les paramètres régionaux du texte, il doit supposer les paramètres régionaux système par défaut, disponibles à l’aide de GetSystemDefaultLCID. Si vous contrôlez le format de fichier et qu’il ne contient actuellement pas d’informations de paramètres régionaux, vous devez ajouter une fonctionnalité utilisateur pour activer l’identification appropriée des paramètres régionaux. L’utilisation d’un analyseur lexicaux incompatible peut entraîner une mauvaise expérience de requête pour l’utilisateur.

GetChunk gère uniquement l’accès aux blocs et ne retourne pas la valeur de texte ou de propriété elle-même. Au lieu de cela, les appels suivants à GetText et GetValue récupèrent le corps du bloc. GetText retourne des blocs de texte, qui sont des chaînes Unicode, à partir du bloc CHUNK_TEXT actuel. Si le bloc actuel est trop grand, plusieurs appels à la méthode GetText peuvent être nécessaires. Chaque appel à la méthode GetText récupère le texte qui suit immédiatement le texte du dernier appel à la méthode GetText . Par exemple, le dernier caractère d’un appel peut se trouver au milieu d’un mot, et le premier caractère de l’appel suivant continue ce mot. Les moteurs de recherche doivent gérer cette situation.

GetValue retourne des valeurs de propriété pour le bloc CHUNK_VALUE actuel dans les structures PROPVARIANT, qui peuvent contenir un large éventail de types de données. GetValue doit allouer la structure PROPVARIANT elle-même à l’aide de CoTaskMemAlloc. L’appelant de GetValue est chargé de libérer de la mémoire pointée par propVARIANT à l’aide de PropVariantClear, et de libérer la structure elle-même avec CoTaskMemFree. Pour plus d’informations sur PROPVARIANTs, consultez la référence PROPVARIANT .

Valeurs de la propriété

Les filtres doivent générer au minimum les propriétés suivantes, qui sont les colonnes par défaut dans la vue de résultats WDS.

GUID PROPSPEC Nom convivial Description
F29F85E0-4FF9-1068-AB91-08002B27B3D9 2 PrimaryTitle Titre qui s’affiche pour cet élément.
F29F85E0-4FF9-1068-AB91-08002B27B3D9 4 PrimaryAuthors Personne la plus associée à cet élément.
D5CDD505-2E9C-101B-9397-08002B2CF9AE PrimaryDate PrimaryDate Date la plus importante pour l’élément, comme la date de réception de l’e-mail ou de modification pour les fichiers.
D5CDD505-2E9C-101B-9397-08002B2CF9AE PerceivedType PerceivedType Type de fichier analysé. Doit correspondre à l’un des types de recherche Windows Desktop répertoriés dans type perçu WDS.

 

Pour les éléments en texte clair, WDS extrait tout le texte et les propriétés définies par le système, telles que la taille de fichier ou l’extension sur l’inclusion de nouveaux types de fichiers de texte en clair dans l’index). Voici d’autres types de propriétés qui peuvent être retournés à l’index :

  • Pour les fichiers : auteur, titre, status, mots clés
  • Pour les médias : album, genre, photo make, date prise
  • Pour les communications : de, à, cc, importance
  • Pour les contacts : poste, téléphone professionnel, entreprise

La liste ci-dessus regroupe les propriétés communes à un type perçu spécifié ; toutefois, n’importe quelle propriété peut être utilisée quel que soit le type. Par exemple, l’entreprise peut être utilisée pour le nom de l’employeur d’un contact et peut également être utilisée pour faire référence au nom d’un client auquel le fichier se rapporte. La plupart de ces propriétés sont utilisées pour afficher les résultats de la recherche dans la vue des résultats WDS. Par exemple, la propriété Title d’un fichier s’affiche en tant que colonne main dans la vue des résultats par défaut. Les objets IFilter doivent générer toutes les propriétés liées au type d’élément qu’ils analysent. Les propriétés personnalisées ne peuvent pas être ajoutées dans WDS 2.x. Pour obtenir la liste complète des propriétés disponibles, consultez le schéma WDS.

Installation du complément de filtre

L’installation du filtre implique de copier la DLL vers un emplacement approprié dans le répertoire Program Files et de l’inscrire. Les filtres doivent implémenter l’auto-inscription pour l’installation et doivent suivre ces instructions :

  • Le programme d’installation doit utiliser le programme d’installation EXE ou MSI.
  • Les notes de publication doivent être fournies.
  • Une entrée Ajout/Suppression de programmes doit être créée pour chaque complément installé.
  • Le programme d’installation doit prendre en charge tous les paramètres de Registre pour le type de fichier ou le magasin particulier que le complément actuel comprend.
  • Si un complément précédent est remplacé, le programme d’installation doit en informer l’utilisateur.
  • Si un complément plus récent a remplacé le complément précédent, il doit y avoir la possibilité de restaurer les fonctionnalités du complément précédent et d’en faire à nouveau le complément par défaut pour ce type de fichier ou ce magasin.

CLSID requis pour l’inscription

Trois identificateurs de classe, ou CLSID, sont associés à chaque filtre. Vous devez générer un ou plusieurs de ces éléments (utilisez uuidgen.exe) pour inscrire votre complément de filtre.

  • Le premier identifie le gestionnaire persistant de tous les filtres, IID_IFilter, qui est {89BCB740-6119-101A-BCB7-00DD010655AF}. Ce CLSID est constant pour tous les filtres qui implémentent IFilter.
  • La seconde (valeur de la clé IID_IFilter) identifie l’implémentation IFilter pour votre type de fichier. Cette clé contient une valeur InprocServer32 qui spécifie le nom de la DLL par chemin d’accès et le modèle de thread. Si le filtre se trouve dans le chemin d’accès système, comme le répertoire system32, un nom de fichier est suffisant. Sinon, cette valeur doit avoir une spécification de chemin d’accès complète.
  • Le troisième identifie le type de fichier que le filtre traite et est retourné par la méthode GetClassID sur votre interface IPersist.

Notes

Dans les versions ultérieures des systèmes d’exploitation Microsoft, l’installation de fichiers dans le répertoire system32 peut devenir plus difficile. Nous vous recommandons donc de les installer sous Program Files et d’inclure un chemin d’accès complet au filtre dans le Registre. Pour des raisons de sécurité, il est également prudent de spécifier un chemin d’accès complet à votre DLL dans le Registre. Sinon, une version « cheval de Troie » de votre DLL pourrait être chargée si elle se trouve dans le chemin du processus avant votre version.

 

Modèle d’inscription

Lorsque WDS est prêt à filtrer un fichier, il recherche dans le Registre sous l’extension du fichier pour déterminer le filtre à charger. Il suit ensuite une série de liens de Registre pour trouver le nom de la DLL de filtre, dans cet ordre :

  1. À partir des CLSID situés à l’adresse suivante :

    HKEY_CURRENT_USER\SOFTWARE\Microsoft\RSSearch\ContentIndexCommon\Filters\Override\RSApp

    HKEY_CURRENT_USER\SOFTWARE\Microsoft\RSSearch\ContentIndexCommon\Filters

  2. À partir du type de contenu de fichier à l’adresse suivante :

    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MIME\Database\Content Type

  3. À partir de l’extension de nom de fichier (identique à l’API Win32 LoadIFilter) à l’adresse suivante :

    HKEY_CURRENT_USER\SOFTWARE\Microsoft\RSSearch\ContentIndexCommon\Filters\Override\RSApp

    HKEY_CURRENT_USER\SOFTWARE\Microsoft\RSSearch\ContentIndexCommon\Filters

    HKEY_CLASSES_ROOT\extpersistentHandler-CLSID-IID_IFilter-CLSID>>>

  4. À partir de Default à :

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RSSearch\ContentIndexCommon\Filters

Pour inscrire un complément de filtre

Vous devez effectuer un total de huit entrées dans le registre pour inscrire votre complément de filtre, où :

  • .ext est la nouvelle extension de nom de fichier
  • GUID_1 peut être n’importe quel nouveau GUID généré pour cette extension
  • 89BCB740-6119-101A-BCB7-00DDD010655AF est le GUID de l’interface IFilter, qui est une constante pour toutes les implémentations IFilter.

  1. Inscrivez le gestionnaire persistant pour l’extension de nom de fichier avec les clés et valeurs suivantes :

    HKEY_CLASSES_ROOT\<.ext>\PersistentHandler
   (Default) = {GUID_1}

    HKEY_CLASSES_ROOT\CLSID\{GUID_1}
   (Default) = <Persistent Handler Description>

    HKEY_CLASSES_ROOT\CLSID\{GUID_1}\PersistentAddinsRegistered
   (Default) = (Value Not Set)

    HKEY_CLASSES_ROOT\CLSID\{GUID_1}\PersistentAddinsRegistered\{89BCB740-6119-101A-BCB7-00DD010655AF}
   (Default) = {CLSID of IFilter implementation}

    HKEY_CLASSES_ROOT\CLSID\{GUID_1}\PersistentHandler
   (Default) = {GUID_1}

  2. Inscrivez l’implémentation IFilter avec les clés et valeurs suivantes :

    HKEY_CLASSES_ROOT\CLSID\{CLSID of IFilter implementation}
   (Default) = Extension IFilter Description">

    HKEY_CLASSES_ROOT\CLSID\{CLSID of IFilter implementation}\InprocServer32
   (Default) = <DLL Install Path>
   ThreadingModel = Both

  3. Inscrivez l’implémentation d’IFilter auprès de Windows Desktop Search avec la clé et la valeur suivantes :

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RSSearch\ContentIndexCommon\Filters\Extension\<.ext>
   (Default) = {CLSID of IFilter implementation}"

Informations de référence

SchemaTable

Types perçus

Développement de gestionnaires de protocole

Autres ressources

Ifilter