Förstå protokollhanterare
Vissa program lagrar sina objekt i databaser eller anpassade filtyper. Windows Search kan indexering av namn och egenskaper för filen, men Windows har ingen kunskap om innehållet i filen. Därför kan sådana objekt inte indexeras eller exponeras i Windows Shell. Genom att skapa en protokollhanterare kan du göra dessa objekt tillgängliga för indexering. Du kan också indexera ett sammansatt filformat, till exempel en .zip-fil.
Det här avsnittet är ordnat på följande sätt:
Indexera datalager med protokollhanterare
När användare behöver söka i äldre databaser, e-postlager eller andra datastrukturer som inte stöds av Windows Search bör du först avgöra om det redan finns en protokollhanterare för datalagret, kanske för användning med ett annat program, till exempel SharePoint Server. I så fall kan du installera protokollhanteraren i systemet. Windows Search-protokollhanterare använder designspecifikationer som liknar SharePoint Server, och de kan ofta användas omväxlande.
Mer information om distribution av Sökserver 2008 med Office SharePoint Server 2007 finns i federerad sökning [Search Server 2008].
Shell-datalager
Innan en tredjepartsutvecklare av nya filformat och datalager kan hämta dessa format och arkiv för att visas i frågeresultat i Utforskaren måste utvecklaren implementera en Shell-datakälla. En Shell-datakälla är en komponent som används för att utöka Shell-namnområdet och exponera objekt i ett datalager. Ett datalager är en lagringsplats för data. Ett datalager kan exponeras för Shell-programmeringsmodellen som en container som använder en Shell-datakälla. Objekten i ett datalager kan indexeras av Windows Search-systemet med hjälp av en protokollhanterare. Protokollhanteraren implementerar protokollet för åtkomst till en innehållskälla i sitt interna format. Gränssnitten ISearchProtocol och ISearchProtocol2 används för att implementera en anpassad protokollhanterare för att expandera de datakällor som kan indexeras.
Om du vill att frågeresultatet ska visas i Utforskaren måste du implementera en Shell-datakälla innan du kan skapa en protokollhanterare för att utöka indexet. Men om alla frågor sker programmatiskt (till exempel via OLE DB) och tolkas av programmets kod i stället för Shell, krävs inte ett Shell-namnområde även om det fortfarande föredras.
Not
En Shell-datakälla kallas ibland för ett Shell-namnområdestillägg. En hanterare kallas ibland för ett Shell-tillägg eller en Shell-tilläggshanterare.
Om du vill att användarna ska visa sina sökresultat från Utforskaren måste du skapa en protokollhanterare och ett eller flera av följande tillägg:
- Snabbmenyhanterare
- Ikonhanterare
- Någon annan typ av filbearbetare
En lista över hanterare som identifieras av utvecklarscenariot som du försöker uppnå finns i Översikt över hanterare i Windows Search som en utvecklingsplattform. Information om hur du skapar hanterare finns i Registering Shell Extensions, Context Menuoch File Type Handlers.
Protokollhanterare
Om datalagret också är en container (till exempel en filsystemmapp) måste du implementera ett filter för att räkna upp URL:erna i containern. Om datalagret innehåller andra data- eller filtyper än någon av de 200 filtyper som stöds av Windows Search måste du implementera ett filter för att få åtkomst till och indexering av innehållet i objekten i arkivet. Windows Search använder protokollhanterare och IFilter- teknik som liknar den som används av SharePoint Server. Om du redan har filter för ett visst arkiv och filtyp installerade på systemet som indexeras kan Windows Search använda de befintliga gränssnitten för att indexering av dessa data.
En översikt över indexeringsprocessen finns i Indexeringsprocessen. Konceptuell information om filterhanterare finns i Utveckla filterhanterare.
Filter och protokollhanterare
Protokollhanterare ger Windows Search-indexeraren åtkomst till datalager, vilket gör att indexeraren kan crawla noderna i ett datalager och extrahera relevant information för indexering. Windows Search levereras till exempel med protokollhanterare för filsystemlager och för vissa versioner av båda Microsoft Outlook-datalager. När du indexerar Outlook-e-post crawlar protokollhanteraren alla meddelanden i en uppsättning Outlook-mappar och extraherar information från varje meddelande och bifogad fil. Den här informationen skickas till indexeraren för inkludering i Windows Search-katalogen.
För översikter över Catalog Manager och Crawl Scope Manager (CSM), se Using the Catalog Manager och Using the Crawl Scope Manager.
Indexera ett sammansatt filformat
Ett sammansatt filformat kan indexeras så att enskilda objekt i filen kan returneras som enskilda resultat. Ett sammansatt filformat, till exempel en komprimerad fil med filnamnstillägget .zip, är i princip ett datalager och kan behandlas som sådant i indexeringssyfte. I följande exempel visas en .zip fil i filsystemets namnområde (FILE://c:/test/test.zip) där det finns både undermappar och enskilda objekt.
Test.zip
|-folder1
| |-folder2
| |- FileX.txt
|- FileY.doc
FILE-protokollhanteraren upptäcker när FILE://c:/test/test.zip förändras genom att övervaka ändringsloggar i filsystemet, och den anropar en IFilter- registrerad för .zip filer när filen ändras, men den känner inte till den interna strukturen i själva .zip filen.
Du måste informera indexeraren om att det sammansatta filformatet är ett datalager. Det är nödvändigt att göra det för att enskilda objekt ska indexeras och hämtas som unika entiteter. När du har implementerat en Shell-datakälla och utfört följande steg har du en protokollhanterare som kan bearbeta och exponera data från ett sammansatt filformat (en .zip fil) som enskilda objekt.
Informera indexeraren om att en sammansatt fil är ett datalager:
Skapa en protokollhanterare (med ISearchProtocol eller ISearchProtocol2) för .zip filer som har möjlighet att binda till källfilen. Mer information finns i Installera och registrera protokollhanterare.
Du kan till exempel använda en maskerad sökväg till .zip-filen som rotmappens namn och sedan använda en hierarkisyntax som vilket annat filformat som helst.
.zip:///escapedPathTo.zipFile/.zipfolder/.../.zipfileMed hjälp av ovanstående exempeldata för c:\test\test.zipskulle de unika URL:erna vara följande. Med dessa URL:er har protokollhanteraren den information som krävs för att binda till den .zip filen och räkna upp underordnade URL:er inklusive de inre filerna så att de kan bindas till och indexeras av .doc och .txt filter.
.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.txtKontrollera att protokollhanteraren uppfyller följande två villkor:
- Rot-URL:erna för en .zip-fil bör emittera PKEY_Search_IsClosedDirectory (System.Search.IsClosedDirectory) på URL:erna som är rot-URL:erna för .zip-filer. Till exempel bör .zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/ generera IsClosedDirectory = SANT. Detta talar om för indexeraren att om datumet på den här URL:en inte har ändrats behöver det inte bearbeta någon av de underordnade URL:erna.
- Varje underordnad URL för den URL:en ska generera PKEY_Search_IsFullyContained (System.Search.IsFullyContained) på de underordnade URL:erna till rot-.zip-URL:en. Normalt i slutet av en inkrementell crawlning behandlar indexeraren alla obesökt URL:er som objekt som ska tas bort. Men rotfilen .zip ska inte bearbeta rot-URL:er eftersom ingenting har ändrats. Om den här egenskapen genereras som TRUE- meddelar indexeraren att om den här URL:en inte har bearbetats i slutet av en inkrementell crawlning ska den inte tas bort. Det tas bara bort om rotobjektet har ändrats och det inte besöks.
Windows Search kräver en startsida för ett protokoll för att veta vilka URL:er som ska crawlas stegvis och vilka URL:er som ska ignoreras när de hittas. Men vi kan inte börja med en URL för varje .zip fil eftersom vi inte vet var varje .zip fil finns. Därför måste .zip-protokollhanterarens startsidas URL kunna räkna upp allt i roten för de undantagna sökvägarna för alla .zip filer. De .zip filerna finns inte nödvändigtvis i filnamnområdet och kan till exempel vara en URL av MAPI-typ som pekar på en .zip fil som en bifogad fil.
Registrera en rot som en startsida:
Registrera en rot som .zip:/// som en startsida så att alla .zip filer börjar där, i praktiken. När du bearbetar roten .zip: URL ska protokollhanteraren skapa en lista med de underordnade URL:er som ska utlämnas genom att fråga Windows Search efter alla URL:er med System.FileExtension = ".zip".
Undvik dessa URL:er för att ta bort snedstrecken och returnera dem som underordnade URL:er. En exempelfråga för att hämta de typer du vill ha kan se ut så här.
SELECT system.itemurl, System.DateModified FROM SystemIndex WHERE System.FileExtension='.zip' OR System.MimeType='mimetypefor.zip'När Windows Search regelbundet utför en inkrementell genomsökning av din .zip:/// rot-URL, måste du återspegla tillbaka listan över URL:er som Windows Search redan hanterar, vilka är .zip URL:er. Om en borttagning identifieras i den ursprungliga lagringsplatsen där filen .zip lagras visas den inte i listan, och den grenen av dataträdet i .zip tas bort.
Om du vill binda till .zip data för en annan protokollhanterare bör du helst gå igenom IShellFolder- för att url:en ska binda till objektets lagring och inte anta att det alltid är en fil. Om du gör detta får du till exempel flexibiliteten att arbeta med bifogade filer i e-postlagring.
När du genererar underordnade URL:er för varje .zip fil bör du använda PKEY_Search_UrlToIndexWithModificationTime (System.Search.UrlToIndexWithModificationTime) för att skicka PKEY_DateModified (System.DateModified) för den faktiska .zip filen så att indexeraren endast crawlar .zip filen om den har ändrats.
Om du vill att dina .zip-URL:er ska indexeras omedelbart efter att de har skapats eller ändrats, och inte behöver vänta på en inkrementell crawlning för att identifiera deras nya tillstånd, kan du tänka dig att övervaka filsystemet själv för .zip filändringar. En sådan metod fungerar dock inte för andra datalager, till exempel MAPI.
Om du vill att dina .zip url:er ska indexeras när de skapas eller ändras:
- Skapa ett filter (och implementering av IFilter-gränssnittet) för .zip filtyp. Mer information finns i Utveckla egenskapshanterare för Windows Search.
- När din IFilter--implementering anropas beror det på att url:en har identifierats eller ändrats. Generera sedan en händelse för den .zip URL som är lämplig för käll-URL:en via IGatherNotifyInline--gränssnittet. Om du gör det kan du omedelbart meddela indexeraren att det finns nya data som ska indexeras utan att behöva vänta på den inkrementella crawlningen.
Relaterade ämnen