Windows Search en tant que plateforme de développement
Pour indexer le contenu et les propriétés de nouveaux formats de fichiers et magasins de données, la recherche Microsoft Windows doit être étendue avec des add-ins.
Avant qu’un développeur tiers de nouveaux formats de fichiers et magasins de données puisse faire apparaître ces formats et magasins dans les résultats de requête dans l’Explorateur Windows, le développeur doit faire les trois choses suivantes :
- Implémenter une source de données Shell pour étendre l’espace de noms Shell.
- Exposer les éléments dans un magasin de données (s’ils ajoutent un nouveau magasin de données, car il devra être indexé).
- Développer un gestionnaire de protocole afin que Windows Search puisse accéder aux données pour l’indexation.
Cette rubrique est organisée comme suit :
- Mise en route
- Vue d’ensemble des scénarios de développement de recherche
- Vue d’ensemble des gestionnaires
- Lignes directrices pour l’installation des add-ins
- Note aux implémenteurs
- Ressources complémentaires
- Rubriques connexes
Mise en route
Avant de commencer à créer une application de recherche Windows, rappelez-vous que la manière préférée de le faire est via une source de données Shell. Une source de données Shell étend l’espace de noms Shell et expose les éléments dans un magasin de données. Les éléments dans le magasin de données peuvent ensuite être indexés par le système de recherche Windows en utilisant un gestionnaire de protocole. Cette approche indirecte pour accéder à la recherche Windows en implémentant une source de données Shell est préférée car elle donne accès à la fonctionnalité complète du Shell. Faire ainsi assure une expérience utilisateur raisonnable.
Si vous souhaitez que les résultats de la requête apparaissent dans l’Explorateur Windows, vous devez implémenter une source de données Shell avant de pouvoir créer un gestionnaire de protocole permettant d’étendre l’index. Cependant, si toutes les requêtes seront programmatiques (par exemple via OLE DB) et interprétées par le code de l’application plutôt que par le Shell, un espace de noms Shell est toujours préféré mais non requis.
Un gestionnaire de protocole est nécessaire pour que Windows obtienne des informations sur le contenu des fichiers, tels que des éléments dans des bases de données ou des types de fichiers personnalisés. Bien que Windows Search puisse indexer le nom et les propriétés du fichier, Windows n’a aucune connaissance du contenu du fichier. Par conséquent, ces éléments ne peuvent pas être indexés ou exposés dans l’interpréteur de commandes Windows. En implémentant un gestionnaire de protocole personnalisé, vous pouvez exposer ces éléments. Pour une liste des gestionnaires identifiés par le scénario de développement que vous essayez de réaliser, veuillez consulter la section Vue d’ensemble des gestionnaires.
Vue d’ensemble des scénarios de développement de recherche
Les scénarios de développement les plus courants dans la recherche Windows sont :
- Ajout d’un nouveau magasin de données
- Ajout d’un nouveau format de fichier
- Consommation des résultats de recherche Windows
Ajout d’un nouveau magasin de données
Vous avez besoin d’un magasin de données Shell pour la recherche Windows uniquement si vous ajoutez un nouveau magasin de données à indexer. Un magasin de données est un référentiel de données qui peut être exposé au modèle de programmation Shell comme un conteneur en utilisant une source de données Shell. Les éléments dans un magasin de données peuvent ensuite être indexés par le système de recherche Windows en utilisant un gestionnaire de protocole. Le gestionnaire de protocole implémente le protocole pour accéder à une source de contenu dans son format natif. Les interfaces ISearchProtocol et ISearchProtocol2 sont utilisées pour implémenter un gestionnaire de protocole personnalisé permettant de développer les sources de données pouvant être indexées. Pour obtenir des informations sur la création d’une source de données Shell, consultez Implémentation des interfaces d’objet dossier de base.
Ajout d’un nouveau format de fichier
Si vous ajoutez un nouveau format de fichier personnalisé, vous devez développer soit un gestionnaire de filtre, soit un gestionnaire de propriétés, mais pas les deux. Un filtre est une implémentation de l’interface IFilter. Il ouvre les fichiers d’un type de fichier particulier et filtre les propriétés et segments de texte pour l’indexeur. Les filtres sont associés à des types de fichiers, comme indiqué par les extensions de nom de fichier, les types MIME ou les identificateurs de classe (CLSID). Bien qu’un filtre puisse gérer plusieurs types de fichiers, chaque type de fichier fonctionne avec un seul filtre.
Un gestionnaire de propriétés traduit les données stockées dans un fichier en un schéma structuré reconnu et accessible par l’Explorateur Windows, la recherche Windows et d’autres applications. Ces systèmes peuvent ensuite interagir avec le gestionnaire de propriétés pour écrire et lire des propriétés dans et depuis un fichier. Les données traduites incluent l’affichage des détails, les infobulles, le volet des détails, les pages de propriétés, et ainsi de suite. Chaque gestionnaire de propriétés est associé à un type de fichier particulier, identifié par l’extension de nom de fichier. Vous avez besoin d’un gestionnaire de propriétés pour faire les choses suivantes :
- Afficher les propriétés des éléments non indexés dans l’UI.
- Prendre en charge l’écriture de propriétés.
Consommation des résultats de recherche Windows
Les sections suivantes décrivent plusieurs manières de consommer les résultats de recherche Windows :
- Interroger les données
- Interroger des magasins de données distants (Recherche fédérée)
- Indexer des fichiers et des éléments
- Indexer un magasin de données
- Gérer le processus d’indexation
- Intégrer le système de propriétés Windows avec les applications de recherche Windows
Interrogation des données
Les développeurs écrivant des applications sur la combinaison du système de recherche Windows et du système de propriétés Windows peuvent accéder aux fichiers et aux éléments indépendamment de l’application ou du type de fichier. Il existe deux façons pour les applications d’accéder aux données de l’indexeur :
- Les applications communiquent directement avec OLE DB en envoyant des requêtes Windows Search Structured Query Language (SQL) au fournisseur OLE DB de Windows Search pour récupérer les résultats. Les requêtes peuvent être construites manuellement ou en utilisant l’interface ISearchQueryHelper pour générer le SQL à partir de mots-clés de recherche et de la syntaxe de requête avancée (AQS).
- Les applications fonctionnent via la couche Shell. L’avantage de la couche Shell est qu’elle prend également en charge d’autres sources comme grep. Cependant, l’inconvénient est que toutes les fonctionnalités de l’indexeur ne sont pas disponibles.
Une autre option consiste à utiliser les protocoles search-ms:// et search://, qui exécutent des recherches basées sur des URL rendues via l’Explorateur Windows. Cette option permet un développement plus léger mais ne retourne pas les résultats ou les sélections de l’utilisateur depuis l’affichage des résultats à l’application appelante. De plus, comme pour d’autres protocoles, les applications de recherche tierces peuvent prendre en charge les protocoles search-ms:// et search:// si les applications se conforment à l’ensemble des fonctionnalités requises. Pour plus d’informations sur les requêtes, veuillez consulter la section Processus de requête dans Windows Search et Requête de l’index par programmation.
Interroger des magasins de données distants (Recherche fédérée)
Dans Windows 7 et versions ultérieures, la recherche fédérée offre un nouveau fournisseur de recherche qui interroge des magasins de données distants via des serveurs web, via le protocole OpenSearch, et énumère les résultats sous forme de flux RSS ou Atom XML. Les connecteurs de recherche sont des jonctions d’espace de noms qui simulent le comportement des dossiers en utilisant un fournisseur de recherche. Pour plus d’informations sur la fédération de recherche vers des magasins de données distants dans Windows 7, veuillez consulter la section Recherche fédérée dans Windows.
Indexer des fichiers et des éléments
Le contenu qui est indexé est basé sur les types de fichiers et de données pris en charge via des add-ins inclus avec Windows Search et les règles d’inclusion et d’exclusion par défaut pour les dossiers dans le système de fichiers. Par exemple, les filtres inclus dans Windows Search prennent en charge plus de 200 types de données courants, y compris les documents Microsoft Office, les courriels Microsoft Outlook (en conjonction avec le gestionnaire de protocole MAPI), les fichiers texte brut, HTML, et bien d’autres. Pour une liste complète des types de fichiers pris en charge nativement, veuillez consulter la section Ce qui est inclus dans l’index.
L’index peut être étendu avec des gestionnaires de propriétés et des filtres pour exposer le contenu et les propriétés de nouveaux formats de fichiers à l’index et à l’Explorateur Windows. Les filtres sont une implémentation de l’interface IFilter. Il existe deux types de filtres : un qui interagit avec des éléments individuels tels que des fichiers et un qui interagit avec des conteneurs tels que des dossiers. Les filtres sont polyvalents en ce sens qu’ils prennent en charge le chunking des données, le contenu textuel, certaines propriétés, et plusieurs langues.
En revanche, les gestionnaires de propriétés ont un but plus spécifique : exposer les propriétés de types de fichiers spécifiques identifiés par les extensions de nom de fichier. Un gestionnaire de propriétés pour un type de fichier peut activer les propriétés get et set, et peut énumérer les propriétés associées à ce type de fichier. Contrairement aux filtres, les gestionnaires de propriétés ne prennent pas en charge le chunking des données ou du contenu textuel, et les gestionnaires de propriétés n’ont aucun moyen d’indiquer la langue d’une propriété textuelle, sauf s’ils prennent en charge l’écriture de propriétés.
Indexer un magasin de données
L’index peut être étendu avec des gestionnaires de protocole pour fournir l’accès à des magasins de données propriétaires. Par exemple, les fichiers et les éléments contenus dans des magasins de données non basés sur le système de fichiers (tels que les bases de données et les magasins de courriels) nécessitent un gestionnaire de protocole pour mapper une URL à un flux. Les gestionnaires de protocole peuvent également déterminer de manière optionnelle les filtres corrects à utiliser pour extraire des informations d’un flux. Les filtres énumèrent les URL du magasin de données. Les éléments sont ensuite individuellement indexés en utilisant le filtre et/ou le gestionnaire de propriétés approprié. Pour plus d’informations, veuillez consulter la section Extension de l’index.
Gérer le processus d’indexation
Les développeurs d’applications peuvent contrôler la portée et la fréquence de l’indexation de Windows Search en utilisant diverses interfaces de gestion. Ces interfaces incluent des fonctionnalités pour ajouter et supprimer les répertoires que l’indexeur analyse pour les changements, notifier manuellement l’index des changements de données, vérifier l’état de l’indexeur, et forcer la réindexation de certaines ou de toutes les données. Pour plus d’informations, veuillez consulter la section Gestion de l’index.
Intégrer le système de propriétés Windows avec les applications de recherche Windows
Le système de propriétés Windows est un système extensible de définition de données en lecture/écriture qui fournit une manière uniforme d’exprimer les métadonnées sur les éléments du Shell. Le système de propriétés Windows dans Windows Vista et versions ultérieures vous permet de stocker et de récupérer des métadonnées pour les éléments du Shell. Un élément du Shell est toute pièce de contenu unique, comme un fichier, un dossier, un courriel ou un contact. Une propriété est une pièce individuelle de métadonnées associée à un élément du Shell. Les valeurs des propriétés sont exprimées sous la forme d’une structure PROPVARIANT.
Une liste étendue de propriétés courantes est incluse pour un certain nombre de types d’éléments courants tels que les photos, la musique, les documents, les messages, les contacts, et les fichiers. Les développeurs peuvent également introduire leurs propres propriétés sur la plateforme si aucune propriété existante ne répond à leurs besoins. Pour plus d’informations sur l’intégration des applications avec le système de propriétés Windows, veuillez consulter la section Développement de gestionnaires de propriétés.
Vue d’ensemble des gestionnaires
Un gestionnaire est un objet COM (Component Object Model) qui fournit des fonctionnalités à un élément Shell. La plupart des sources de données Shell offrent un système extensible pour lier des gestionnaires aux éléments. Par exemple, le dossier du système de fichiers utilise le système d’association pour rechercher les gestionnaires pour un type de fichier particulier. Un gestionnaire spécifique est requis pour chaque type de fichier. Un gestionnaire de filtre est requis pour le type de fichier Adobe Acrobat .pdf, par exemple, un autre gestionnaire de filtre est requis pour le format de fichier .doc, et ainsi de suite.
Différents gestionnaires ont quelques points communs. Dans Windows Vista et versions ultérieures, tous les gestionnaires doivent utiliser l’une des interfaces suivantes pour initialiser le gestionnaire : IInitializeWithStream, IInitializeWithItem, ou IItinitializeWithFile.
Le tableau suivant liste les tâches de développement de haut niveau, le type de gestionnaire nécessaire pour chaque tâche, et fournit un lien vers des informations conceptuelles sur la manière d’effectuer chaque tâche.
Tâche | Handler | Informations conceptuelles |
---|---|---|
Accéder aux propriétés d’un fichier pour l’indexation | Gestionnaire de propriétés | Développement de gestionnaires de propriétés Propriétés définies par le système pour les formats de fichiers personnalisés |
Ajouter des formats de presse-papiers pour l’objet de données (IDataObject) d’un élément (Les objets de données sont utilisés dans les scénarios de glisser-déposer et de copier-coller). | Gestionnaire d'objets de données | Création de gestionnaires de données |
Ajouter des verbes pour un élément qui sont couramment affichés dans un menu contextuel | Un gestionnaire de menus contextuels | Création de gestionnaires de menus contextuels Personnalisation d’un menu contextuel en utilisant des verbes dynamiques |
Associer un type de fichier à une icône spécifique | Un gestionnaire d’icônes | Création de gestionnaires d’icônes |
Créer des feuilles de propriétés avec des images UI et des contrôles qui permettent une interaction personnalisée avec un type de fichier | Gestionnaire de feuille de propriétés | Gestionnaires de feuilles de propriétés |
Permettre à un type d’élément de prendre en charge les scénarios de glisser-déposer et de copier-coller | Gestionnaire de dépôt | Transfert d’objets Shell avec glisser-déposer et le presse-papiers |
Extraire des segments de texte et des propriétés de documents pour l’indexation | Gestionnaire de filtre | Développement de gestionnaires de filtres |
Indexer un nouveau type de fichier | Gestionnaire de filtre, gestionnaire de propriétés | Développement de gestionnaires de filtres Développement de gestionnaires de propriétés |
Indexer le contenu d’un magasin de données | Gestionnaire de protocole | Développer des gestionnaires de protocoles |
Prévisualiser une vue simplifiée de l’élément Shell dans le volet de prévisualisation de l’Explorateur Windows | Gestionnaire de prévisualisation | Gestionnaires de prévisualisation |
Fournir un texte contextuel lorsque la souris survole un objet UI | Gestionnaire d'info-bulle | Création de gestionnaires d’extension Shell (Personnalisation des infobulles) |
Fournir une image statique pour représenter un élément Shell | Gestionnaire de vignette | Gestionnaires de vignettes |
Le tableau suivant liste les gestionnaires et les interfaces pour implémenter chaque type de gestionnaire.
Handler | Interfaces |
---|---|
Gestionnaire de dépôt | IDropTarget, IDropTargetHelper, IPersistFile, IShellExtInit |
Gestionnaire d'objets de données | IDataObject, IPersistFile |
Gestionnaire de filtre | IFilter |
Un gestionnaire d’icônes | IExtractIcon Facultatif : IPersist, IPersistFile |
Gestionnaire d'info-bulle | IQueryInfo |
Gestionnaire de prévisualisation | IPreviewHandler |
Gestionnaire de propriétés | IPropertyStore |
Gestionnaire de protocole | IFilter, ISearchProtocol, IUrlAccessor Facultatif : ISearchProtocol2, IUrlAccessor2, IUrlAccessor3, IUrlAccessor4 |
Gestionnaire de feuille de propriétés | IShellExtInit, IShellPropSheetExt |
Un gestionnaire de menus contextuels | IContextMenu, IExplorerCommand, IShellExtInit |
Gestionnaire de vignette | IThumbnailProvider |
Remarque
Un gestionnaire de propriétés est parfois connu sous le nom de gestionnaire de métadonnées. Une source de données Shell est parfois appelée extension d’espace de noms Shell. Un gestionnaire de type de fichier est parfois connu sous le nom de gestionnaire d’extension Shell ou d’extension Shell.
Pour plus d’informations sur la création de gestionnaires, veuillez consulter la section Création de gestionnaires d’extension Shell. Pour plus d’informations sur les propriétés, veuillez consulter la section Système de propriétés Windows.
Lignes directrices pour l’installation des add-ins
Utilisez les lignes directrices suivantes lors de la création d’un installateur d’add-in :
- L’installateur doit utiliser soit l’installateur EXE, soit l’installateur MSI.
- Les notes de publication doivent être fournies.
- Une entrée Ajouter/Supprimer des programmes doit être créée pour chaque add-in 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 avertir l’utilisateur.
- Si un nouvel add-in a remplacé un add-in précédent, l’utilisateur doit pouvoir restaurer la fonctionnalité de l’add-in précédent et le rendre à nouveau l’add-in par défaut pour ce type de fichier ou magasin.
Note aux implémenteurs
Avant de créer un filtre ou un gestionnaire de propriétés, les développeurs doivent considérer les points suivants :
- Ces gestionnaires sont des extensions in-process qui sont chargées dans des processus que vous ne contrôlez pas, tels que le processus de démon de filtre, l’Explorateur Windows (recherche grep), et les hôtes tiers comme Windows Mail).
- Vous devez écrire un code sécurisé suffisamment robuste pour gérer des formes arbitrairement corrompues de votre format de fichier qui ont été créées pour attaquer le système.
- Votre add-in ne doit pas laisser de ressources non libérées qui causeront des problèmes pour les processus hôtes.
- Votre add-in ne doit pas planter car cela entraînerait également un crash des processus hôtes et ralentirait le processus de filtrage.
- Étant donné que ces gestionnaires sont exécutés dans un processus système en arrière-plan, ils doivent fonctionner rapidement avec une consommation minimale de CPU et d’E/S afin de répondre aux exigences de performance du système.
Ainsi, ces add-ins doivent être écrits par des développeurs ayant une expertise dans la création de code au niveau système.
Ressources complémentaires
- Pour obtenir des informations sur la création d’une source de données Shell, consultez Implémentation des interfaces d’objet dossier de base.
- Pour les sources de données qui doivent utiliser l’objet de vue de dossier système par défaut du Shell (DefView), veuillez consulter la section Implémentation d’une vue de dossier, la fonction SHCreateShellFolderView, et la structure SFV_CREATE. Les sources de données qui utilisent l’objet de vue de dossier système par défaut du Shell (DefView) doivent implémenter l’ensemble d’interfaces suivant : IShellFolder, IShellFolder2, IPersistFolder, IPersistFolder2, et ( en option) IPersistFolder3. Si votre implémentation IShellFolder n’utilise pas SHCreateShellFolderView pour créer le DefView, l’objet de vue Shell peut nécessiter IFolderView.
- ISearchFolderItemFactory est l’interface principale pour les consommateurs de la source de données Shell connue sous le nom de DBFolder. Pour plus d’informations sur DBFolder, veuillez consulter la description de la constante STR_PARSE_WITH_PROPERTIES dans Clés de chaîne de contexte de liaison. Consultez également Tableaux associatifs et IPropertySystem::GetPropertyDescriptionListFromString.
- Pour obtenir des informations sur OLE DB, consultez Vue d’ensemble de la programmation OLE DB. Pour obtenir des informations sur le fournisseur de données .NET Framework pour OLE DB, consultez la documentation de System.Data.OleDb Namespace.
- Pour des forums soutenus par la communauté sur les technologies de recherche, veuillez consulter la section Windows : forums de recherche.
- Pour obtenir des exemples de code connexes, consultez Exemples de code Windows Search.
Rubriques connexes