了解属性处理程序
属性由称为属性标识符的 ID 表示 (PID) 。 每个属性都必须具有一个全局唯一标识符 (GUID) 。 此标识符由 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 搜索系统以及其他应用程序使用属性处理程序来读取和修改此元数据。 如果你是拥有特定文件类型的开发人员,则应注册属性处理程序,使属性系统能够访问文件中的元数据。 在某些情况下,你可能能够使用可读取和理解文件格式及其属性的现有属性处理程序;在其他情况下,可能需要为文件类型开发新的属性处理程序。
编写属性处理程序的第一步是考虑文件类型支持的属性。 属性值存储在文件流中,主要是为了启用可传输性。 当属性值存储在文件本身中时(就像它们在此系统中一样),用户可以将文件复制到另一台计算机、U 盘或其他文件系统,或者将文件作为电子邮件附件发送,属性会随文件一起移动,永远不会不同步或丢失。 因此,如果文件格式支持存储额外信息,则最好将属性存储在文件本身中。
下一步是确定文件应提供的属性。 你可能最初认为有限的一组属性就足够了。 音频文件只能支持与音频相关的属性,并结束于此。 然而,该音频文件可能是由律师事务所存档的法庭会议录音。 在这种情况下,律师事务所当然希望将其他非音频属性与此文件相关联,例如案例编号。 音频文件格式的提供程序无法确定将使用其格式的所有方案。 因此,他们应考虑启用属性系统支持的任何任意属性的一揽子存储。
旧技术
Microsoft Windows NT 文件系统 (NTFS) 辅助流技术的开发旨在通过文件系统层上设置的备用流来支持文件中额外信息的持久性。 人们可能想知道,为什么这些辅助流不用作存储属性main方法,尤其是在支持开放元数据的情况下。 主要原因是此额外信息的可传输性。 遗憾的是,这些备用流在许多方案中被删除,包括客户端缓存支持 (CSC) 、将文件作为附件发送以及将文件复制到非 NTFS 存储。
辅助流不提供可靠的解决方案,其中属性可以保证随文件一起传输,因此,Windows Vista 属性系统不提供利用辅助 NTFS 流进行属性存储的内置机制。 此外,强烈建议不鼓励 ISV 生成使用辅助流存储属性的属性处理程序。 当然,在某些情况下,NTFS 辅助流是合适的,特别是当应用程序可以保证他们正在处理的文件始终存储在 NTFS 卷中,并且不会由于最终用户交互而传输。
相关主题
反馈
https://aka.ms/ContentUserFeedback。
即将发布:在整个 2024 年,我们将逐步淘汰作为内容反馈机制的“GitHub 问题”,并将其取代为新的反馈系统。 有关详细信息,请参阅:提交和查看相关反馈