다음을 통해 공유


프로토콜 처리기 이해

일부 애플리케이션은 해당 항목을 데이터베이스 또는 사용자 지정 파일 형식에 저장합니다. Windows Search는 파일의 이름과 속성을 인덱싱할 수 있지만 Windows에서는 파일의 내용을 알지 않습니다. 따라서 이러한 항목은 Windows 셸에서 인덱싱하거나 노출할 수 없습니다. 프로토콜 처리기를 만들어 이러한 항목을 인덱싱에 사용할 수 있도록 할 수 있습니다. .zip 파일과 같은 복합 파일 형식을 인덱싱할 수도 있습니다.

이 항목은 다음과 같이 구성됩니다.

프로토콜 처리기를 사용하여 데이터 저장소 인덱싱

사용자가 Windows Search에서 지원하지 않는 레거시 데이터베이스, 전자 메일 저장소 또는 기타 데이터 구조를 검색해야 하는 경우 먼저 SharePoint Server와 같은 다른 응용 프로그램에서 사용하기 위해 해당 데이터 저장소에 대한 프로토콜 처리기가 이미 있는지 확인해야 합니다. 그렇다면 해당 프로토콜 처리기를 시스템에 설치할 수 있습니다. Windows Search 프로토콜 처리기는 SharePoint Server와 유사한 디자인 사양을 사용하며 종종 서로 교환하여 사용할 수 있습니다.

Office SharePoint Server 2007을 사용한 Search Server 2008 배포에 대한 자세한 내용은 페더레이션 검색 [Search Server 2008]을 참조하세요.

Shell 데이터 저장소

새 파일 형식 및 데이터 저장소의 타사 개발자가 Windows 탐색기의 쿼리 결과에 표시할 형식 및 저장소를 가져오기 전에 개발자는 셸 데이터 원본을 구현해야 합니다. 셸 데이터 원본은 셸 네임스페이스를 확장하고 데이터 저장소의 항목을 노출하는 데 사용되는 구성 요소입니다. 데이터 저장소는 데이터의 리포지토리입니다. 셸 프로그래밍 모델에 셸 데이터 원본을 사용하는 컨테이너로 데이터 저장소를 노출할 수 있습니다. 데이터 저장소의 항목은 프로토콜 처리기를 사용하여 Windows Search 시스템에서 인덱싱할 수 있습니다. 프로토콜 처리기는 기본 형식으로 콘텐츠 원본에 액세스하기 위한 프로토콜을 구현합니다. ISearchProtocolISearchProtocol2 인터페이스는 사용자 지정 프로토콜 처리기를 구현하여 인덱싱할 수 있는 데이터 원본을 확장하는 데 사용됩니다.

Windows 탐색기에 쿼리 결과를 표시하려면 인덱스 확장을 위한 프로토콜 처리기를 만들려면 먼저 셸 데이터 원본을 구현해야 합니다. 그러나 모든 쿼리가 프로그래밍 방식으로(예: OLE DB를 통해) 셸이 아닌 애플리케이션의 코드로 해석되는 경우 셸 네임스페이스가 계속 선호되는 것은 아닙니다.

참고 항목

셸 데이터 원본을 셸 네임스페이스 확장이라고도 합니다. 처리기를 셸 확장 또는 셸 확장 처리기라고도 합니다.

 

사용자가 Windows 탐색기 내에서 검색 결과를 보도록 하려면 프로토콜 처리기와 다음 추가 기능 중 하나 이상을 만들어야 합니다.

  • 바로 가기 메뉴 처리기
  • 아이콘 처리기
  • 다른 형식의 파일 처리기

달성하려는 개발자 시나리오로 식별되는 처리기 목록은 Windows Search에서 개발 플랫폼으로 "처리기 개요"를 참조하세요. 처리기를 만드는 방법에 대한 자세한 내용은 셸 확장명, 상황에 맞는 메뉴파일 형식 처리기 등록을 참조하세요.

프로토콜 처리기

데이터 저장소가 컨테이너(예: 파일 시스템 폴더)인 경우 컨테이너의 URL을 열거하는 필터를 구현해야 합니다. 데이터 저장소에 Windows Search에서 지원하는 200개의 파일 형식 중 하나 이외의 데이터 또는 파일 형식이 포함된 경우 저장소의 항목 내용에 액세스하고 인덱싱하는 필터를 구현해야 합니다. Windows Search는 SharePoint Server에서 사용하는 것과 유사한 프로토콜 처리기 및 IFilter 기술을 사용합니다. 인덱싱되는 시스템에 특정 저장소 및 파일 형식에 대한 필터가 이미 설치된 경우 Windows Search에서 기존 인터페이스를 사용하여 이 데이터를 인덱싱할 수 있습니다.

인덱싱 프로세스에 대한 개요는 인덱싱 프로세스를 참조 하세요. 필터 처리기에 대한 개념 정보는 필터 처리기 개발을 참조 하세요.

필터 및 프로토콜 처리기

프로토콜 처리기는 Windows Search 인덱서가 데이터 저장소에 액세스할 수 있도록 하여 인덱서가 데이터 저장소의 노드를 크롤링하고 인덱스에 대한 관련 정보를 추출할 수 있도록 합니다. 예를 들어 Windows Search는 파일 시스템 저장소 및 Microsoft Outlook 데이터 저장소의 일부 버전에 대한 프로토콜 처리기와 함께 제공됩니다. Outlook 전자 메일을 인덱싱할 때 프로토콜 처리기는 Outlook 폴더 집합의 모든 메시지를 크롤링하고 각 메시지 및 첨부 파일에서 정보를 추출합니다. 이 정보는 Windows Search 카탈로그에 포함되도록 인덱서에 전달됩니다.

카탈로그 관리자 및 CSM(크롤링 범위 관리자)의 개요는 카탈로그 관리자 사용 및 크롤링 범위 관리자 사용을 참조하세요.

복합 파일 형식 인덱싱

파일의 개별 항목을 개별 결과로 반환할 수 있도록 복합 파일 형식을 인덱싱할 수 있습니다. .zip 파일 이름 확장명을 가진 압축 파일과 같은 복합 파일 형식은 기본적으로 데이터 저장소이며 인덱싱 목적으로 처리할 수 있습니다. 다음 예제에서는 하위 폴더와 개별 항목이 모두 있는 파일 시스템 네임스페이스(FILE://c:/test/test.zip)에 .zip 파일을 표시합니다.

Test.zip 

    |-folder1 

    |    |-folder2 

    |           |- FileX.txt 

    |- FileY.doc

FILE 프로토콜 처리기는 파일 시스템 변경 로그를 모니터링하여 FILE://c:/test/test.zip 변경될 때를 검색하고 파일이 변경될 때 해당 파일의 .zip 파일에 등록된 IFilter를 호출하지만 .zip 파일 자체의 내부 구조를 알지는 않습니다.

복합 파일 형식이 데이터 저장소임을 인덱서에 알려야 합니다. 개별 항목을 인덱싱하고 고유 엔터티로 검색하려면 이 작업을 수행해야 합니다. 셸 데이터 원본을 구현하고 다음 단계를 수행한 후에는 복합 파일 형식(.zip 파일)의 데이터를 개별 항목으로 처리하고 노출할 수 있는 프로토콜 처리기가 있습니다.

복합 파일이 데이터 저장소임을 인덱서에 알리려면 다음을 수행합니다.

  1. 소스 파일에 바인딩할 수 있는 .zip 파일에 대한 프로토콜 처리기(ISearchProtocol 또는 ISearchProtocol2 사용)를 만듭니다. 자세한 내용은 프로토콜 처리기 설치 및 등록을 참조 하세요.

    예를 들어 .zip 파일에 대한 이스케이프된 경로를 루트 폴더 이름으로 사용한 다음 다른 파일 형식과 같은 계층 구문을 사용할 수 있습니다.

    .zip:///escapedPathTo.zipFile/.zipfolder/.../.zipfile
    

    c:\test\test.zip에 위의 샘플 데이터를 사용하면 고유한 URL은 다음과 같습니다. 이러한 URL을 사용하여 프로토콜 처리기에는 .zip 파일에 바인딩하고 내부 파일을 포함한 자식 URL을 열거하는 데 필요한 정보가 있으므로 .doc 및 .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.txt
    
  2. 프로토콜 처리기가 다음 두 조건을 충족하는지 확인합니다.

    • .zip 파일의 루트 URL은 루트 .zip 파일 URL인 URL에서 PKEY_Search_IsClosedDirectory(System.Search.IsClosedDirectory)를 내보내야 합니다. 예를 들어 .zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/ IsClosedDirectory = TRUE를 내보내야 합니다. 이렇게 하면 이 URL의 날짜가 변경되지 않은 경우 자식 URL을 처리할 필요가 없음을 인덱서에 알릴 수 있습니다.
    • 해당 URL의 모든 자식 URL은 루트 .zip URL의 자식 URL에 PKEY_Search_IsFullyContained(System.Search.IsFullyContained)를 내보내야 합니다. 일반적으로 증분 크롤링이 끝날 때 인덱서는 보이지 않는 모든 URL을 삭제해야 하는 항목으로 처리합니다. 그러나 루트 .zip 파일은 변경되지 않았으므로 루트 URL을 처리해서는 안 됩니다. 이 속성을 TRUE내보내면 이 URL이 증분 크롤링의 끝에서 처리되지 않은 경우 삭제해서는 안 됨을 인덱서에 알릴 수 있습니다. 루트 항목이 변경되고 방문하지 않는 경우에만 삭제됩니다.

Windows Search를 사용하려면 증분 방식으로 크롤링할 URL과 검색할 때 무시해야 하는 URL을 파악하기 위해 프로토콜에 대한 시작 페이지가 필요합니다. 그러나 각 .zip 파일의 위치를 모르기 때문에 각 .zip 파일에 대한 URL로 시작할 수 없습니다. 따라서 .zip 프로토콜 처리기의 시작 페이지 URL은 모든 .zip 파일의 이스케이프된 경로 루트에 있는 모든 항목을 열거할 수 있어야 합니다. 이러한 .zip 파일은 반드시 FILE: 네임스페이스에 있는 것은 아니며.zip 파일을 첨부 파일로 가리키는 MAPI 형식 URL일 수 있습니다.

루트를 시작 페이지로 등록하려면 다음을 수행합니다.

  1. .zip:/// 같은 루트를 시작 페이지로 등록하여 모든 .zip 파일이 실제로 시작되도록 합니다. 루트 .zip: URL을 처리할 때 프로토콜 처리기는 System.FileExtension = ".zip"을 사용하여 모든 URL에 대해 Windows Search를 쿼리하여 내보낼 자식 URL 목록을 생성해야 합니다.

  2. 이러한 URL을 이스케이프하여 슬래시를 제거하고 자식 URL로 반환합니다. 원하는 형식을 검색하는 예제 쿼리는 다음과 같습니다.

    SELECT system.itemurl, System.DateModified FROM SystemIndex 
    WHERE System.FileExtension='.zip' OR System.MimeType='mimetypefor.zip'
    
  3. Windows Search가 .zip:/// 루트 URL에서 주기적으로 증분 크롤링을 수행하는 경우 Windows Search가 이미 기본 .zip URL과 관련된 URL 목록을 다시 반영해야 합니다. .zip 파일이 저장된 네이티브 저장소에서 삭제가 검색되면 열거형에 표시되지 않으며 .zip에 있는 트리의 분기가 제거됩니다.

  4. 다른 프로토콜 처리기의 .zip 데이터에 바인딩하려면 해당 URL에 대한 IShellFolder를 통해 개체의 스토리지에 바인딩하고 항상 파일이라고 가정하지 않는 것이 좋습니다. 이렇게 하면 예를 들어 메일 저장소에서 첨부 파일을 유연하게 사용할 수 있습니다.

  5. 각 .zip 파일에 대해 자식 URL을 내보낸 경우 인덱서가 변경된 경우에만 .zip 파일을 크롤링하도록 실제 .zip 파일의 PKEY_DateModified(System.DateModified)를 전달하려면 PKEY_Search_UrlToIndexWithModificationTime(System.Search.UrlToIndexWithModificationTime)를 사용해야 합니다.

.zip URL을 만들거나 수정한 직후에 인덱싱하고 증분 크롤링이 새 상태를 검색할 때까지 기다릴 필요가 없도록 하려면 파일 시스템에서 .zip 파일 변경 내용을 직접 모니터링할 수 있습니다. 그러나 MAPI와 같은 다른 데이터 저장소에서는 이러한 접근 방식이 작동하지 않습니다.

.zip URL을 만들거나 수정할 때 인덱싱하려면 다음을 수행합니다.

  1. .zip 파일 형식에 대한 필터(및 IFilter 인터페이스 구현)를 만듭니다. 자세한 내용은 Windows Search용 속성 처리기 개발을 참조하세요.
  2. IFilter 구현이 호출될 때마다 해당 URL이 검색되거나 변경되었기 때문입니다. 그런 다음 IGatherNotifyInline 인터페이스를 통해 원본 URL에 적합한 .zip URL에 대한 이벤트를 생성합니다. 이렇게 하면 증분 크롤링을 기다리지 않고도 인덱싱할 새 데이터가 있음을 인덱서에 즉시 알릴 수 있습니다.

프로토콜 처리기 개발

프로토콜 처리기 설치 및 등록

변경 내용 인덱스 알림

아이콘 및 상황에 맞는 메뉴 추가

코드 샘플: 프로토콜 처리기용 셸 확장

프로토콜 처리기 설치 및 등록

프로토콜 처리기에 대한 검색 커넥트or 만들기

프로토콜 처리기 디버깅