Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Sommige toepassingen slaan hun items op in databases of aangepaste bestandstypen. Hoewel Windows Search de naam en eigenschappen van het bestand kan indexeren, heeft Windows geen kennis van de inhoud van het bestand. Als gevolg hiervan kunnen dergelijke items niet worden geïndexeerd of weergegeven in de Windows Shell. Door een protocolhandler te maken, kunt u deze items beschikbaar maken voor indexering. U kunt ook een samengestelde bestandsindeling, zoals een .zip-bestand, indexeren.
Dit onderwerp is als volgt ingedeeld:
- het indexeren van gegevensarchieven met protocolhandlers
- indexeren van een samengestelde bestandsindeling
- Verwante onderwerpen
Gegevensarchieven indexeren met protocolhandlers
Wanneer gebruikers verouderde databases, e-mailarchieven of andere gegevensstructuren moeten doorzoeken die niet worden ondersteund door Windows Search, moet u eerst bepalen of er al een protocolhandler bestaat voor dat gegevensarchief, mogelijk voor gebruik met een andere toepassing, zoals SharePoint Server. Zo ja, dan kunt u die protocolhandler op het systeem installeren. Windows Search-protocolhandlers gebruiken ontwerpspecificaties die vergelijkbaar zijn met SharePoint Server en kunnen vaak door elkaar worden gebruikt.
Zie Federatieve zoekfunctie [Search Server 2008]voor meer informatie over de implementatie van Search Server 2008 met Office SharePoint Server 2007.
Shell-gegevensarchieven
Voordat een externe ontwikkelaar van nieuwe bestandsindelingen en gegevensarchieven deze indelingen en archieven kan ophalen in queryresultaten in Windows Verkenner, moet de ontwikkelaar een Shell-gegevensbron implementeren. Een Shell-gegevensbron is een onderdeel dat wordt gebruikt om de Shell-naamruimte uit te breiden en items beschikbaar te maken in een gegevensarchief. Een gegevensarchief is een opslagplaats met gegevens. Een gegevensarchief kan worden blootgesteld aan het Shell-programmeermodel als een container die gebruikmaakt van een Shell-gegevensbron. De items in een gegevensarchief kunnen worden geïndexeerd door het Windows Search-systeem met behulp van een protocolhandler. De protocolhandler implementeert het protocol voor toegang tot een inhoudsbron in de systeemeigen indeling. De ISearchProtocol en ISearchProtocol2 interfaces worden gebruikt om een aangepaste protocolhandler te implementeren om de gegevensbronnen uit te breiden die kunnen worden geïndexeerd.
Als u wilt dat de queryresultaten worden weergegeven in Windows Verkenner, moet u een Shell-gegevensbron implementeren voordat u een protocolhandler kunt maken om de index uit te breiden. Als alle query's echter programmatisch zijn (bijvoorbeeld via OLE DB) en door de code van de toepassing worden geïnterpreteerd in plaats van door Shell, is een Shell-naamruimte hoewel nog steeds de voorkeur heeft, niet strikt vereist.
Notitie
Een Shell-gegevensbron wordt ook wel een Shell-naamruimteextensie genoemd. Een handler wordt ook wel een Shell-extensie of een Shell-extensiehandler genoemd.
Als u wilt dat gebruikers hun zoekresultaten bekijken vanuit Windows Verkenner, moet u een protocolhandler en een of meer van de volgende invoegtoepassingen maken:
- Snelle menuverwerker
- Pictogramverwerker
- Een ander type bestandshandler
Zie 'Overzicht van handlers' in Windows Search als een ontwikkelplatformvoor een lijst met handlers die zijn geïdentificeerd door het ontwikkelaarsscenario dat u probeert te bereiken. Voor meer informatie over het maken van handlers, zie Shell-extensies registreren, Contextmenuen Handlers voor bestandstypen.
Protocolhandlers
Als het gegevensarchief ook een container is (zoals een bestandssysteemmap), moet u een filter implementeren om de URL's in de container op te sommen. Als het gegevensarchief andere gegevens- of bestandstypen bevat dan een van de 200 bestandstypen die worden ondersteund door Windows Search, moet u een filter implementeren om de inhoud van items in het archief te openen en te indexeren. Windows Search maakt gebruik van protocolhandler en IFilter technologie die vergelijkbaar is met die van SharePoint Server. Als u al filters hebt voor een specifiek archief en bestandstype dat is geïnstalleerd op het systeem dat wordt geïndexeerd, kan Windows Search mogelijk de bestaande interfaces gebruiken om deze gegevens te indexeren.
Zie Het indexeringsprocesvoor een overzicht van het indexeringsproces. Zie Filterhandlers ontwikkelenvoor conceptuele informatie over filterhandlers.
Filters en protocolhandlers
Protocolhandlers geven de Windows Search-indexeerfunctie toegang tot gegevensarchieven, waardoor de indexeerfunctie de knooppunten van een gegevensarchief kan verkennen en relevante informatie kan extraheren om te indexeren. Windows Search wordt bijvoorbeeld geleverd met protocolhandlers voor bestandssysteemarchieven en voor sommige versies van beide Microsoft Outlook-gegevensarchieven. Bij het indexeren van Outlook-e-mail verkent de protocolhandler alle berichten in een set Outlook-mappen en worden gegevens uit elk bericht en elke bijlage geëxtraheerd. Deze informatie wordt doorgegeven aan de indexeerfunctie voor opname in de Windows Search-catalogus.
Zie voor overzichten van de Catalog Manager en de Crawl Scope Manager (CSM) Gebruik van de Catalog Manager en Gebruik van de Crawl Scope Manager.
Een samengestelde bestandsindeling indexeren
Een samengestelde bestandsindeling kan worden geïndexeerd, zodat afzonderlijke items in het bestand als afzonderlijke resultaten kunnen worden geretourneerd. Een samengestelde bestandsindeling zoals een gecomprimeerd bestand met een .zip bestandsnaamextensie is in wezen een gegevensarchief en kan als zodanig worden behandeld voor indexeringsdoeleinden. In het volgende voorbeeld wordt een .zip bestand weergegeven in de bestandsnaamruimte (FILE://c:/test/test.zip) waarin zowel submappen als afzonderlijke items staan.
Test.zip
|-folder1
| |-folder2
| |- FileX.txt
|- FileY.doc
De FILE-protocolhandler detecteert wanneer FILE://c:/test/test.zip wijzigt door bestandssysteemlogboeken te controleren. Vervolgens zal een IFilter-, die is geregistreerd voor .zip bestanden, worden aangeroepen wanneer het bestand verandert, maar het weet niets van de interne structuur van het .zip bestand zelf.
U moet de indexeerfunctie informeren dat de samengestelde bestandsindeling een gegevensarchief is. Het is noodzakelijk om dit te doen voor afzonderlijke items die moeten worden geïndexeerd en opgehaald als unieke entiteiten. Nadat u een Shell-gegevensbron hebt geïmplementeerd en de volgende stappen hebt uitgevoerd, hebt u een protocolhandler die de gegevens uit een samengestelde bestandsindeling (een .zip-bestand) als afzonderlijke items kan verwerken en beschikbaar maken.
De indexeerfunctie informeren dat een samengesteld bestand een gegevensarchief is:
Maak een protocolhandler (met behulp van ISearchProtocol of ISearchProtocol2) voor .zip bestanden met de mogelijkheid om verbinding te maken met het bronbestand. Zie Protocolhandlers installeren en registrerenvoor meer informatie.
U kunt bijvoorbeeld een escaped pad naar het .zip-bestand gebruiken als de naam van de hoofdmap en vervolgens een hiërarchiesyntaxis gebruiken zoals elke andere bestandsindeling.
.zip:///escapedPathTo.zipFile/.zipfolder/.../.zipfileAls u de bovenstaande voorbeeldgegevens voor c:\test\test.zipgebruikt, zijn de unieke URL's als volgt. Met deze URL's beschikt de protocolhandler over de informatie die nodig is om het .zip bestand te binden en de onderliggende URL's op te sommen, inclusief de binnenste bestanden, zodat ze kunnen worden gebonden aan en geïndexeerd door de .doc- en .txt-filters.
.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.txtZorg ervoor dat uw protocolhandler voldoet aan de volgende twee voorwaarden:
- De root-URL's voor een .zip-bestand moeten PKEY_Search_IsClosedDirectory (System.Search.IsClosedDirectory) verzenden naar de URL's die de root-URLs van het .zip-bestand zijn. Bijvoorbeeld: .zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/ moet IsClosedDirectory = TRUEweergeven. Dit vertelt de indexeerfunctie dat als de datum op deze URL niet is gewijzigd, er geen onderliggende URL's hoeven te worden verwerkt.
- Elke onderliggende URL voor die URL moet PKEY_Search_IsFullyContained (System.Search.IsFullyContained) verzenden op de onderliggende URL's van de hoofd-.zip-URL. Normaal gesproken behandelt de indexeerfunctie aan het einde van een incrementele verkenning alle niet-bekeken URL's als items die moeten worden verwijderd. Maar het hoofdbestand .zip mag geen hoofd-URL's verwerken omdat er niets is gewijzigd. Als u deze eigenschap verzendt als TRUE vertelt de indexeerfunctie dat als deze URL niet is verwerkt aan het einde van een incrementele verkenning, deze niet mag worden verwijderd. Het wordt alleen verwijderd als het hoofditem is gewijzigd en het niet wordt bezocht.
Windows Search vereist een startpagina voor een protocol om te weten welke URL's incrementeel moeten worden verkend en welke URL's moeten worden genegeerd wanneer ze worden gevonden. Maar we kunnen niet beginnen met een URL voor elk .zip bestand, omdat we niet weten waar elk .zip bestand zich bevindt. Daarom moet de URL van de startpagina van de .zip-protocolhandler alles kunnen inventariseren in de hoofdmap van de escapepaden van alle .zip-bestanden. Deze .zip bestanden bevinden zich niet noodzakelijkerwijs in het BESTAND: naamruimte en kan een MAPI-type-URL zijn die verwijst naar een .zip bestand als bijlage, bijvoorbeeld.
Een root registreren als startpagina:
Registreer een hoofdmap zoals .zip:/// als startpagina, zodat alle .zip-bestanden daar effectief beginnen. Bij het verwerken van de hoofd-.zip: URL, moet uw protocolhandler de lijst met onderliggende URL's genereren die moeten worden verzonden door een query uit te voeren op Windows Search voor alle URL's met System.FileExtension = ".zip".
Escape deze URL's om de slashes te verwijderen en deze als onderliggende URL's te retourneren. Een voorbeeldquery voor het ophalen van de gewenste typen kan er als volgt uitzien.
SELECT system.itemurl, System.DateModified FROM SystemIndex WHERE System.FileExtension='.zip' OR System.MimeType='mimetypefor.zip'Wanneer Windows Search periodiek een incrementele verkenning uitvoert op uw .zip:/// root-URL, moet u de lijst met URL's die Windows Search al onderhoudt, weergeven die al .zip URL's zijn. Als een verwijdering wordt gedetecteerd in het systeemeigen archief waar het .zip-bestand is opgeslagen, ziet u de verwijdering niet in uw opsomming en wordt die tak van de boom in het .zip verwijderd.
Als u verbinding wilt maken met de .zip gegevensbinding voor een andere protocolhandler, moet u in het ideale geval de IShellFolder- gebruiken om die URL om te koppelen aan de opslag van het object en niet aan te nemen dat het altijd een bestand is. Dit biedt u bijvoorbeeld de flexibiliteit om te werken met bijlagen in e-mailarchieven.
Wanneer u onderliggende URL's genereert voor elk .zip-bestand, moet u PKEY_Search_UrlToIndexWithModificationTime (System.Search.UrlToIndexWithModificationTime) gebruiken om PKEY_DateModified (System.DateModified) van het werkelijke .zip-bestand door te geven, zodat de indexeerder het .zip-bestand alleen crawlt als het is gewijzigd.
Als u uw .zip URL's onmiddellijk wilt laten indexeren nadat ze zijn gemaakt of gewijzigd en u niet hoeft te wachten tot een incrementele verkenning de nieuwe status detecteert, kunt u het bestandssysteem mogelijk zelf controleren op .zip bestandswijzigingen. Een dergelijke benadering werkt echter niet voor andere gegevensarchieven, zoals MAPI.
Als u uw .zip-URL's wilt laten indexeren wanneer ze worden gemaakt of gewijzigd:
- Maak een filter (en implementatie van de IFilter-interface) voor het .zip bestandstype. Zie Eigenschapshandlers ontwikkelen voor Windows Searchvoor meer informatie.
- Wanneer uw IFilter-implementatie wordt aangeroepen, komt dit doordat die URL is gedetecteerd of gewijzigd. Genereer vervolgens een gebeurtenis voor de .zip URL die geschikt is voor de bron-URL, via de IGatherNotifyInline interface. Als u dit doet, kunt u de indexeerfunctie onmiddellijk vertellen dat er nieuwe gegevens moeten worden geïndexeerd zonder dat u hoeft te wachten op de incrementele verkenning.
Verwante onderwerpen