[元数据文件命名法]规范性文件命名系统，不再为文件命名发愁

背景

我曾听过一句有哲理的话，具体找不到了，它的大意是：

没有良好命名的文件，基本就是没有意义的文件。

见字如面，一个良好的文件名，除了方便检索外，还让人看着舒服，赏心又悦目。

当用不到的时候，文件命名是小事，但当你因为不恰当的命名导致找不到文件而焦头烂额时，它就不再是小事。

在实际生活中，每次给需要存档的文件起名、整理时，我都要对所起的文件名思考：

对人类（我）的可读性高吗？
概括性强吗？
方便我以后快速检索到吗？
对软件兼容吗？
……

每起一次名，就要让我头疼一下。因此我急需一个规范，让我在起名时有个指导，不再是瞎苍蝇撞墙地想到啥写啥。

目前我能在网上能找到的命名法，都是类似这样的：

命名结构：项目命名词（或编号）+文件命名词+文件作者+日期+版本号.ext
例如：2016年公司部门工作总结_营销部_大鹏_20170101_V1.0.doc
文件名称由五部分组成：

第一部分为阐述文件主题，观其名知大意；

第二部分为文件所属类别，如在单位工作的写工作部分、学生人群可写班级等；

第三部分为文件创建者；

第四部分为当前文件的日期；

第五部分为文件阶段标识，用于版本管理。

但我觉得不好用！或者说，不够用！现实的文件情况可比这复杂多了！

在前 2021 年 10 月 23 日，我提出了规范性图片文件名整理系统的构思，用以解决图片整理、检索的问题，我认为这个方法很好，非常周到，只是它局限在了管理图片、视频方面，如果扩展一下，可以应用到大部分文件、文件夹的命名管理当中，因此，经过思索，我对其进行扩展，得到一套详细、好用、好理解的命名法。

一个方法，为了方便交流，最好还是取个名字，因为网上还没人起过这样的名字，我就先大言不惭地起这样一个名：元数据文件命名法

它是一个为文件、文件夹命名的规则，覆盖了以下适用范围：

照片、视频、设计素材
工作项目
书籍、文档
软件安装包
录像素材
科研数据文件
……（几乎一切需要存档的文件）

不适用的地方：编程源文件的命名

命名原则

元数据文件命名法 提倡，在文件、文件的命名中，可选地、有序地包含以下以下 7 个 元数据块：

时间：年、月、日、时分秒，根据实际情况决定精度
前缀：可以是数字序号、大的分类；不常用，主要目的是为文件进行手动排序
标题：文件的主标题，描述文件内容的本质
版本：版本号，对于需要迭代的项目文件很重要
标签：标题之外的补充信息，例如地点、文件性质
人物：可以是人名、组织名、宠物名、作者、来源答主
备注：评论性文字，杂谈、心得

每个元数据块之间，应当使用规范的、高可读性的 块间分隔符

在命名时，要注意文件系统对文件名的限制：

NTFS 上最多 255 个字符
有些系统上最多 255 字节（每个中文2字节）
不能使用的字符：< > / | : " * ?

宽松命名和严格命名

对于普通文档管理，文件名受到的约束很小，中文、空格、! @ # $ % 等特殊符号可以使用。

但实际现实中，还有一些特殊场景，如：

科学计算
实验数据处理
剪辑素材

在这些方面，对文件命名的限制会更高，因为有些古老的工具，对于文件名中的特殊字符、中文字符、空格，不能正确地处理，会造成错误。

为避免不兼容，最安全保险的文件命名又受以下限制：

不能有中文
主体为数字、英文字母（ASCii 符号）
可输入英文符号，但是避免：: ~ ! @ # $ % ^ & * ( ) ` ; < > ? , [ ] { } ‘ “
可使用的安全符号：- _ .

因此，元数据文件命名法 分为宽松和严格两小类。它们遵循相同的原则，只是 严格版 在字符使用上更加安全，更适合科学研究等对文件名字符要求高的领域。

元数据文件命名法【宽松】

命名示例

直接列举规则细节，会不方便理解，所以先以几个规范的示例帮助学习和理解：

(20181005-170201)婚纱照#苏州#太湖#夕阳@伊女士@胡先生@摄影李.jpg

(20190207-105303)合影#过年#走亲戚#老家@唐语&二姨家来走亲戚，和表姐合影.jpg
(20200102-130843)酥肉汤#美食#老家@李明@刘大龙&我和李明在他家，第1次学了炸酥肉，煮了汤&他表弟在旁边捣蛋.mp4

(2020-03)销售数据#北京#广告业务@林佳一&她是本月的销冠.xlsx
(2020-03)销售数据#北京#服务器@黄元&这个月不太景气，有些下滑.xlsx

(2021-08-23)我还年轻，我还年轻#御音萌妹#翻唱@咩咩爱睡懒觉.mp4
(2021-05-05)【囍】嫁鸡随鸡，嫁狗随狗#舞蹈@-小D-biu.mp4

我还年轻，我还年轻 - 咩咩爱睡懒觉#翻唱@老王乐队.mp3

(2020-03)面试简历#后端@高净&小伙子技术相当可以，老板要定了.doc
(2020-03)面试简历#运维@林嵘宏&可能申请的岗位不大合适.doc

(2012)《 中国图书馆分类法简本》#分类@国家图书馆.pdf
(2014)《Talk Like TED》#演讲@Carmine-Gallo&z-lib.org.epub
(2014)《英语框架》#英语学习@吴全欢&我的英语语法开导之作，非常感谢作者.pdf
(2016)《童哥说单词：牛津词源全解（第八版）》#英语学习#词根@童理民.pdf
(2016)《搞定》#GTD@戴维·艾伦&共三册.pdf
(2020)《费曼学习方法》#学习@Farnam Street Media.pdf

(2012)Adobe Photoshop CS6(v13.0.1.1)#便携版&从www.xxxx.com下载的.7z

(2015-09)裁员计划#已批准@人事部

基地扩建项目#todo@老张=规模有些大，得多开几次会
健身视频#routine#健康#运动
(2014)同学照片#人物@初中同学

(2021-05-13)004-玩具车(v1.1.1)#done#rhino@客户32&这个要求是真简单，就喜欢这样的客户
(2021-05-16)002-海贼王(v3.4.5)#todo#3ds Max@客户38&反稿了好多次，要求贼高，但客户又不差钱

001-颜文字皮肤(v1.0)#键盘
001-颜文字皮肤(v1.6)#键盘&啊！！！心态崩了，重构重构！
001-颜文字皮肤(v2.0)#键盘
001-颜文字皮肤(v2.1)#键盘#done&Nice，这是最终版了

宽松命名细则

提倡将以下项目可选地、按顺序地写入文件名

1. 时间（可选）

时间不是一个必要项，但对于时间敏感性文件（如照片、视频、项目），最好还是添加上合适的时间戳。

样式有：

(YYYYMMDD-HHMMSS)
(YYYY-MM-DD)
(YYYY-MM)
(YYYY)

例如：

(20210512-091500)
(2021-05-12)
(2021-05)
(2021)

如此设计的原因：

时间开头，方便按时间排序
时间放在括号中间，与后面文字部分形成明显界限，方便批处理获取时间信息
时间放在括号中美观呐
年月日 之间使用 - 分隔，高可读性，用户看着不累
加上 时分秒 后，只在日期和时间之间用 - 分隔：
- 整个时间戳有 14 位数字，便于用户区分日期和时间部分
- 不能太长了，不然在资源管理器中显示效果不好

2. 前缀（可选）

可以是数字序号、大的分类，使用 - 分隔，例如：

01-
005-
022-
122-
属性1-
属性1-属性2-
属性1-属性2-属性3-

如此设计的原因：

用户有时会有 手动排序 的需求，通过在标题前加上数字序号、或者对文件特别重要的属性，可以达到手工排序归类的效果
为了高可读性，前缀和标题间，应当有一个合法、但不常用的符号用作分隔，在中文输入法状态下，- 也是一个方便输入的字符

3. 标题（可选）

文字标题，用以表示该文件的最本质属性，不需要太多废话，多余的补充信息放到标签、评论中就可以

4. 版本（可选）

用以解决一个项目时常有多个版本的情况，样式是：

(v大版本号[.中版本号[.小版本号]])

例如：

(v1.1.1)
(v3.4.5)
(v1.6)
(v1)
(v6)

如此设计的原因：

版本号外加上括号，显眼，好区分，耐看，与文件名中其它部分形成明显分隔
版本号中的 v，让人一眼就知道这几个数字表示的是版本
版本号一定要排在标题后，这样相同项目的不同版本，才能排列在一起
版本号一定要排在标签、评论前，这样才能让同项目的不同版本有序排列

5. 标签（可选）

可以对文件性质、分类、地点进行补充，样式是：

#标签文字

例如：

#todo
#done
#后端
#已批准
#搁置
#学习方法
#北京
#New York

标签可以有多个，标签文字中可以包含空格

如此设计的原因是：在微博、空间、Twitter 等社交媒体上，# 已经被广泛地用作话题标签，在 Obsidian 等笔记软件中，也被用作标签的标识符，用户可以一眼就下意识地得知：这是一个标签。

6. 人物（可选）

即名字，但不止于人名，可以是组织名、公司名、作者名、设计师名、部门名、博主名、答主名、摄影师名、客户名……，样式是：

@名字

例如：

@人事部
@伊女士
@摄影李
@阿豪的阁楼
@John Legend

名字支持空格

如此设计的原因：

在社交网站上 @用户名 使用非常广泛，用户一看，就知道后面跟着的是个名字
文件是服务于人的，是人创造的，大部分文件总会对应到生活中的一个活的对象，它可以是人，也可以是组织。总之，在文件中加上名字，可以方便用户根据人名、组织名找快速找到相关文件。
人名在文件名中的权重不用太高，主要是检索时用，应当排在后面些

7. 评论、备注（可选）

它的样式是：

&评论文字&第二行评论文字

其中，规定以 & 作为评论起始的分隔符，同时之后的 & 充当换行符

评论要尽可能简要，避免让文件名超过 255 个字符的限制

如此设计的原因：

用户有对文件进行补充性说明的需求
补充性文字的权重最低，应排在最后面
文件名长度有限，从这方面讲，也应当将可调整性最强的评论部分放到最后面
使用 & 将评论与前面的部分分隔开，方便用户、批处理程序区分
评论只有一坨不符合直觉，需要一个合法、不常用的词充当换行符

上述所有 7 个内容块的标识符号，使用的是：( ) - @ # &，除了 ( ) 外，其余所有的符号都可以在中文输入法下方便地输入

检索

经过这样的命名，基本上，没有什么文件是你找不到的了，例如我想要找所有 -小D-biu 在 2020 年的视频，只需要在 Everything 或者 Listary 中输入：2020 @-小D-biu .mp4，Nice！

另外，上述的规范还特别方便批处理，这也是在设计这套命名时，非常注重的一个点

元数据文件命名法【严格】

与宽松版相比，原则不变，文件命名中应当可选地、按顺序地包含以下 7 个 元数据块：

时间
前缀
标题
版本
标签
人物
备注

标题规范

科研标题

对于科研文件，提倡标题部分使用缩写，且应包含：

项目、实验名称
位置、空间坐标、样本序号
研究条件、样品处理方式
……

对不同的项目，标题的缩写应制定具体、合理的规范，建议在项目总目录新建一个 txt 或 md 文件，解释所使用过的缩写。

录像素材标题

对于要用于剪辑的录像素材，提倡标题部分使用缩写，且应包含：

项目、主题名称
场景号
摄影机编号
素材尺寸、帧率
编码类型
……

对不同的项目，标题的缩写应制定具体、合理的规范，建议在项目总目录新建一个 txt 或 md 文件，解释所使用过的缩写。

严格命名细则

在基于宽松命名细则的基础上，附加以下细则：

仅使用数字、英文字符

符号仅使用 - _ .

不能使用空格

每个 元数据块 之间，应当使用 块间分隔符，推荐 __ 或 _ ，例如：

YYYYMMDD__Title__Author.ext
YYYYMMDD_Title_Author.ext
Title__Author.ext

每个 元数据块 内部，应当使用 块内分隔符，且应与 块间间隔符 不同，推荐 . 或 -，例如：

YYYYMMDD__Attr1.Attr2.Attr3__Tag1.Tag2__Author1.Author2.ext
YYYYMMDD__Attr1-Attr2-Attr3__Tag1-Tag2__Author1-Author2.ext

年月日、时分秒之间，应当使用 块内分隔符，例如：

YYYYMMDD-HHMMSS__Title__Author.ext

连续使用多个单词时，推荐使用 驼峰法 或 块内分隔符（一定不要用空格），如：

LongAndNecessaryTitle__Author.ext
Long-and-necessary-title__Author.ext
Long.and.necessary.title__Author.ext

科研文件命名示例

参考模板：

YYYYMMDD_Attr1.Attr2.Attr3.Attr4_Tag1.Tag2_Author1_Comment.ext
YYYYMMDD-HHMMSS__Attr1.Attr2.Attr3.Attr4__Tag1.Tag2__Author1.Autor2__Comment.ext

YYYYMMDD_Place.SampleNum.Procedure.Number_Tag1.Tag2_Author.ext
YYYYMMDD-HHMMSS__Place.SampleNum.Procedure.Number__Tag1.Tag2__Author.ext

示例1：

20140623_FR3S.129C.2653_NewProgress_BD.JPG

    日期：20140623，2014年06月23日
    标题：FR3S.129C.2653.W
    标题缩写释义：
        FR3S：研究地点 FR3；Shallow，潜水域 （S=Shallow, M=Middle, D=Deep）
        129C：区域129，覆盖处理（C=Covered, U=Uncovered）
        2653：照片序号
    标签：NewProgress 有重要新进展，有别于其它普通数据
    研究人员：BD（Bruce D）

示例2：

20210321__ITO.5HT-Lab1-U1__HJ

    日期：20210321，2021年03月21日
    标题：ITO.5HT-Lab1
    标题缩写释义：
        ITO.5HT：实验项目为修饰 ITO 电极，用于测量 5HT
        Lab1：测试地点，实验室1
        U1：Unit 1，即第一台设备
    研究人员：HJ

202127__Samp11-OxPPy-7.0PBS0.1-KCl0.1-CV8-M0.4-P1.8-S0.1__Good.elc

    测试时间：202127，20:21:27
    标题：Samp11-OxPPy-7.0PBS0.1-KCl0.1-CV8-M0.4-P1.8-S0.1
    标题缩写释义：
        Samp11：Sample 11，即样品序号11
        OxPPY：所作的操作为氧化 PPY
        7.0PBS0.1：溶液环境为 PH7.0 的 PBS 缓冲液，浓度为 0.1M
        KCl0.1：溶液中还有 0.1M 的 KCl
        CV8：仪器参数为循环伏安法（cyclic voltammetry），循环8次
        M0.4：扫描下限 -0.4V （M 表示 Minus）
        P1.8：扫描上限 1.8V （P 表示 Positive）
        S0.1：速度 0.1V/s （S 表示 Speed）
    标签：Good

# 在本例中，由于标题内参数中有用到小数点的地方，所以规范 - 作为块内分隔符

录像素材命名示例

参考模板：

YYYYMMDD_Theme.Scene.Camera.ResFps.Codec.FileNum_Tags_Authors.ext
YYYYMMDD-HHMMSS__Theme.Scene.Camera.ResFps.Codec.FileNum__Tags__Authors__Comment.ext

标题缩写释义：
  Theme：主题、项目
  Scene：场景
  Camera：录像设备
  ResFps：分辨率、帧率
  Codec：编码格式
  FileNum：文件序号

示例：

20211025-102501_Proj1.S1.Rn4D.4k60.sLog3_BTS_Li.mov
20211025-102501__Proj1.S1.Rn4D.4k60.sLog3__BTS__Li.mov

    时间：2021年10月25日 10点25分01秒
    标题：Proj1.S1.Rn4D.4k60.sLog3
    标题缩写释义：
        Prj1：项目1（Project 1）
        S1：场景1（Scene 1）
        Rn4D：设备为如影4D
        4k60：分辨率4K，帧率60
        sLog3：Log类型
    标签：BTS，Behind The Scene,幕后
    摄影师：Li

结语

要辩证

构思这样一个宽适用领域、高度弹性的命名规则是真费脑筋。

这样的命名法，没有成为强制使用的初衷，只是提供一个可供参考的模板，在实际命名中，要实际情况实际分析，灵活变更。渴望一条规则面对所有情况，是不大可能的。

假设你在投简历的时候，就不适用于这样的命名法，而应当按公司要求的格式来，例如：

应聘XX岗位-姓名-学校-手机号
姓名+学历+学校+实习时间+应聘岗位+意向城市+手机号

所以，要辩证地看待该命名法，具体情况具体分析！

如何用

有了这样一套方案，不是说就一定要立即用到所有已存档的文件上，它的意义是，当你再需要给一系列文件命名时，会有一个科学合理的依据。

长文件名通常意味着更多的工作量，目前的文件浏览器，在重命名的操作上，并不是很好用，需要有一些辅助性程序，帮助规范命名，可以是：

各种语言写的 GUI 程序
Quicker 动作（已实现：规范文件命名）
批处理脚本

东西不复杂，不用太多的技术，但是打磨到好用的程度，还是需要时间的。

Quicker 动作使用示例：

参考

本文转自少年派 @淳帅二代

背景

命名原则

宽松命名和严格命名

元数据文件命名法【宽松】

命名示例

宽松命名细则

1. 时间（可选）

2. 前缀（可选）

3. 标题（可选）

4. 版本（可选）

5. 标签（可选）

6. 人物（可选）

7. 评论、备注（可选）

检索

元数据文件命名法【严格】

标题规范

科研标题

录像素材标题

严格命名细则

科研文件命名示例

录像素材命名示例

结语

要辩证

如何用

参考

发表回复 取消回复

发表回复取消回复