Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Egyes alkalmazások az elemeket adatbázisokban vagy egyéni fájltípusokban tárolják. Bár a Windows Search képes indexelni a fájl nevét és tulajdonságait, a Windows nem ismeri a fájl tartalmát. Ennek eredményeképpen az ilyen elemek nem indexelhetők és nem tehetők közzé a Windows Shellben. Egy protokollkezelő létrehozásával ezeket az elemeket elérhetővé teheti indexelésre. Összetett fájlformátumokat, például .zip fájlokat is indexelhet.
Ez a témakör a következőképpen van rendszerezve:
- adattárak indexelése protokollkezelőkkel
- Összetett fájlformátumú indexelése
- Kapcsolódó témakörök
Adattárak indexelése protokollkezelőkkel
Ha a felhasználóknak régi adatbázisokban, e-mail-tárolókban vagy más, a Windows Search által nem támogatott adatstruktúrákban kell keresnie, először meg kell határoznia, hogy létezik-e már protokollkezelő az adott adattárhoz, esetleg egy másik alkalmazáshoz, például a SharePoint Serverhez. Ha igen, telepítheti a protokollkezelőt a rendszerre. A Windows Search protokollkezelői a SharePoint Serverhez hasonló tervezési specifikációkat használnak, és gyakran felcserélhetők.
További információ a Search Server 2008 Office SharePoint Server 2007-ben történő telepítéséről: Összevont keresés [Search Server 2008].
Shell-adattárak
Mielőtt az új fájlformátumok és adattárak külső fejlesztője lekérheti ezeket a formátumokat és tárolókat a lekérdezési eredményekben a Windows Intézőben, a fejlesztőnek implementálnia kell egy Shell-adatforrást. A Shell-adatforrások olyan összetevők, amelyek a Shell-névtér kibővítésére és az adattárban lévő elemek elérhetővé tételére szolgálnak. Az adattár az adatok adattára. Az adattárak a Shell-programozási modell számára egy Shell-adatforrást használó tárolóként is elérhetők. Az adattár elemeit a Windows Search rendszer egy protokollkezelővel indexelheti. A protokollkezelő implementálja a protokollt egy tartalomforrás natív formátumban való eléréséhez. Az ISearchProtocol és ISearchProtocol2 felületek használatával egyéni protokollkezelőt implementálhat az indexelhető adatforrások kibontásához.
Ha azt szeretné, hogy a lekérdezés eredményei megjelenjenek a Windows Intézőben, implementálnia kell egy Shell-adatforrást, mielőtt létrehozna egy protokollkezelőt az index kiterjesztéséhez. Ha azonban az összes lekérdezés programozott lesz (például OLE DB-n keresztül), és az alkalmazás kódja értelmezi a Shell helyett, akkor a Rendszerhéj névterének használata továbbra sem feltétlenül szükséges.
Jegyzet
A Shell-adatforrásokat néha Shell-névtérbővítménynek is nevezik. A kezelőt néha Shell-bővítménynek vagy Shell-bővítménykezelőnek is nevezik.
Ha azt szeretné, hogy a felhasználók a Windows Intézőben tekintsék meg a keresési eredményeket, akkor létre kell hoznia egy protokollkezelőt és egy vagy több alábbi bővítményt:
- Helyi menükezelő
- Ikonkezelő
- Más típusú fájlkezelő
Az elérni kívánt fejlesztői forgatókönyv által azonosított kezelők listáját lásd: "Kezelők áttekintése" Windows Search mint fejlesztési platform. További információ a kezelők létrehozásáról: Shell-bővítmények regisztrálása, Helyi menüés Fájltípus-kezelők.
Protokollkezelők
Ha az adattár szintén tároló (például fájlrendszermappa), akkor egy szűrőt kell implementálnia a tároló URL-címeinek számbavételéhez. Ha az adattár a Windows Search által támogatott 200 fájltípustól eltérő adatokat vagy fájltípusokat tartalmaz, akkor egy szűrőt kell implementálnia az áruház elemeinek eléréséhez és indexeléséhez. A Windows Search a SharePoint Server által használthoz hasonló protokollkezelőt és IFilter technológiát használ. Ha már rendelkezik az indexelt rendszeren egy adott tárolóra és fájltípusra vonatkozó szűrőkkel, előfordulhat, hogy a Windows Search a meglévő felületekkel indexeli ezeket az adatokat.
Az indexelési folyamat áttekintését az Az indexelési folyamatcímű cikkben tekintheti meg. A szűrőkezelőkre vonatkozó elméleti információkért tekintse meg Szűrőkezelők fejlesztésecímű témakört.
Szűrők és protokollkezelők
A protokollkezelők hozzáférést biztosítanak a Windows Search indexelőjének az adattárakhoz, így az indexelő bejárhatja az adattár csomópontjait, és releváns információkat nyerhet ki az indexeléshez. A Windows Search például a fájlrendszertárolókhoz és a Microsoft Outlook-adattárak egyes verzióihoz tartozó protokollkezelőket tartalmazza. Az Outlook-e-mailek indexelésekor a protokollkezelő bejárja az Outlook-mappák összes üzenetét, és adatokat nyer ki az egyes üzenetekből és mellékletekből. Ezeket az információkat a rendszer átadja az indexelőnek, hogy bekerüljön a Windows Search katalógusába.
A Catalog Manager és a Bejárási Hatókör-kezelő (CSM) áttekintéséhez lásd: A Catalog Manager használata és A Bejárási Hatókör-kezelő használata.
Összetett fájlformátum indexelése
Az összetett fájlformátumok indexelhetők, így a fájl egyes elemei egyedi eredményként is visszaadhatók. Az összetett fájlformátumok, például a .zip fájlnévkiterjesztéssel rendelkező tömörített fájlok alapvetően adattárak, és indexelés céljából is kezelhetők. Az alábbi példa egy .zip fájlt jelenít meg a fájlrendszer névterében (FILE://c:/test/test.zip), amelyben almappák és egyes elemek is találhatók.
Test.zip
|-folder1
| |-folder2
| |- FileX.txt
|- FileY.doc
A FILE protokollkezelő a fájlrendszer változásnaplóinak figyelésével észleli, amikor a FILE://c:/test/test.zip módosul, és ilyenkor meghív egy IFilter--t, amelyet a .zip fájlokhoz regisztráltak, de nem ismeri a .zip fájl belső szerkezetét.
Tájékoztatnia kell az indexelőt, hogy az összetett fájlformátum egy adattár. Erre azért van szükség, hogy az egyes elemeket egyedi entitásokként indexelje és kérje le. Miután implementált egy Shell-adatforrást, és elvégezte a következő lépéseket, egy protokollkezelővel fog rendelkezni, amely képes feldolgozni és elérhetővé tenni az adatokat összetett fájlformátumból (egy .zip fájlból) egyéni elemként.
Az indexelő tájékoztatása arról, hogy egy összetett fájl egy adattár:
Hozzon létre egy protokollkezelőt (ISearchProtocol vagy ISearchProtocol2használatával) olyan .zip fájlokhoz, amelyek képesek kapcsolódni a forrásfájlhoz. További információ: Protokollkezelők telepítése és regisztrálása.
Használhat például egy elérési utat a .zip fájlhoz gyökérmappanévként, majd használhat egy hierarchiaszintaxist, mint bármely más fájlformátumot.
.zip:///escapedPathTo.zipFile/.zipfolder/.../.zipfileA c:\test\test.zipfenti mintaadatait használva az egyedi URL-címek a következők. Ezekkel az URL-címekkel a protokollkezelő rendelkezik a .zip fájlhoz való kötéshez szükséges információkkal, és számba kell vennie a gyermek URL-címeket, beleértve a belső fájlokat is, hogy azok a .doc és .txt szűrőkhöz legyenek kötve és indexelhetők.
.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.txtGyőződjön meg arról, hogy a protokollkezelő megfelel a következő két feltételnek:
- A .zip-fájlok gyökér URL-címeinek a PKEY_Search_IsClosedDirectory-t (System.Search.IsClosedDirectory) kell kibocsátaniuk olyan URL-címeken, amelyek gyökér .zip fájl URL-címek. Például: .zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/ IsClosedDirectory = TRUE. Ez azt jelzi az indexelőnek, hogy ha az URL-cím dátuma nem változott, akkor nem kell feldolgoznia a gyermek URL-címeket.
- Az URL-címhez tartozó minden gyermek URL-címnek a gyökér .zip URL-cím gyermek URL-címein kell kibocsátania a PKEY_Search_IsFullyContained (System.Search.IsFullyContained) értéket. Általában a növekményes bejárás végén az indexelő az összes nem felügyelt URL-címet törölni kívánt elemként kezeli. A gyökér .zip fájlnak azonban nem szabad feldolgoznia a gyökér URL-címeket, mert semmi sem változott. Ha ezt a tulajdonságot TRUE értékre állítja, az indexelő azt jelzi, hogy ha ezt az URL-címet nem dolgozták fel növekményes bejárás végén, akkor nem szabad törölni. Csak akkor törlődik, ha a gyökérelem módosult, és nem lett megtekintve.
A Windows Search használatához egy protokoll kezdőoldalára van szükség ahhoz, hogy megtudja, milyen URL-címek legyenek növekményesen bejárva, és mely URL-címeket kell figyelmen kívül hagyni a kereséskor. Az egyes .zip fájlok URL-címével azonban nem kezdjük, mert nem tudjuk, hol találhatók az egyes .zip fájlok. Ezért a .zip protokollkezelő kezdőoldali URL-címének képesnek kell lennie felsorolni mindent, ami az összes .zip fájl megszökött elérési útjának gyökerében található. Ezek a .zip fájlok nem feltétlenül szerepelnek a FÁJL: névtérben, és lehet egy MAPI típusú URL-cím, amely például mellékletként egy .zip fájlra mutat.
Egy gyökér regisztrálása kezdőlapként:
Regisztráljon egy gyökeret, például a .zip:///-t kezdőlapként, hogy ténylegesen az összes .zip fájl onnan induljon. A gyökér .zip: URL-cím feldolgozásakor a protokollkezelőnek létre kell hoznia a kibocsátandó gyermek URL-címek listáját a Windows Searchben a System.FileExtension = ".zip" url-címmel rendelkező összes URL-cím lekérdezésével.
Az URL-eket úgy módosítsa, hogy eltávolítja a perjeleket, majd gyermek URL-ként adja vissza őket. A kívánt típusokat lekérdező példalekérdezés az alábbiak szerint nézhet ki.
SELECT system.itemurl, System.DateModified FROM SystemIndex WHERE System.FileExtension='.zip' OR System.MimeType='mimetypefor.zip'Ha a Windows Search rendszeresen inkrementális bejárást végez a .zip:/// gyökér URL-en, tükröznie kell azoknak az URL-eknek a listáját, amelyeket a Windows Search már fenntart, és amelyek .zip URL-ek. Ha a rendszer a .zip fájlt tároló natív tárolóban észlel törlést, az nem jelenik meg az enumerálásban, és a .zip fa ága el lesz távolítva.
Egy másik protokollkezelő .zip adataihoz való kötéshez ideális esetben az IShellFolder-t kell használnia az URL-hez, hogy az objektum tárolójához kötődjön, és ne feltételezze, hogy az mindig fájl. Így például rugalmasan dolgozhat a mellékletekkel a levelezési áruházakban.
Ha aldomain URL-címeket generál minden egyes .zip fájlhoz, akkor a PKEY_Search_UrlToIndexWithModificationTime (System.Search.UrlToIndexWithModificationTime) segítségével kell átadnia a tényleges .zip fájl PKEY_DateModified (System.DateModified) értékét annak érdekében, hogy az indexelő csak akkor futtassa le a .zip fájlt, ha az megváltozott.
Ahhoz, hogy a .zip URL-címeket közvetlenül a létrehozásuk vagy módosításuk után indexelje, és nem kell várnia a növekményes bejárásra az új állapotuk felderítéséhez, elképzelhető, hogy ön is figyeli a fájlrendszert .zip fájlmódosítások esetén. Ez a megközelítés azonban nem működne más adattárakban, például a MAPI-ben.
A .zip URL-címeinek indexelése létrehozásukkor vagy módosításakor:
- Hozzon létre egy szűrőt (és az IFilter felület implementációját) a .zip fájltípushoz. További információ: A Windows Searchtulajdonságkezelőinek fejlesztése.
- Amikor a IFilter implementációját meghívják, azért mert az URL-t felfedezték vagy megváltozott. Ezután hozzon létre egy eseményt a forrás URL-címének megfelelő .zip URL-címhez az IGatherNotifyInline felületen keresztül. Ezzel az indexelővel azonnal közölheti, hogy új adatokat kell indexelni, anélkül, hogy kell várnia az inkrementális bejárásra.
Kapcsolódó témakörök