了解属性处理程序
属性由称为属性标识符（PID）的 ID 表示。 每个属性必须具有全局唯一标识符（GUID）。 此标识符由 GUID 组成，表示名为属性集的属性集合以及字符串或 32 位整数，用于标识集中的属性。 如果使用 ID 的整数形式，则值0x00000000、0xFFFFFFFF和0xFFFFFFFE被视为无效。 供应商可以通过将属性放置在由其自己的 GUID 定义的属性集中来保证其属性唯一定义。
重要
对于架构的第一个版本，必须仔细和战略性地定义属性。 对自定义属性（如列宽或属性类型）所做的任何更改都不会在注册架构后反映在数据库中。 在系统上注册架构后识别这些更改的唯一方法是重新生成索引，然后注册新架构，或注册架构，然后为每个后续版本创建一个新属性（由规范名称和 PKEY 组成）：例如 PKEY_GroupName_PropertyNameV2， PKEY_GroupName_PropertyNameV3等等。 不建议以这种方式创建新属性，因为多个多余的列可能会影响系统性能。
本主题的组织方式如下：
元数据
在 Windows Vista 及更高版本中，基于元数据的新属性系统对于组织文件、电子邮件和联系人等项目至关重要。 在此新属性系统中，可以根据项的元数据进行搜索，用户可以读取或写入该元数据。 此系统中的元数据由作为名称/值对实现的 可扩展属性 集表示。
在 Windows Vista 及更高版本中，一组广泛的属性涵盖了照片、音乐、文档、消息、联系人和文件等项目的详细信息。 如果没有现有属性满足其需求，独立软件供应商（ISV）可以将自己的属性引入平台。
打开元数据
Windows Vista 及更高版本中的属性系统是一个开放的元数据系统。 文件格式存储分配给它的任何属性，并在查询时公开该值，而不考虑相关性或含义。 这使第三方开发人员能够将额外的属性附加到文件，而无需更改与之关联的属性处理程序。 开放元数据是一个强大的概念。 有关如何支持基于 XML 的文件格式的开放元数据的详细信息，请参阅初始化属性处理程序中的 “支持打开元数据”。
注意
属性处理程序始终与特定文件类型相关联;因此，如果文件格式包含需要自定义属性处理程序的属性，则应始终为每个文件格式注册唯一的文件扩展名。
关于属性处理程序
在 Windows Vista 及更高版本中，Windows 具有一个可扩展的属性系统，用于在访问的文件和数据项中存储和检索元数据。 Windows 资源管理器和 Windows 搜索系统以及其他应用程序使用属性处理程序读取和修改此元数据。 如果你是拥有特定文件类型的开发人员，则应注册一个属性处理程序，以授予属性系统对文件中元数据的访问权限。 在某些情况下，你可能能够使用现有的属性处理程序来读取和了解文件格式及其属性;在其他情况下，可能需要为文件类型开发新的属性处理程序。
编写属性处理程序的第一步是考虑文件类型支持的属性。 属性值存储在文件流中，主要用于实现可传输性。 当属性值存储在文件本身中时，与此系统中一样，用户可以将文件复制到另一台计算机、USB 闪存驱动器或其他文件系统，或者将文件作为电子邮件附件发送，属性会随文件一起传输，并且永远不会同步或丢失。 因此，如果文件格式支持存储额外信息，最好将属性存储在文件本身中。
下一步是确定文件应提供哪些属性。 你可能最初认为一组有限的属性足够。 音频文件只能支持与音频相关的属性并结束。 但是，该音频文件可能是律师事务所存档的一个法庭的录音。 在这种情况下，律师事务所当然希望将其他非音频属性与此文件相关联，例如案例编号。 音频文件格式的提供程序无法确定将使用其格式的所有方案。 因此，它们应考虑启用属性系统支持的任何任意属性的全面存储。
旧技术
Microsoft Windows NT 文件系统 （NTFS） 辅助流技术已开发，通过文件系统层的备用流集来支持文件的额外信息的持久性。 人们可能想知道为什么这些辅助流不用作存储属性的主要方法，尤其是在开放元数据支持的情况下。 主要原因是此额外信息的可传输性。 遗憾的是，在很多情况下，这些备用流会被删除，包括客户端缓存支持（CSC）、将文件作为附件发送，以及将文件复制到非 NTFS 存储。
辅助流不提供可靠的解决方案，其中保证属性随文件一起传输，因此，Windows Vista 属性系统不提供利用辅助 NTFS 流进行属性存储的内置机制。 也强烈建议不要生成使用辅助流存储属性的属性处理程序。 当然，在某些情况下，NTFS 辅助流是适当的，特别是当应用程序可以保证他们处理的文件始终存储在 NTFS 卷中，并且不会由于最终用户交互而传输。
相关主题