다음을 통해 공유

속성 시스템 개요

  • 아티클

Windows 속성 시스템은 셸 항목에 대한 메타데이터를 균일하게 표현하는 방법을 제공하는 확장 가능한 데이터 정의 읽기/쓰기 시스템입니다. Windows Vista 이상의 Windows 속성 시스템을 사용하면 셸 항목에 대한 메타데이터를 저장하고 검색할 수 있습니다. 셸 항목은 파일, 폴더, 전자 메일 또는 연락처와 같은 단일 콘텐츠입니다. 속성은 셸 항목과 연결된 개별 메타데이터 조각입니다. 속성 값은 PROPVARIANT 구조체로 표현됩니다.

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

소개

속성은 정식 이름(예: ) 및 속성 키(예: System.Document.LastAuthor)로 PKEY_Document_LastAuthor고유하게 식별됩니다. PKEY(속성 키)는 PKEY/PROPVARIANT 또는 문자열/PROPVARIANT로 구성된 이름-값 쌍의 이름 부분입니다. 여기서 문자열은 PKEY의 정식 이름(예: System.Document.LastAuthor)입니다. PKEY는 속성에 대해 알아야 할 모든 것을 속성 시스템에 알려주는 정의이지만 값은 속성의 실제 instance. PKEY는 내부적으로 formatID 및 propID를 포함합니다.

개별 속성은 다음 세 부분으로 구성됩니다.

  • 정식 이름(예: System.Music.Artist)입니다.
  • .propdesc XML 파일 형식으로 지정되고 IPropertyDescription을 통해 프로그래밍 방식으로 표현되는 스키마 설명입니다.
  • 가수의 이름과 같은 값입니다.

스키마 설명은 속성 이름, 데이터 형식, 제약 조건, 속성이 뷰 및 검색 시스템과 상호 작용하는 방법에 대한 정보 등 속성에 대한 정보로 구성됩니다. 이름 및 스키마 설명은 전역적으로 정의되며 모든 항목 및 형식에 대해 동일합니다. 값은 개별 항목과 관련이 있습니다. 즉, System.Music.Artist 속성은 항상 다중 값 문자열로 정의되지만 각 항목에 대해 다른 값(또는 값 없음)이 있을 수 있습니다.

속성 처리기는 파일에 저장된 데이터를 Windows Explorer, Windows Search 및 기타 애플리케이션에서 인식하고 액세스할 수 있는 구조화된 스키마로 변환합니다. 그런 다음 이러한 시스템은 속성 처리기와 상호 작용하여 파일과 속성을 쓰고 읽을 수 있습니다. 번역된 데이터는 프로그래밍 방식으로 노출되며 세부 정보 보기, 정보 설명, 세부 정보 창, 속성 페이지 등 다양한 컨텍스트에서 Windows Explorer 통해 사용자에게 표시됩니다. 각 속성 처리기는 파일 이름 확장명으로 식별되는 특정 파일 형식과 연결됩니다. 개발자는 파일 형식의 네이티브 형식(예: .jpg 또는 .png)을 생성하고 사용하는 속성 처리기를 구현하거나 MS-PROPSTORE 이진 형식을 생성하고 사용하는 In-Memory 속성 저장소를 사용해야 합니다.

Windows 속성 시스템은 개별 파일 형식에서 추상화 수준을 제공하는 추상 데이터 모델을 만듭니다. Windows 속성 시스템에서 제공하는 추상 데이터 모델은 셸 항목과 연결된 확장 가능한 명명된 값 집합을 읽고 쓰는 방법입니다. 값 식은 유연하고 많은 데이터 형식을 지원하며 확장 가능하므로 임의의 데이터(VT_BLOB) 및 개체를 값으로 표현할 수 있습니다.

추상화로 인해 모든 항목의 특성 또는 메타데이터를 쿼리할 수 있습니다. 추상화할 수 있는 항목의 예로는 Microsoft Office 문서, ID3 태그, AutoCAD 및 기타 타사 독점 소프트웨어가 있습니다. 마찬가지로 .jpeg 파일이 있는 경우 .jpeg 및 EXIF 코덱을 사용하여 파일의 바이트를 읽어 이미지의 크기를 검색할 수 있습니다. 대신 .png 파일이 있는 경우 다른 코덱과 다른 코드가 필요합니다. Windows 속성 시스템을 사용하면 이러한 종류의 문제를 방지할 수 있습니다. 새 파일 형식을 구현하는 경우 Windows 속성 시스템에서 제공하는 균일한 추상화에 연결하고 메타데이터를 소모성으로 만드는 방법을 지정할 수 있습니다. 이러한 이유로 Windows 속성 시스템에서 제공하는 공통 플랫폼을 사용하는 것이 항상 좋습니다.

개발 시나리오

속성은 생산자와 소비자가 표현합니다. 이 컨텍스트에서 생산자는 Windows 속성 시스템의 속성 인벤토리이며 소비자는 이 시스템의 속성 정보를 사용하는 애플리케이션(및 개발자)입니다. Windows 속성 시스템의 및 참가자 사용은 다음 표에서 확인할 수 있습니다.

Windows 속성 시스템 사용 참가자
속성 설명의 확장 가능한 레지스트리, 메모리 내 속성 저장소 구현 및 속성 처리기에 바인딩, 형식 변환 및 속성 저장소 직렬화를 위한 서비스를 제공하는 빌딩 블록입니다. 소비자
추상적인 방식으로 속성을 읽고 쓰려는 애플리케이션입니다. 소비자
사용자 지정 속성 스키마를 정의하고 자체 속성 처리기를 개발하여 속성 시스템에 대한 새 속성을 정의하는 속성 인벤토리입니다. Producer
사용자 지정 파일 형식으로 저장된 속성에 대한 액세스를 사용하도록 설정하려는 파일 형식 소유자입니다. Producer

 

소비자는 기존 속성, 스키마 및 속성 처리기를 사용합니다. 사용할 수 있는 속성에는 지원되는 파일 형식에 대한 속성 처리기의 읽기/쓰기 속성이 포함되며 일부 사용자 지정 속성도 포함될 수 있습니다. 사용 가능한 스키마에는 적어도 시스템 스키마와 다른 스키마도 포함됩니다. 소비자는 항목이 저장되는 폴더에 관계없이 메타데이터를 사용하고 아티스트를 기반으로 보기를 빌드하는 애플리케이션을 만들 수 있습니다. 파일 폴더 계층 구조는 관련이 없습니다. 예를 들어 특정 가수가 해당 항목의 위치를 염려하지 않고 모든 노래 항목을 지정할 수 있습니다. 이 복잡한 엔드 투 엔드 시나리오는 Windows 속성 시스템에 국한되지 않지만 인덱싱 및 검색 폴더와 같은 여러 구성 요소가 포함됩니다.

속성 인벤토리 또는 타사 개발자는 Windows 속성 시스템의 생산자입니다. 새 속성을 정의할 준비를 할 때 먼저 Windows에서 정의하는 속성 집합을 검사합니다. 요구 사항을 충족하는 형식과 필요한 사용과 일치하는 의미 체계를 찾으면 해당 속성을 사용하고 새 속성을 발명하지 마세요. 새 사용자 지정 속성을 정의하는 경우 해당 속성을 사용하려는 다른 개발자와 계약을 맺고 해당 계약의 결과를 게시하여 해당 속성의 사용자 커뮤니티에 가입할 수 있도록 합니다.

생산자는 Windows Explorer 기능을 활용할 수 있습니다. 예를 들어 새 이미지 형식을 작성하고 속성 처리기를 구현하는 경우 Windows Explorer 새 파일 형식을 사용할 수 있습니다. 그런 다음 사용자는 자신의 사진에 태그를 지정하고 Windows 속성 시스템의 모든 속성에 따라 사진 컬렉션을 피벗할 수 있습니다. 실제로 Shell이 속성과 함께 수행하는 모든 작업은 타사 개발자가 자체 애플리케이션에서 수행할 수 있습니다. 여기에는 그룹화, 정렬, 쿼리 및 전체 속성 표시가 포함됩니다. Windows Explorer 제공하는 사용자 환경은 주로 공개적으로 사용 가능한 API를 사용하는 타사에서 구현할 수 있습니다. 이러한 API를 사용하여 Windows Explorer 교체하거나 확장할 수 있습니다.

셸 데이터 모델을 사용하는 애플리케이션의 관점에서 볼 때 Windows 속성 시스템 사용과 관련된 다양한 시나리오가 있습니다. 미디어 관리 애플리케이션이 대표적인 예입니다. 핵심 속성 시스템 시나리오에는 사진의 키워드(keyword) 속성을 읽거나 datetaken 속성을 설정하는 등의 시나리오가 포함됩니다. Windows 속성 시스템에서 사용하도록 설정하지만 다른 여러 구성 요소가 작동해야 하는 엔드 투 엔드 통합 시나리오의 예로는 모든 그림을 표시하거나 키워드(keyword) 포함된 문서를 찾는 것이 포함됩니다.

속성은 Windows Search 및 인덱싱과 상호 작용할 때 생산자와 소비자 모두에게 서비스를 제공합니다. Windows Search에는 WSS(Windows Search Service) 구현에 사용되는 속성 값의 캐시가 있습니다. 이러한 속성 값은 Windows Search OLE DB 공급자를 사용하거나 검색 결과 및 쿼리 기반 보기의 항목을 나타내는 ISearchFolderItemFactory를 통해 프로그래밍 방식으로 쿼리할 수 있습니다. 그런 다음, Windows Search는 Word 문서와 같은 항목이 인덱싱될 때 필터 처리기 또는 속성 처리기에서 내보낸 속성을 수집하고 저장합니다. 이 저장소는 인덱스를 다시 작성할 때 삭제되고 다시 작성됩니다.

참고

스키마를 다시 등록할 때 이전에 정의된 속성의 특성에 대한 변경 내용은 인덱서에서 적용되지 않을 수 있습니다. 솔루션은 인덱스 다시 작성 또는 이전 속성을 업데이트하는 대신 변경 내용을 반영하는 새 속성을 도입하는 것입니다(권장하지 않음). 자세한 내용은 이 항목의 뒷부 분에 있는 구현자에 대한 참고 를 참조하세요.

 

예를 들어 미디어 애플리케이션을 만드는 개발자는 애플리케이션 사용자에게 특정 아티스트가 사용 가능한 모든 음악을 표시하려고 합니다. 애플리케이션은 사용자에게 사용 가능한 아티스트 목록을 제공한 다음 사용자가 선택한 아티스트가 사용 가능한 모든 음악 목록을 생성합니다. 또는 최종 사용자가 ?artist:Beethoven?에 대한 쿼리를 수행하고 검색 과정에서 사용 가능한 속성의 전체 목록에 노출될 수 있습니다. 이 예제에는 셸 네임스페이스, 속성 처리기 및/또는 다음 중 하나를 통해 인덱스를 쿼리하는 작업이 포함됩니다.

  • 셸 데이터 원본입니다.
  • OLE DB 공급자입니다.
  • Windows Explorer 검색 파일로 이동하거나 프로그래밍 방식으로 IShellFolder에 바인딩하여 쿼리를 시작하는 데 사용되는 저장된 검색 파일(.search-ms)입니다.

참고

속성은 System.Kind 이 미디어 애플리케이션 시나리오에 참여하지 않지만 특정 scope 모든 .search-ms 파일을 반환하는 쿼리를 빌드하는 데 사용할 수 있습니다.

 

검색 API에 액세스하고 Windows Search 애플리케이션을 만드는 기본 방법은 셸 데이터 원본을 사용하는 것입니다. ISearchFolderItemFactory 는 셸 네임스페이스의 다른 데이터 원본에 대해 쿼리를 실행하고 결과를 열거할 수 있는 일종의 "가상" 데이터 원본인 Search 폴더 데이터 원본의 인스턴스를 만들 수 있는 구성 요소입니다. 인덱서를 사용하거나 지정된 범위의 항목을 수동으로 열거하고 검사하여 수행할 수 있습니다.

타사 개발자는 프로그래밍 방식 쿼리를 통해 인덱스의 데이터를 사용하는 애플리케이션을 만들 수 있으며, Windows Search에서 인덱싱할 사용자 지정 파일 및 항목 유형에 대한 인덱스의 데이터를 확장할 수 있습니다. Windows Explorer 쿼리 결과를 표시하려면 프로토콜 처리기를 만들어 인덱스 확장을 위해 셸 데이터 원본을 구현해야 합니다. 그러나 모든 쿼리가 프로그래밍 방식으로(예: OLE DB를 통해) 셸이 아닌 애플리케이션의 코드에서 해석되는 경우 셸 네임스페이스는 여전히 선호되지만 필수는 아닙니다. Windows에서 데이터베이스 또는 사용자 지정 파일 형식의 항목과 같은 파일 콘텐츠에 대한 정보를 가져오려면 프로토콜 처리기가 필요합니다. Windows Search는 파일의 이름과 속성을 인덱싱할 수 있지만 Windows에는 파일 내용에 대한 정보가 없습니다. 따라서 이러한 항목은 Windows 셸에서 인덱싱하거나 노출할 수 없습니다. 사용자 지정 프로토콜 처리기를 구현하여 이러한 항목을 노출할 수 있습니다. 달성하려는 개발자 시나리오에서 식별된 처리기 목록은 개발 플랫폼으로 Windows Search의 "처리기 개요"를 참조하세요.

참고

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

 

구현자에 대한 참고 사항

속성 시스템의 스키마를 사용할 때 인덱서에 발생할 수 있는 잠재적인 어려움으로 인해 스키마의 첫 번째 릴리스에 대해 특성을 신중하고 전략적으로 정의하는 것이 중요합니다. 스키마가 등록된 후에는 특성(형식, 열 너비, 인덱싱 가능 여부)에 대한 변경 내용이 데이터베이스에 반영되지 않습니다. 시스템에 스키마를 한 번 등록한 후 이러한 변경 내용을 인식하는 유일한 방법은 인덱스를 다시 빌드한 다음 새 스키마를 등록하거나 스키마를 등록한 다음 각 후속 릴리스에 대해 새 속성을 만드는 것입니다. 예를 들어 PKEY_GroupName_PropertyNameV2, PKEY_GroupName_PropertyNameV3등입니다. 여러 개의 불필요한 열이 시스템 성능에 영향을 미칠 수 있으므로 이러한 방식으로 새 속성을 만들지 않는 것이 좋습니다.

Windows 속성 시스템 설명서

이 설명서의 나머지 부분에는 다음 섹션이 포함되어 있습니다.

추가 리소스

Windows 속성 시스템 개발자 가이드

속성 시스템 참조

속성 시스템 코드 샘플