Noções básicas sobre Manipuladores de Protocolo
Alguns aplicativos armazenam seus itens em bancos de dados ou tipos de arquivo personalizados. Embora o Windows Search possa indexar o nome e as propriedades do arquivo, o Windows não tem conhecimento do conteúdo do arquivo. Como resultado, esses itens não podem ser indexados ou expostos no Shell do Windows. Ao criar um manipulador de protocolo, disponibilize esses itens para indexação. Também é possível indexar um formato de arquivo composto, como um arquivo .zip.
Este tópico é organizado da seguinte maneira:
- Indexar armazenamentos de dados com manipuladores de protocolo
- Indexar um formato de arquivo composto
- Tópicos relacionados
Indexar armazenamentos de dados com manipuladores de protocolo
Quando os usuários precisarem pesquisar bancos de dados herdados, repositórios de email ou outras estruturas de dados que não têm suporte pelo Windows Search, primeiro determine se já existe um manipulador de protocolo para esse armazenamento de dados, talvez para uso com outro aplicativo, como o SharePoint Server. Nesse caso, instale esse manipulador de protocolo no sistema. Os manipuladores de protocolo de Pesquisa do Windows usam especificações de design semelhantes ao SharePoint Server e geralmente podem ser usados de forma intercambiável.
Para obter mais informações sobre a implantação do Search Server 2008 com o Office SharePoint Server 2007, consulte Pesquisa Federada [Search Server 2008].
Armazenamentos de dados do Shell
Antes que um desenvolvedor terceirizado de novos formatos de arquivo e armazenamentos de dados possa obter esses formatos e repositórios para aparecer nos resultados da consulta no Windows Explorer, o desenvolvedor deve implementar uma fonte de dados do Shell. Uma fonte de dados do Shell é um componente usado para estender o namespace do Shell e expor itens em um armazenamento de dados. Um armazenamento de dados é um repositório de dados. Um armazenamento de dados pode ser exposto ao modelo de programação do Shell como um contêiner que usa uma fonte de dados do Shell. Os itens em um armazenamento de dados podem ser indexados pelo sistema de Windows Search usando um manipulador de protocolo. O manipulador de protocolo implementa o protocolo para acessar uma fonte de conteúdo em seu formato nativo. As interfaces ISearchProtocol e ISearchProtocol2 são usadas para implementar um manipulador de protocolo personalizado, para expandir as fontes de dados que podem ser indexadas.
Caso queira que os resultados da consulta apareçam no Windows Explorer, implemente uma fonte de dados do Shell antes de criar um manipulador de protocolo para estender o índice. No entanto, se todas as consultas forem programáticas (por meio do OLE DB, por exemplo) e interpretadas pelo código do aplicativo em vez do Shell, um namespace do Shell, embora ainda preferencial, não será estritamente necessário.
Observação
Às vezes, uma fonte de dados do Shell é conhecida como uma extensão de namespace do Shell. Às vezes, um manipulador é conhecido como uma extensão Shell ou um manipulador de extensão Shell.
Caso queira que os usuários exibam os resultados da pesquisa no Windows Explorer, crie um manipulador de protocolo e um ou mais dos seguintes suplementos:
- Manipulador de menu de atalho
- Manipulador de ícones
- Algum outro tipo de manipulador de arquivos
Para obter uma lista de manipuladores identificados pelo cenário de desenvolvedor que está tentando conseguir, consulte "Visão geral dos manipuladores" no Windows Search como uma Plataforma de Desenvolvimento. Para obter informações sobre como criar manipuladores, consulte Como registrar extensões de Shell, Menu de contexto e Manipuladores de tipo de arquivo.
Manipuladores de protocolo
Se o armazenamento de dados também for um contêiner (como uma pasta do sistema de arquivos), implemente um filtro para enumerar os URLs no contêiner. Se o armazenamento de dados contiver dados ou tipos de arquivo diferentes de um dos 200 tipos de arquivo com suporte pelo Windows Search, implemente um filtro para acessar e indexar o conteúdo dos itens no repositório. O Windows Search usa o manipulador de protocolo e a tecnologia IFilter semelhante à usada pelo SharePoint Server. Caso já tenha filtros para um repositório específico e tipo de arquivo instalado no sistema que está sendo indexado, o Windows Search poderá usar as interfaces existentes para indexar esses dados.
Para obter uma visão geral do processo de indexação, consulte O processo de indexação. Para obter informações conceituais sobre manipuladores de filtro, consulte Desenvolver manipuladores de filtro.
Filtros e manipuladores de protocolo
Os manipuladores de protocolo dão ao indexador do Windows Search acesso a armazenamentos de dados, permitindo que o indexador rastreie os nós de um armazenamento de dados e extraia informações relevantes para o índice. O Windows Search, por exemplo, fornece manipuladores de protocolo para repositórios de sistema de arquivos e para algumas versões de ambos os armazenamentos de dados do Microsoft Outlook. Ao indexar o email do Outlook, o manipulador de protocolo rastreia todas as mensagens em um conjunto de pastas do Outlook e extrai informações de cada mensagem e anexo. Essas informações são passadas ao indexador para inclusão no catálogo do Windows Search.
Para obter visões gerais do Gerenciador de Catálogos e do CSM (Gerenciador de Escopo de Rastreamento), consulte Usar o gerenciador de catálogos e Usar o gerenciador de escopo de rastreamento.
Indexar um formato de arquivo composto
Um formato de arquivo composto pode ser indexado para que itens individuais no arquivo possam ser retornados como resultados individuais. Um formato de arquivo composto, como um arquivo compactado com uma extensão de nome de arquivo .zip, é essencialmente um armazenamento de dados e pode ser tratado como tal para fins de indexação. O exemplo a seguir exibe um arquivo .zip no namespace do sistema de arquivos (FILE://c:/test/test.zip) no qual há subpastas e itens individuais.
Test.zip
|-folder1
| |-folder2
| |- FileX.txt
|- FileY.doc
O manipulador de protocolo de ARQUIVO descobre quando FILE://c:/test/test.zip é alterado ao monitorar logs de alteração do sistema de arquivos e invoca um IFilter registrado para arquivos .zip nesse arquivo quando é alterado, mas não tem conhecimento da estrutura interna do próprio arquivo .zip.
Informe ao indexador que o formato de arquivo composto é um armazenamento de dados. É necessário fazer isso para que itens individuais sejam indexados e recuperados como entidades exclusivas. Depois de implementar uma fonte de dados do Shell e executar as etapas a seguir, você terá um manipulador de protocolo que pode processar e expor os dados de um formato de arquivo composto (um arquivo .zip) como itens individuais.
Para informar ao indexador que um arquivo composto é um armazenamento de dados:
Crie um manipulador de protocolo (usando ISearchProtocolou ISearchProtocol2) para arquivos .zip que podem associar ao arquivo de origem. Para obter mais informações, consulte Instalar e registrar manipuladores de protocolo.
Por exemplo, use um caminho com escape para o arquivo .zip como o nome da pasta raiz e, em seguida, use uma sintaxe de hierarquia como qualquer outro formato de arquivo.
.zip:///escapedPathTo.zipFile/.zipfolder/.../.zipfileUsando os dados de exemplo acima para c:\test\test.zip, os URLs exclusivos seriam os seguintes. Com esses URLs, o manipulador de protocolo tem as informações necessárias para associar ao arquivo .zip e enumerar os URLs filho, incluindo os arquivos internos, para que possam ser associadas e indexadas pelos filtros .doc e .txt.
.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.txtVerifique se o manipulador de protocolo atende às duas condições a seguir:
- Os URLs raiz de um arquivo .zip devem emitir PKEY_Search_IsClosedDirectory (System.Search.IsClosedDirectory) nos URLs que são os URLs raiz de arquivo .zip. Por exemplo, .zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/ deve emitir IsClosedDirectory = TRUE. Isso informa ao indexador que, se a data desse URL não foi alterada, ele não precisará processar nenhum dos URLs filho.
- Cada URL filho para esse URL deve emitir PKEY_Search_IsFullyContained (System.Search.IsFullyContained) nos URLs filho do URL raiz do .zip. Normalmente, no final de um rastreamento incremental, o indexador trata todos os URLs não supervisionados como itens que devem ser excluídos. Mas o arquivo .zip raiz não deve processar os URLs raiz porque nada foi alterado. Emitir essa propriedade como TRUE informa ao indexador que, se esse URL não tiver sido processado no final de um rastreamento incremental, ele não deverá ser excluída. Ele só será excluído se o item raiz foi alterado e não for visitado.
O Windows Search requer uma página inicial para um protocolo para saber quais URLs devem ser rastreados incrementalmente e quais URLs devem ser ignorados quando forem encontradas. Mas não podemos começar com um URL para cada arquivo .zip, porque não sabemos onde está cada arquivo .zip. Portanto, o URL da página inicial do manipulador de protocolo .zip deve poder enumerar tudo na raiz dos caminhos com escape de todos os arquivos .zip. Esses arquivos .zip não estão necessariamente no namespace do ARQUIVO: e podem ser um URL de tipo MAPI que aponta para um arquivo .zip como um anexo, por exemplo.
Para registrar uma raiz como uma página inicial:
Registre uma raiz como .zip:/// como uma página inicial para que todos os arquivos .zip comecem lá, na verdade. Ao processar o URL raiz do .zip: o manipulador de protocolo deve gerar a lista de URLs filho a serem emitidas consultando o Windows Search para todas os URLs com System.FileExtension = ".zip".
Escape desses URLs para remover as barras e devolvê-las como URLs filho. Uma consulta de exemplo para recuperar os tipos que você deseja pode ter a seguinte aparência.
SELECT system.itemurl, System.DateModified FROM SystemIndex WHERE System.FileExtension='.zip' OR System.MimeType='mimetypefor.zip'Quando o Windows Search faz periodicamente um rastreamento incremental no URL raiz do .zip:///, você deve refletir de volta a lista de URLs que o Windows Search já mantém que são URLs .zip. Se uma exclusão for descoberta no repositório nativo onde o arquivo .zip está armazenado, ele não aparecerá em sua enumeração e esse branch da árvore no .zip será removido.
Para associar os dados .zip para outro manipulador de protocolo, você deve, idealmente, passar pelo IShellFolder para que o URL se associe ao armazenamento do objeto e não suponha que seja sempre um arquivo. Isso oferece flexibilidade para trabalhar com anexos em repositórios de correio, por exemplo.
Ao emitir URLs filho para cada arquivo .zip, use PKEY_Search_UrlToIndexWithModificationTime (System.Search.UrlToIndexWithModificationTime) para passar PKEY_DateModified (System.DateModified) do arquivo .zip real para que o indexador rastreie o arquivo .zip somente se ele foi alterado.
Para que os URLs .zip sejam indexados imediatamente após serem criados ou modificados e não precise aguardar um rastreamento incremental para descobrir seu novo estado, monitore o sistema de arquivos por conta própria para alterações de arquivo .zip. No entanto, essa abordagem não funcionaria para outros armazenamentos de dados, como MAPI.
Para que os URLs .zip sejam indexados quando forem criados ou modificados:
- Crie um filtro (e implementação da interface IFilter) para o tipo de arquivo .zip. Para obter mais informações, consulte Desenvolvendo manipuladores de propriedades para o Windows Search.
- Sempre que a implementação do IFilter é chamada, é porque esse URL foi descoberto ou alterado. Em seguida, gere um evento para o URL .zip apropriado para o URL de origem, por meio da interface IGatherNotifyInline. Isso permite informar imediatamente ao indexador que há novos dados a serem indexados sem precisar aguardar o rastreamento incremental.
Tópicos relacionados
-
Exemplo de código: extensões de Shell para manipuladores de protocolo
-
Criar um conector de pesquisa para um manipulador de protocolo
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de