很多文件都有自己的独特元数据扩展, 典型的就是 JPG 图片的 EXIF 信息. 在管理大量文件的时候注意到元数据的重要性, 写给计算机看的元数据是文件头, 是数据包头. 写给人类看的, 规范的文件元数据很少, 应用广泛的除了 EXIF, 还有用在音频文件的 IDv2, IDv3 标签, 视频封装容器格式中用来保存封面的元信息, 电子书的书籍信息, 电子文档里面 Microsoft 给 Excel, Word, PPT 都添加了各种各样的元信息, 一些归档软件还能给 ZIP 添加注释.
对于这类基于文件格式的元信息还是主要看操作这类文件格式的软件的适配, 而更加深入一层的是文件系统的元信息, 比如 NTFS 的备用数据流(Alternate data stream, ADS):
- **NTFS #Alternate data stream (ADS) - Wikipedia**: https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(ADS)
- [MS-FSCC: NTFS Streams | Microsoft Learn](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c54dec26-1551-4d3a-a0ea-4fa40f848eb3)
应用程序可以直接在文件系统上给文件添加额外的元信息, 目前使用这种原理的软件给文件添加额外信息的软件只发现了一个: Directory Opus. 当然也能自己用 PowerShell 给文件添加和读取备用数据流:
)
- [Streams - Sysinternals | Microsoft Learn](https://learn.microsoft.com/en-us/sysinternals/downloads/streams)
但是说了这么多, 上面提到的元信息都是只针对文件的, 对文件夹的元信息, 就算是 NTFS 的备用数据流也没有办法. 虽然直接用文件夹名称存储元信息是一种直观的办法, 但是限制就会变得很多, 比如特殊字符, 来自操作系统的路径长度限制, 来自归档文件格式算法的路径长度限制([tar 限制 255 个字符](https://www.gnu.org/software/tar/manual/html_section/Formats.html)), 来自文件系统的路径长度限制(NTFS 限制 65535 个字符), 如果不选择更好的办法, 用文件夹名称的写元信息就会陷入一个来自方方面面的 "木桶效应". 没有任何文件系统支持给文件夹添加元数据, 或许就只能另辟蹊径了, 比如给文件目录建立索引, 然后在索引里面写元信息, 类似于给文件目录建数据库, 当然最后还要用其他的软件读取数据库和目录建立操作关系, 相当于要重写一个文件管理器软件. 更加简单的索引比如 [Descript.ion](https://zh.wikipedia.org/zh-hans/Descript.ion) 目前还在使用, 被 ACDSee, XnView, Total Commander 还有 7-Zip, 以及上面提到过的 Directory Opus 采用. 这些软件要么本身就是一个文件管理器, 要么就是附带操作文件目录的功能的软件.
文件夹也需要元信息, 但解决办法还没有找到, 或许以后也只能求助于第三方文件管理器了.
