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

背景

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

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

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

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

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

  • 对人类(我)的可读性高吗?
  • 概括性强吗?
  • 方便我以后快速检索到吗?
  • 对软件兼容吗?
  • ……

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

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

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

  • 第一部分为阐述文件主题,观其名知大意;
  • 第二部分为文件所属类别,如在单位工作的写工作部分、学生人群可写班级等;
  • 第三部分为文件创建者;
  • 第四部分为当前文件的日期;
  • 第五部分为文件阶段标识,用于版本管理。

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

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

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

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

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

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

命名原则

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

  1. 时间:年、月、日、时分秒,根据实际情况决定精度
  2. 前缀:可以是数字序号、大的分类;不常用,主要目的是为文件进行手动排序
  3. 标题:文件的主标题,描述文件内容的本质
  4. 版本:版本号,对于需要迭代的项目文件很重要
  5. 标签:标题之外的补充信息,例如地点、文件性质
  6. 人物:可以是人名、组织名、宠物名、作者、来源答主
  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 个 元数据块

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

标题规范

科研标题

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

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

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

录像素材标题

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

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

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

严格命名细则

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

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

  2. 符号仅使用 - _ .

  3. 不能使用空格

  4. 每个 元数据块 之间,应当使用 块间分隔符,推荐 ___ ,例如:

    • YYYYMMDD__Title__Author.ext
    • YYYYMMDD_Title_Author.ext
    • Title__Author.ext

    我个人更喜欢 __,因为文件名首先是给人读的,使用双下划线,对人类的易读性更高

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

    • YYYYMMDD__Attr1.Attr2.Attr3__Tag1.Tag2__Author1.Author2.ext
    • YYYYMMDD__Attr1-Attr2-Attr3__Tag1-Tag2__Author1-Author2.ext
  6. 年月日、时分秒之间,应当使用 块内分隔符,例如:

    • YYYYMMDD-HHMMSS__Title__Author.ext
  7. 连续使用多个单词时,推荐使用 驼峰法块内分隔符(一定不要用空格),如:

    • 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
    标题: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

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

录像素材命名示例

参考模板:

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岗位-姓名-学校-手机号
  • 姓名+学历+学校+实习时间+应聘岗位+意向城市+手机号

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

如何用

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

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

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

Quicker 动作 使用示例:

参考

5 Likes

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

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

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

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

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

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

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

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

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

例如,使用 @天弦集团 可以表示:天弦集团是利益相关(例如文档发布者),但内容不一定是讲天弦集团的。

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

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

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

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

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

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

可以立刻运用于新的文件

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

  1. 作者发的图片命名构思,使用配合这套命名法的重命名程序,或者Quicker动作。我觉得作者可以按照这个方案开发一个产品出来 :joy:
  2. 不太重要或者不想给别人看标注时,选择不严格命名。作者也说了命名细节是可选择的,增加弹性,缓解强迫症
  1. 看了这个回复,引发了我从另外一个角度考虑,就是命名时这些英文符号和中文名称夹杂在一起,切换输入法可能会降低效率,也就引出了前几天的一个讨论:英文符号输入方法

如何处理过去的文件

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

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

2 Likes

tagLyst

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

1 Like

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

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

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

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

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

规范文件命名

2 Likes

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

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

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

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

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

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

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

就表示:

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

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


图片

图片
emm,专门写了个小工具,有需要的可以问我要源码,自行添加/减少标签,更换分隔符之类的哈,哈哈哈

2 Likes

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

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

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

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

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

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

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

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

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

image

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

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

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

image

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

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

如果这个文件不在根目录下,而是在某个文件夹下,需要减去文件夹名字的长度。有几层文件夹就需减去所有层数相加的文件夹名长度。
image

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

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

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

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

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

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

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

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

唯独 windows 下的资源管理器,和其他的一些第三方管理器(如 total commander) 不支持。

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