# 规范性文件、文件夹命名系统，用以解决文件整理、存档、检索的问题【元数据文件命名法】

**URL:** <https://meta.appinn.net/t/topic/27003>\
**Category:** 讨论分享\
**Tags:** 文件管理\
**Created:** [2021 年10 月 24 日 09:06 UTC](https://meta.appinn.net/t/topic/27003 "2021-10-24T09:06:47Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

作者： ![HaujetZhao](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/h/67e7ee/32.png) [@HaujetZhao](https://meta.appinn.net/u/HaujetZhao)\
发布日期： [2021 年10 月 24 日 09:06 UTC](https://meta.appinn.net/t/topic/27003/1 "2021-10-24T09:06:47Z")

</div>

## 背景

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

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

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

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

在实际生活中，给需要存档、方便以后寻找的文件起名、整理，每次取名，我都要对名字思考：

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

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

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

> 命名结构： **项目命名词（或编号）+文件命名词+文件作者+日期+版本号.ext**  
> 例如：2016年公司部门工作总结\_营销部\_大鹏\_20170101\_V1.0.doc  
> 文件名称由五部分组成：
> 
> - 第一部分为阐述文件主题，观其名知大意；
> - 第二部分为文件所属类别，如在单位工作的写工作部分、学生人群可写班级等；
> - 第三部分为文件创建者；
> - 第四部分为当前文件的日期；
> - 第五部分为文件阶段标识，用于版本管理。

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

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

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

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

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

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

## 命名原则

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

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

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

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

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

## 宽松命名和严格命名

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

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

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

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

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

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

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

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

### 命名示例

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

```plaintext
(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. 时间（可选）

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

样式有：

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

```

例如：

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

```

如此设计的原因：

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

#### 2. 前缀（可选）

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

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

```

如此设计的原因：

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

#### 3. 标题（可选）

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

#### 4. 版本（可选）

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

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

```

例如：

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

```

如此设计的原因：

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

#### 5. 标签（可选）

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

```plaintext
#标签文字

```

例如：

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

```

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

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

#### 6. 人物（可选）

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

```plaintext
@名字

```

例如：

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

```

名字支持空格

如此设计的原因：

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

#### 7. 评论、备注（可选）

它的样式是：

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

```

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

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

如此设计的原因：

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

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

### 检索

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

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

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

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

1. 时间
2. 前缀
3. 标题
4. 版本
5. 标签
6. 人物
7. 备注

### 标题规范

#### 科研标题

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

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

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

#### 录像素材标题

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

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

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

### 严格命名细则

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

1. 仅使用数字、英文字符

2. 符号仅使用 `- _ .`

3. 不能使用空格

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

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

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

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

### 科研文件命名示例

参考模板：

```plaintext
YYYYMMDD_Attr1.Attr2.Attr3.Attr4_Tag1.Tag2_Author1_Comment.ext
YYYYMMDD-HHMMSS __Attr1.Attr2.Attr3.Attr4__ Tag1.Tag2 __Author1.Autor2__ Comment.ext

```

```plaintext
YYYYMMDD_Place.SampleNum.Procedure.Number_Tag1.Tag2_Author.ext
YYYYMMDD-HHMMSS __Place.SampleNum.Procedure.Number__ Tag1.Tag2__Author.ext

```

示例1：

```plaintext
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：

```auto
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
    标题：U1-Samp11-OxPPy-PB7.0-CV8
    标题缩写释义：
        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

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

```

### 录像素材命名示例

参考模板：

```plaintext
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：文件序号

```

示例：

```plaintext
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 动作（已实现：[宽松元数据命名法动作](https://getquicker.net/Sharedaction?code=fac14427-c0f5-4567-c945-08d99706f10d)）
- 批处理脚本

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

[Quicker 动作](https://getquicker.net/Sharedaction?code=fac14427-c0f5-4567-c945-08d99706f10d) 使用示例：

 ![image](https://meta-edge.appinn.com/uploads/default/original/3X/b/d/bddea40d65d5a0d20619febd97f6b9b09b62b6c9.png)

## 参考

- [Best practices for file naming | Stanford Libraries](https://library.stanford.edu/research/data-management-services/data-best-practices/best-practices-file-naming)
- [Case study: File naming done well | Stanford Libraries](https://library.stanford.edu/research/data-management-services/case-studies/case-study-file-naming-done-well)
- [文件的命名与组织](https://zhuanlan.zhihu.com/p/154377940)
- [Life Hack + 文件命名：意义、要素与工具](https://zhuanlan.zhihu.com/p/28925196)
- [Comparison of file systems - Wikipedia](https://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits)

---

<div class="post-metadata">

作者： ![dangerace](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/dangerace/32/16676_2.png) [@dangerace](https://meta.appinn.net/u/dangerace)\
发布日期： [2021 年10 月 24 日 10:58 UTC](https://meta.appinn.net/t/topic/27003/2 "2021-10-24T10:58:44Z")

</div>

楼主有心了，这套文件、文件夹命名“规范”我认为已经初具雏形，有一定的合理性，可以供使用文件名管理文档的人群借鉴。

当然有些细节也可以继续探讨。例如楼主设计了“#”、“@”、“^”等不同代号来代表后面信息不同类型，这个想法很赞，但是实际运用中，这样会不会增加用户的（记忆）使用成本？在整个文件名都是文本格式的前提下，这样区分不同信息的“类型”有多大必要性等等。

在有everything这样的文件名搜索神器的加持下，可能多数人仅仅把需要的关键信息放到文件名中就足够了，也许“(20210918)#todo@小王^补充性说明.txt”和“20210918-todo-小王-补充性说明.txt”甚至“20210918。todo。小王。补充性说明.txt”之间，并没有本质上的区别，不会对搜索造成什么影响。后者反倒输入更加随心所欲，方便快捷。

以上对楼主的方案设计做了一些评论，不代表我不同意楼主的方案，只是凭心而论提出一些可能的看法供楼主参考；相反，我非常赞同楼主这样，能够对生活中很多人习以为常的一些情况认真思索，认真总结，提出改进优化方案。再次表示对楼主的赞赏。

---

<div class="post-metadata">

作者： ![HaujetZhao](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/h/67e7ee/32.png) [@HaujetZhao](https://meta.appinn.net/u/HaujetZhao)\
发布日期： [2021 年10 月 24 日 11:15 UTC](https://meta.appinn.net/t/topic/27003/3 "2021-10-24T11:15:26Z")

</div>

使用这些符号也是经过了考虑的：

- `#` 在微博、twitter 上面，被广泛地用作标签
- `@` 在网上也被广泛地用作提及某人 @dangerace
- `^` 在正则表达式中被用于表示行首

尤其是前两个符号，只要是个上网多的现代人，基本都能下意识地认为：这是标签、这是提及某人

即使是新人，看到了这个文件名，对其中的名词、名字不熟悉，但看到那样的符号，也能轻易区分出，里面的标签、提及名字部分。

当我们用标签的时候，主要意思是其内容与 xxx 有关；当我们说提及某人时，是指它是其中的人物、作者等等，但主要内容不一定与它有关。

例如，使用 `@天弦集团` 可以表示：天弦集团是利益相关（例如文档发布者），但内容不一定是讲天弦集团的。

而使用 `#天弦集团` 则一定表示这个文件的内容跟天弦集团密切相关，但作者不一定是天弦集团。

再比如，`#哲学` 一眼就知道，是讲哲学话题的，而使用 `@哲学` 则明确表示有个叫哲学的人是文件的利益相关者。

而使用 `_` 就会混淆提及、标签之间的作用。

---

<div class="post-metadata">

作者： ![homefairy](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/h/9dc877/32.png) [@homefairy](https://meta.appinn.net/u/homefairy)\
发布日期： [2021 年10 月 24 日 11:46 UTC](https://meta.appinn.net/t/topic/27003/4 "2021-10-24T11:46:37Z")

</div>

有个问题是发布的时候你可能不希望暴露这些标注信息，然后你又需要改文件名，或者复制一份 :sweat_smile:

---

<div class="post-metadata">

作者： ![DavidJoy](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/davidjoy/32/58244_2.png) [@DavidJoy](https://meta.appinn.net/u/DavidJoy)\
发布日期： [2021 年10 月 24 日 12:17 UTC](https://meta.appinn.net/t/topic/27003/5 "2021-10-24T12:17:46Z")

</div>

我觉得这套命名方案十分完备

以下是构思，对于我来说应该如何运用这个方案，并结合了大家的思考。

### 可以立刻运用于新的文件

新的文件可以立刻按照这套方案执行，因为这套方案是完备的，没有副作用。  
唯一可能存在的问题是没时间完备地命名，也就是效率问题：

1. [作者发的图片命名构思](https://meta.appinn.net/t/topic/26987)，使用配合这套命名法的重命名程序，或者Quicker动作。我觉得作者可以按照这个方案开发一个产品出来 :joy:
2. 不太重要或者不想给别人看标注时，选择不严格命名。作者也说了命名细节是可选择的，增加弹性，缓解强迫症

> [@homefairy](#):
>
> 有个问题是发布的时候你可能不希望暴露这些标注信息

1. 看了这个回复，引发了我从另外一个角度考虑，就是命名时这些英文符号和中文名称夹杂在一起，切换输入法可能会降低效率，也就引出了前几天的一个讨论：[英文符号输入方法](https://meta.appinn.net/t/topic/26834)

> [@dangerace](#):
>
> 例如楼主设计了“#”、“@”、“^”等不同代号来代表后面信息不同类型，这个想法很赞，但是实际运用中，这样会不会增加用户的（记忆）使用成本？

### 如何处理过去的文件

我不可能把它们都重新命名，这个工程量很大，而且不一定有收益。  
这句话说得很好

> [@HaujetZhao](#):
>
> 没有良好命名的文件，基本就是没有意义的文件。

我要做的事不是把所有文件都重命名好，而是当我需要用到过去的文件时，说明它们突然有了意义，这时再把它们按照新的方案重命名好，以备下一次用。

---

<div class="post-metadata">

作者： ![deanme](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/deanme/32/1331_2.png) [@deanme](https://meta.appinn.net/u/deanme)\
发布日期： [2021 年10 月 24 日 12:42 UTC](https://meta.appinn.net/t/topic/27003/6 "2021-10-24T12:42:20Z")

</div>

tagLyst

---

<div class="post-metadata">

作者： ![HaujetZhao](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/h/67e7ee/32.png) [@HaujetZhao](https://meta.appinn.net/u/HaujetZhao)\
发布日期： [2021 年10 月 24 日 13:55 UTC](https://meta.appinn.net/t/topic/27003/7 "2021-10-24T13:55:38Z")

</div>

> [@DavidJoy](#):
>
> 就是命名时这些英文符号和中文名称夹杂在一起，切换输入法可能会降低效率

已更新，将评论的前缀符号，改成了 `&`，以确保在中文输入法下，不用来回切换输入法，也能便捷地输入。

---

<div class="post-metadata">

作者： ![Ghost\_Girls](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/ghost_girls/32/20608_2.png) [@Ghost\_Girls](https://meta.appinn.net/u/Ghost_Girls)\
发布日期： [2021 年10 月 24 日 14:24 UTC](https://meta.appinn.net/t/topic/27003/8 "2021-10-24T14:24:49Z")

</div>

作为一个专业版用户，我只能告诉你，Taglyst不能管理超过几万个文件的文件夹，也就说它 **连返回上级目录检索文件都要卡上7秒钟** ，这个是绝对不能忍受的。  
此外，Taglyst同一个数据库仅能使用一种命名格式，不能灵活的使用。

- 打开软件随机跑死
- 打开文件夹要2~3秒
- 返回上一级文件夹要7秒

**数据基于MICRO U.2企业级SSD，基于Netlist 企业级 U.2 SSD ，基于MICRON Sata SSD测试，在数据库添加测试中，结果是SATA（72s）比U.2（80s）还快8秒，这就非常的离谱**

---

<div class="post-metadata">

作者： ![haitao](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/h/958977/32.png) [@haitao](https://meta.appinn.net/u/haitao)\
发布日期： [2021 年10 月 24 日 14:45 UTC](https://meta.appinn.net/t/topic/27003/9 "2021-10-24T14:45:36Z")

</div>

检索通过everything，  
设置修改标签、查询界面 通过一个程序，它把标签转为新的文件名，把查询的标签转为向everything发请求。。。。

---

<div class="post-metadata">

作者： ![HaujetZhao](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/h/67e7ee/32.png) [@HaujetZhao](https://meta.appinn.net/u/HaujetZhao)\
发布日期： [2021 年10 月 25 日 17:06 UTC](https://meta.appinn.net/t/topic/27003/10 "2021-10-25T17:06:03Z")

</div>

已实现 Quicker 动作辅助重命名了，特意更新下：

[规范文件命名](https://getquicker.net/Sharedaction?code=fac14427-c0f5-4567-c945-08d99706f10d)

 ![image](https://meta.appinn.net/uploads/default/original/3X/b/d/bddea40d65d5a0d20619febd97f6b9b09b62b6c9.png)

---

<div class="post-metadata">

作者： ![hoknight](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/hoknight/32/20286_2.png) [@hoknight](https://meta.appinn.net/u/hoknight)\
发布日期： [2021 年10 月 26 日 05:39 UTC](https://meta.appinn.net/t/topic/27003/11 "2021-10-26T05:39:30Z")

</div>

我日常需要在多语种环境（中英日），且很多文件需要跟他人一起处理，文件多起来，实在懒得一个个用规范命名

---

<div class="post-metadata">

作者： ![lesliexin](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/l/7feea3/32.png) [@lesliexin](https://meta.appinn.net/u/lesliexin)\
发布日期： [2021 年10 月 26 日 06:09 UTC](https://meta.appinn.net/t/topic/27003/12 "2021-10-26T06:09:12Z")

</div>

很完善的命名规范。  
不过日常很难完全应用。我个人的一些文件也会有类似的命名规范，不过不是统一的，比如音乐是：作者-歌曲名（-专辑），照片是：设备-时间戳，等等。  
因为这些文件是我自己保存的，所以我不需要在标题上写太过详尽的说明。  
而且我更喜欢使用资源管理器，一层一层文件夹去分门别类的去存放文件。

---

<div class="post-metadata">

作者： ![HaujetZhao](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/h/67e7ee/32.png) [@HaujetZhao](https://meta.appinn.net/u/HaujetZhao)\
发布日期： [2021 年10 月 26 日 06:56 UTC](https://meta.appinn.net/t/topic/27003/13 "2021-10-26T06:56:05Z")

</div>

一个案例示例，我刚刚把电脑上的几本电子书，用规范命名法命名了，现在在 Listary 里就可以方便地从多个维度通过搭配条件找到想要的书，不再是需要记起时间久远想不起来的书名：

 ![image](https://meta.appinn.net/uploads/default/original/3X/b/c/bc7ff523bfa5fa97fa6767e2733b5e1a89d8806f.png)

而且这样的命名，在文件管理器里也看着舒服了。

以前总苦于没有好用的电子书管理器，不方便通过书籍元数据搜索，现在就没这烦恼了！

> [@lesliexin](#):
>
> 比如音乐是：作者-歌曲名（-专辑）

不用完全运用，这个方法弹性很大，例如对于歌曲，我在运用这个方法后，就可以方便规范地在原歌名的基础上，往文件名加添加更多信息，例如：

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

```

就表示：

- 歌曲名是 《我还年轻，我还年轻》
- 歌手是 咩咩爱睡懒觉
- 歌曲是翻唱版本
- 原唱是 老王乐队

---

<div class="post-metadata">

作者： ![anon23138622](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/a/a88e57/32.png) [@anon23138622](https://meta.appinn.net/u/anon23138622)\
发布日期： [2021 年11 月 3 日 03:38 UTC](https://meta.appinn.net/t/topic/27003/14 "2021-11-03T03:38:20Z")

</div>

噢哈哈哈，我的资料文件夹截图给你们看

 ![图片](https://meta.appinn.net/uploads/default/original/3X/3/3/33aa4c617392fe6ee95ae06d9f2d401d37e0cf63.png)  
 ![图片](https://meta.appinn.net/uploads/default/original/3X/7/0/7040da85d7182090f9dd7e10cfec91a83b2b525c.png)  
 ![图片](https://meta.appinn.net/uploads/default/original/3X/a/5/a5c0e436574d9cc5df58e2e152d87ba31fcd5f24.png)  
 ![图片](https://meta.appinn.net/uploads/default/original/3X/3/4/345ac5fce638b8297284d97fa509f2e81f8ebf1d.png)  
emm，专门写了个小工具，有需要的可以问我要源码，自行添加/减少标签，更换分隔符之类的哈，哈哈哈

---

<div class="post-metadata">

作者： ![beng-da-ba-la](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/b/b3f665/32.png) [@beng-da-ba-la](https://meta.appinn.net/u/beng-da-ba-la)\
发布日期： [2021 年11 月 3 日 05:29 UTC](https://meta.appinn.net/t/topic/27003/15 "2021-11-03T05:29:53Z")

</div>

先收藏在慢慢看 学习起来 不过就怕不好操作 时间久了 自己也忘了规则

---

<div class="post-metadata">

作者： ![dangerace](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/dangerace/32/16676_2.png) [@dangerace](https://meta.appinn.net/u/dangerace)\
发布日期： [2021 年11 月 3 日 07:12 UTC](https://meta.appinn.net/t/topic/27003/16 "2021-11-03T07:12:39Z")

</div>

不错不错，加油！  
另外推荐一下拙作Document TagExplorer，也可以和您的作品一样，为文件更名，额外还可以批量进行，也许对您的小作品的完善优化有一些借鉴意义。

> [@【20231024更新】Document\_TagExplorer -免费好用的windows文件标签分类管理工具](https://meta.appinn.net/t/topic/24381):
>
> V6.7.5.0以后的最新版本，已经在本论坛另开新帖进行更新了，请点击[这里](https://meta.appinn.net/t/topic/50445)跳转。 软件名称 Document TagExplorer 一款免费的windows文件标签管理工具 V6.0.1.0 Quick\_TagViewer 更新为V1.8.1.1 应用平台 Windows 推荐类型 【开发者自荐】 一句简介 一款给文件打标签、加备注，并利用标签和备注对文档进行分类、搜索的文件管理器。 应用简介 您的视频文件是如何分类管理的？如何才能快速找到所有[国产]神剧？如何才能一键搜出所有[印度出品]的[英文版][歌舞剧]？ 您的照片是如何分类管理的？如何才能快速找到所有带1岁儿子时在云南旅游的照片？如何才能一键搜出所有卡片机在2017年在泰国拍摄的照片？ 您的办公文档是如何分类管理的？… 分成不同文件夹进行管理吗？是按照“国别”建立文件夹好？还是按照“类型”建立文件夹好？又或者是按照“语言”建立文件夹？还需要按“场景”分类怎么办？ 又或者是通过修改文件名来进行记录和区别？可是N长的文件名看着眼晕怎么办？并且根据实际需要，文件名还会变来变去，着实不方便管理。 使用分成不同文…

 ![image](https://meta-edge.appinn.com/uploads/default/original/3X/f/4/f46255494d75d80953a48eab56fcaf12d87d8ea7.png)

---

<div class="post-metadata">

作者： ![xiaokonglong](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/xiaokonglong/32/908_2.png) [@xiaokonglong](https://meta.appinn.net/u/xiaokonglong)\
发布日期： [2021 年11 月 3 日 07:49 UTC](https://meta.appinn.net/t/topic/27003/17 "2021-11-03T07:49:11Z")

</div>

对于陈年的旧文件, 其实这种方法太累人了. 适合一开始就建立良好命名规范的人.

而且如果是收集来的文件, 也需要挨个改名, 工作量其实也不小.

所以, 一定程度的规范命名我是支持的. 但是过于严谨和繁琐的命名规范并不具有普适性.

其实只要不是 “新建文档1.docx 新建文件夹(1)” 这种过于随意的命名, 有个基本的表达文档含义的标题就行.

因为有更好的办法来解决归档和检索问题.

一般来说有2种办法: 不过都只适合文档用户, 不适用多媒体文件.

方法一: 利用文档本身的属性

 ![image](https://meta.appinn.net/uploads/default/original/3X/c/1/c15094f8da3b7cf589bebb9a18d414bbda6f6055.png)

在说明组别里, 可以录入标题、主题、标记、类别、备注， 这些数据可以录入更多信息，实现更详细的检索和归档。

word本身就支持对这些信息的填写。

 ![image](https://meta.appinn.net/uploads/default/original/3X/c/1/c1c9326aef8f82a5bd417b15954057b99a7ef900.png)

这些信息在资源管理器的栏目里， 也可以查看到。

 ![image](https://meta.appinn.net/uploads/default/original/3X/f/4/f4fe18c7f7a83f324139a7f4321de7a4619bd18e.png)

这种方法其实并不比重命名方便多少， 但是好处是可以突破文件命名的字符长度限制，也避免了重命名可能导致的编码问题。

> windows系统下文件名长度为:255个英文字符(DOS下8.3格式),包括文件名和扩展名在内,或者是255/2=127个中文字符+1个英文字符

> 如果这个文件不在根目录下,而是在某个文件夹下,需要减去文件夹名字的长度。有几层文件夹就需减去所有层数相加的文件夹名长度。
> 
> ![image](https://meta.appinn.net/uploads/default/original/3X/3/8/38279c3af82485463ca903ef7faf6ed3cb7dae90.png)

所以真正整理起来的时候，由于各种层级分类，很可能整理到后面，文件名长度严重受限。

另外一种方法就是内容检索， 这也是系统自带的功能。

比如windows search ， 很多人因为资源占用的原因会选择停用这个服务，论坛里有人推广过bbdoc，也是免费的。我一直用着，除了第一次索引比较慢，以后会好很多。

内容索引可以超越命名本身的信息，也不需要用户遵守某种规范，实在是懒人的首选方案。 🤪 😜

---

<div class="post-metadata">

作者： ![anon23138622](https://meta-edge.appinn.com/letter_avatar_proxy/v4/letter/a/a88e57/32.png) [@anon23138622](https://meta.appinn.net/u/anon23138622)\
发布日期： [2021 年11 月 3 日 09:51 UTC](https://meta.appinn.net/t/topic/27003/19 "2021-11-03T09:51:10Z")

</div>

哈哈哈，好东西，我的就是拿来用眼睛检索用的，所以要按照顺序指定标签，目前暂时够用，哈哈哈，比我强太多了，我就会用个vb，而且连拖拽文件到软件上面都没写好

---

<div class="post-metadata">

作者： ![zaonie](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/zaonie/32/14754_2.png) [@zaonie](https://meta.appinn.net/u/zaonie)\
发布日期： [2021 年11 月 9 日 00:49 UTC](https://meta.appinn.net/t/topic/27003/20 "2021-11-09T00:49:45Z")

</div>

楼主和小恐龙的方案都很好。谢谢！

---

<div class="post-metadata">

作者： ![bcaso](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/bcaso/32/20852_2.png) [@bcaso](https://meta.appinn.net/u/bcaso)\
发布日期： [2021 年11 月 21 日 10:35 UTC](https://meta.appinn.net/t/topic/27003/21 "2021-11-21T10:35:25Z")

</div>

前缀如果只用来排序的话，可以用16进制，3个10进制数表示范围：000~999，共1000个，而3个16进制表示范围：000~FFF，共4096个，同样的3位，用16进制，能多表示3096个。

linux下的 `ls`, windows cmd 下的 `dir`，浏览器如果当作文件管理器`file:///` , 都支持16进制排序。

唯独 windows 下的资源管理器，和其他的一些第三方管理器可能不支持。  
第三方资源管理器 total commander 支持 16 进制排序，在设置 → 显示 → 排序方式 ，选择 按字符代码排序。

windows 资源管理器改为 16 进制排序的方法：  
[https://www.smwcentral.net/?p=viewthread&t=104294&page=1&pid=1554219#p1554219](https://www.smwcentral.net/?p=viewthread&t=104294&page=1&pid=1554219#p1554219)

[下一页](https://meta.appinn.net/t/topic/27003.md?page=2)