Grundlegendes zu Protokollhandlern
Einige Anwendungen speichern ihre Elemente in Datenbanken oder benutzerdefinierten Dateitypen. Windows Search kann zwar den Namen und die Eigenschaften der Datei indizieren, Windows hat jedoch keine Kenntnis über den Inhalt der Datei. Daher können solche Elemente nicht indiziert oder in der Windows-Shell verfügbar gemacht werden. Durch Erstellen eines Protokollhandlers können Sie diese Elemente für die Indizierung verfügbar machen. Sie können auch ein zusammengesetztes Dateiformat wie eine ZIP-Datei indizieren.
Dieses Thema ist wie folgt organisiert:
- Indizieren von Datenspeichern mit Protokollhandlern
- Indizieren eines Verbunddateiformats
- Verwandte Themen
Indizieren von Datenspeichern mit Protokollhandlern
Wenn Benutzer Legacydatenbanken, E-Mail-Speicher oder andere Datenstrukturen durchsuchen müssen, die nicht von Windows Search unterstützt werden, sollten Sie zuerst ermitteln, ob für diese Datenspeicher bereits Protokollhandler vorhanden sind, z. B. für eine andere Anwendung wie SharePoint Server. Wenn ja, können Sie diesen Protokollhandler auf dem System installieren. Windows Search-Protokollhandler verwenden Entwurfsspezifikationen, die SharePoint Server ähneln, und sie sind häufig untereinander austauschbar.
Weitere Informationen zur Search Server 2008-Bereitstellung mit Office SharePoint Server 2007 finden Sie unter Sammelsuche [Search Server 2008].
Shell-Datenspeicher
Bevor ein Drittanbieter für neue Dateiformate und Datenspeicher diese Formate und Speicher abrufen kann, um in Abfrageergebnissen in Windows Explorer anzuzeigen, muss der Entwickler eine Shell-Datenquelle implementieren. Eine Shell-Datenquelle ist eine Komponente, die verwendet wird, um den Shell-Namespace zu erweitern und Elemente in einem Datenspeicher verfügbar zu machen. Ein Datenspeicher ist ein Repository von Daten. Ein Datenspeicher kann für das Shell-Programmiermodell als Container verfügbar gemacht werden, der eine Shell-Datenquelle verwendet. Die Elemente in einem Datenspeicher können mithilfe eines Protokollhandlers vom Windows Search-System indiziert werden. Der Protokollhandler implementiert das Protokoll für den Zugriff auf eine Inhaltsquelle im systemeigenen Format. Die ISearchProtocol- und ISearchProtocol2-Schnittstellen werden verwendet, um einen benutzerdefinierten Protokollhandler zu implementieren, um die Datenquellen, die indiziert werden können, zu erweitern.
Wenn die Abfrageergebnisse im Windows-Explorer angezeigt werden sollen, müssen Sie eine Shell-Datenquelle implementieren, bevor Sie einen Protokollhandler erstellen können, um den Index zu erweitern. Wenn jedoch alle Abfragen programmgesteuert sind (z. B. über OLE DB) und vom Code der Anwendung und nicht von der Shell interpretiert werden, ist ein Shell-Namespace, der weiterhin bevorzugt wird, nicht unbedingt erforderlich.
Hinweis
Eine Shell-Datenquelle wird manchmal als Shell-Namespaceerweiterung bezeichnet. Ein Handler wird manchmal als Shellerweiterung oder Shellerweiterungshandler bezeichnet.
Wenn Sie möchten, dass Benutzer ihre Suchergebnisse im Windows-Explorer anzeigen können, müssen Sie einen Protokollhandler und einen oder mehrere der folgenden Add-Ins erstellen:
- Kontextmenühandler
- Symbolhandler
- Ein anderer Dateihandlertyp
Eine Liste der vom Entwicklerszenario identifizierten Handler, die Sie erreichen möchten, finden Sie unter "Übersicht über Handler" in Windows Search als Entwicklungsplattform. Informationen zum Erstellen von Handlern finden Sie unter Registrieren von Shellerweiterungen, Kontextmenü und Dateityphandlern.
Protokollhandler
Wenn der Datenspeicher auch ein Container ist (z. B. ein Dateisystemordner), müssen Sie einen Filter implementieren, um die URLs im Container auflisten zu können. Wenn der Datenspeicher andere Daten oder Dateitypen als die 200 von Windows Search unterstützten enthält, müssen Sie einen Filter implementieren, um auf den Inhalt von Elementen im Speicher zugreifen und sie indizieren zu können. Windows Search verwendet Protokollhandler und IFilter-Technologie ähnlich der von SharePoint Server verwendeten. Wenn Sie bereits Filter für einen bestimmten Speicher und Dateityp auf dem System, das indiziert wird, installiert haben, kann Windows Search möglicherweise die vorhandenen Schnittstellen verwenden, um diese Daten indizieren.
Eine Übersicht über den Indizierungsprozess finden Sie unter Indizierungsprozess. Konzeptionelle Informationen zu Filterhandlern finden Sie unter Developing Filter Handlers.
Filter und Protokollhandler
Protokollhandler gewähren dem Windows Search-Indexer Zugriff auf Datenspeicher, sodass der Indexer die Knoten eines Datenspeichers durchforsten und relevante Informationen indexieren kann. Windows Search wird beispielsweise mit Protokollhandlern für Dateisystemspeicher und für einige Versionen von Microsoft Outlook-Datenspeichern ausgeliefert. Beim Indizieren von Outlook-E-Mails durchforstet der Protokollhandler alle Nachrichten in einer Reihe von Outlook-Ordnern und extrahiert Informationen aus jeder Nachricht und Anlage. Diese Informationen werden an den Indexer zur Aufnahme in den Windows Search-Katalog übergeben.
Übersichten über den Katalog-Manager und den Crawlbereichsmanager (Crawl Scope Manager, CSM) finden Sie unter Verwenden des Katalog-Managers und Verwenden des Crawlbereichsmanagers.
Indizieren eines Verbunddateiformats
Ein zusammengesetztes Dateiformat kann indiziert werden, sodass einzelne Elemente in der Datei als Einzelergebnisse zurückgegeben werden können. Ein zusammengesetztes Dateiformat, z. B. eine komprimierte Datei mit der Dateinamenerweiterung ZIP, ist im Wesentlichen ein Datenspeicher und kann zu Indizierungszwecken als solcher behandelt werden. Im folgenden Beispiel wird eine ZIP-Datei im Dateisystem-Namespace (FILE://c:/test/test.zip) angezeigt, in der sowohl Unterordner als auch einzelne Elemente vorhanden sind.
Test.zip
|-folder1
| |-folder2
| |- FileX.txt
|- FileY.doc
Der FILE-Protokollhandler erkennt, wenn sich FILE://c:/test/test.zip ändert, indem er Dateisystemänderungsprotokolle überwacht, und er löst einen IFilter aus, der für ZIP-Dateien in dieser Datei registriert ist, wenn sich die Datei ändert, er aber keine Kenntnisse über die interne Struktur der ZIP-Datei selbst hat.
Sie müssen den Indexer darüber informieren, dass das zusammengesetzte Dateiformat ein Datenspeicher ist. Dies ist erforderlich, damit einzelne Elemente indiziert und als eindeutige Entitäten abgerufen werden. Nachdem Sie eine Shell-Datenquelle implementiert und die folgenden Schritte ausgeführt haben, verfügen Sie über einen Protokollhandler, der die Daten aus einem zusammengesetzten Dateiformat (einer ZIP-Datei) als einzelne Elemente verarbeiten und verfügbar machen kann.
So informieren Sie den Indexer darüber, dass eine zusammengesetzte Datei ein Datenspeicher ist:
Erstellen Sie einen Protokollhandler (mit ISearchProtocol oder ISearchProtocol2) für ZIP-Dateien, welche die Möglichkeit der Bindung an die Quelldatei haben. Weitere Informationen finden Sie unter Installieren und Registrieren von Protokollhandlern.
Sie können z. B. einen Escapepfad zur ZIP-Datei als Stammordnernamen verwenden und dann einen Hierarchiesyntax wie jedes andere Dateiformat verwenden.
.zip:///escapedPathTo.zipFile/.zipfolder/.../.zipfileBei Verwendung der obigen Beispieldaten für c:\test\test\test.zip würden die eindeutigen URLs wie folgt aussehen. Bei diesen URLs verfügt der Protokollhandler über die erforderlichen Informationen zum Binden an die ZIP-Datei und zum Aufzählen die untergeordneten URLs einschließlich der inneren Dateien, sodass sie von den DOC- und TXT-Filtern gebunden und indiziert werden können.
.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.txtStellen Sie sicher, dass der Protokollhandler die folgenden beiden Bedingungen erfüllt:
- Die Stamm-URLs für eine ZIP-Datei sollten PKEY_Search_IsClosedDirectory (System.Search.IsClosedDirectory) für die URLs ausgeben, welche die Stamm-ZIP-Datei-URLs sind. Beispielsweise sollte .zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/ IsClosedDirectory = WAHR ausgeben. Dadurch wird dem Indexer mitgeteilt, dass, wenn sich das Datum dieser URL nicht geändert hat, keine der untergeordneten URLs verarbeiten werden muss.
- Jede untergeordnete URL für diese URL sollte PKEY_Search_IsFullyContained (System.Search.IsFullyContained) für die untergeordneten URLs der STAMM-ZIP-URL ausgeben. Normalerweise behandelt der Indexer am Ende eines inkrementellen Crawls alle nicht besuchten URLs als Elemente, die gelöscht werden sollen. Aber für die ZIP-Stammdatei sollten keine Stamm-URLs verarbeitet werden, weil nichts geändert wurde. Wenn diese Eigenschaft als WAHR gesendet wird, wird dem Indexer mitgeteilt, dass, wenn diese URL nicht am Ende eines inkrementellen Crawls verarbeitet wurde, sie trotzdem nicht gelöscht werden soll. Sie wird nur gelöscht, wenn sich das Stammelement geändert hat und sie nicht besucht wird.
Windows Search erfordert eine Startseite für ein Protokoll, um zu wissen, welche URLs inkrementell durchforstet werden sollen und welche URLs ignoriert werden sollen, wenn sie gefunden werden. Wir können jedoch nicht mit einer URL für jede ZIP-Datei beginnen, da wir nicht wissen, wo sich die ZIP-Dateien befinden. Daher muss die URL des ZIP-Protokollhandlers auf der Startseite in der Lage sein, alle Elemente im Stammverzeichnis der Escapepfade aller ZIP-Dateien aufzählen zu können. Diese ZIP-Dateien befinden sich nicht unbedingt im FILE:-Namespace und können eine MAPI-Typ-URL sein, die beispielsweise auf eine ZIP-Datei als Anlage verweist.
So registrieren Sie einen Stamm als Startseite:
Registrieren Sie einen Stamm wie .zip:/// als Startseite, damit alle ZIP-Dateien faktisch dort beginnen. Bei der Verarbeitung der ZIP-Stamm-URL sollte ihr Protokollhandler die Liste der untergeordneten URLs generieren, die ausgegeben werden sollen, durch eine Abfrage von Windows Search nach allen URLs mit System.FileExtension = „.zip“.
Escapen Sie diese URLs, um die Schrägstriche zu entfernen und sie als untergeordnete URLs zurückzugeben. Eine Beispielabfrage zum Abrufen der gewünschten Typen könnte wie folgt aussehen.
SELECT system.itemurl, System.DateModified FROM SystemIndex WHERE System.FileExtension='.zip' OR System.MimeType='mimetypefor.zip'Wenn Windows Search in regelmäßigen Abständen einen inkrementellen Crawl auf Ihrer Stamm-URL zip:/// durchführt, müssen Sie die Liste der URLs wiedergeben, die ZIP-URLs sind, die Windows Search bereits unterstützt. Wenn ein Löschvorgang im nativen Speicher erkannt wird, in dem die ZIP-Datei gespeichert ist, wird sie nicht in Ihrer Aufzählung angezeigt, und diese Verzweigung der Struktur in der ZIP-Datei wird entfernt.
Um eine Bindung an die ZIP-Daten für einen anderen Protokollhandler zu erstellen, sollten Sie idealerweise den IShellFolder für diese URL durchlaufen, um eine Bindung an den Speicher des Objekts zu erstellen, und nicht davon auszugehen, dass es sich zwingend um eine Datei handelt. Auf diese Weise haben Sie die Flexibilität, z. B. mit Anlagen in E-Mail-Speichern zu arbeiten.
Wenn Sie untergeordnete URLs für jede ZIP-Datei ausgeben, sollten Sie PKEY_Search_UrlToIndexWithModificationTime (System.Search.UrlToIndexWithModificationTime) verwenden, um PKEY_DateModified (System.DateModified) der tatsächlichen ZIP-Datei zu übergeben, sodass der Indexer die ZIP-Datei nur durchforstet, wenn sie geändert wurde.
Damit Ihre ZIP-URLs unmittelbar nach dem Erstellen oder Ändern indiziert werden und nicht auf einen inkrementellen Crawl warten müssen, um ihren neuen Zustand zu ermitteln, könnten Sie das Dateisystem möglicherweise selbst auf ZIP-Dateiänderungen überwachen. Ein solcher Ansatz würde jedoch nicht für andere Datenspeicher wie MAPI funktionieren.
Damit Ihre ZIP-URLs beim Erstellen oder Ändern indiziert werden:
- Erstellen Sie einen Filter (und implementieren Sie die IFilter-Schnittstelle) für den ZIP-Dateityp. Weitere Informationen finden Sie unter Entwicklung von Eigenschaftenhandlern für Windows Search.
- Wenn Ihre IFilter-Implementierung aufgerufen wird, liegt es daran, dass diese URL erkannt oder geändert wurde. Generieren Sie dann ein Ereignis für die ZIP-URL über die IGatherNotifyInline-Schnittstelle, das für die Quell-URL geeignet ist. Auf diese Weise können Sie dem Indexer sofort mitteilen, dass neue Daten indiziert werden müssen, ohne auf den inkrementellen Crawl warten zu müssen.
Zugehörige Themen