对一般办公文件来言，规范文件、文件夹合法的命名规则如下：
1、文件命名的结构
项目命名词（或项目编号）_文件命名词_日期_V版本号.文件后缀
例如：Doc_PCPIS Proposal_20101112_V1.0.doc
文件名称由四部分组成：
第一部分为项目名称或编号，第二部分为文件的描述，第三部分为当前文件的日期，第四部分为文件阶段标识加文件后缀。
如果是同一版本同一阶段的文件修改过两次以上，则在版本标识后面加以数字标识，每次修改数字加1； 当有多人同时提交同一份文件时，可以在版本标识的后面加入人名或缩写来区别。
2、文件命名规则
1，文件名最长使用255个字符；
2，可以使用扩展名，扩展名用来表示文件类型，也可以使用多间隔符的扩展名；
3，文件名中允许使用空格，但不允许使用下列字符（英文输入法状态）：<>/ \ | : " * ?
4，windows系统对文件名中字母的大小写在显示时有不同，但在使用时不区分大小写。
扩展资料：
DOS *** 作系统规定文件名由文件主名和扩展名组成，文件主名由1~8个字符组成，扩展名由1~3个字符组成，主名和扩展名之间由一个小圆点隔开，一般称为8.3规则。
文件扩展名是早期 *** 作系统（如VMS/CP/M/DOS等）用来标志文件格式的一种机制。以DOS来说，一个文件扩展名是跟在文件主名后面的，由一个分隔符号分隔。
在一个像“example.txt”的文件名中，example是文件主名，txt为文件扩展名，表示这个文件是一个纯文字文件，句号“.”就是文件主名与文件扩展名的分隔符号。
DOS作业系统（包括Windows 3.x）把文件扩展名限制在3个字符以内。个人电脑自从Windows95开始，在其他Windows *** 作系统上的FAT32文件系统中包含有一个界面水平的修正，使得文件扩展名的字数可以达到256个英文字符（长文件名）。
但是在系统层面，仍然保留3个字母的命名方式，这对很多用户来说都是不可见的。NTFS文件系统则没有这种限制。
这种命名法有着很大的缺陷，甚至安全的缺陷，所以某些 *** 作系统已经不再遵循文件扩展名的规范，而是采用更精确的文件魔术数字来确定文件类型。
不过Windows系列的作业系统即使是最新的Windows10都依然保持这种命名格式。
参考资料来源：百度百科-文件扩展名
参考资料来源：百度百科-文件名
====================源自DOS时代的8.3格式文件名规范====================所谓8.3格式短文件名规范，就是型如 PROGRA~1（目录）或者
元素周~1.exe（文件）这样的名称——
“8”是指文件名或目录名的主体部分小于等于8个字节；
“3”是指文件名的扩展名部分小于等于3个字节。
另外还有一点，就是8.3文件名的有效字符不包括空格等特殊字符。
8.3短文件名格式规范是DOS+FAT12/FAT16时代遗留下的老规矩，
自从Windows95开始（其实据说从Windows for Groups 3.11开始），
Windows就已经能支持长文件名，但是为了向前兼容，特别是文件系统兼容性，
FAT文件系统均强制执行“为长文件名提供8.3兼容格式的短文件名”的特性。
因此你会看到，在FAT16/32文件系统上：
目录"program files"同时还拥有一个8.3规范的"PROGRA~1"短名称；
而文件"元素周期表.exe"也同时拥有一个"元素周~1.exe"的短名称。
[这有一点像类UNIX系统下的hardlink，一个对象拥有两个引用方式。]
PS：知道为什么IE浏览器的主程序叫做iexplore.exe 而不是iexplorer么？
就是为了照顾8.3短文件名规范。
===================NTFS文件系统与8.3格式规范的兼容性===================
NTFS文件系统支持unicode（UTF16）字符集文件名，最长达255个UTF16字符，
因此NTFS文件系统以及基于unicode字符集的32位NT内核Windows *** 作系统
本身都没有必要遵循16位DOS时代遗留的8.3格式短文件名规范。
但还是为了兼容性，NTFS文件系统也提供了一个可选的特性：8.3兼容格式。
Windows中这个特性默认是on，也就是说每当建立一个长文件名的对象的同时，
系统的NTFS驱动模块会自动建立一个合适的8.3格式短名称指向这个对象。
需要指出的是，这个特性并不像FAT文件系统中那样是强制执行的，
因此不同的磁盘实用程序或者 *** 作系统可能有不同的执行方式——
比如windowsXP中可以用 fsutil behavior set disable8dot3 1 命令关闭，
驱动模块关闭这一特性后就不会每次都额外地建立一个附加的短名称，
这样在新建/重命名大量小文件/目录的时候能略微提升磁盘的写入速度，
（不用计算出一个合适的短文件名，也不用把这个额外的信息写入磁盘）。
=================非win32标准的老程序兼容性依赖8.3规范=================
但是，关闭这一特性之后可能导致某些古老的应用程序出现兼容性问题，
这些程序虽说是32位GUI界面的“windows应用程序”，却不完全遵循win32
程序的规范，而是通常混合有16位API，使用8.3格式短名称来引用文件。
很显然，如果在一个NTFS分区上根本就不为长文件名提供短名称，那么这些
16/32位混合型老程序将无法用8.3格式短名称来找到文件，当然会出错……
但是事情并不总是这么简单的——
最近我发现有几个老的应用程序不能正常启动，这包括曾经在科大校园网上
非常流行的科技大词典（主程序 ncce_win.exe，怎么样，熟悉不？）
细查原因，似乎只是放在NTFS分区才会出问题，移到FAT32的U盘上没问题。
后来我惊讶的发现：把U盘格成NTFS再放上这个程序也没问题！…… ……
数小时后，真正的的原因被找到了，说起来非常复杂，简而言之：
全路径上有一级目录不兼容短文件名格式，因此主程序找不到相关文件！
为什么会有一级目录不兼容8.3规范呢？
因为我的硬盘是在以前的硬盘出故障后新换的，换上来之前，我在
一个64位windows *** 作系统上把旧硬盘上还能读出的目录一一复制过来，
而那个64位windows关闭了NTFS的8.3兼容特性，复制来的目录和文件
都不具备附加的短名称，特别是我放应用程序的E:\program files\目录。
（64位windows理论上是完全不支持16位和16/32位混合程序的，因此可能
默认就关闭了NTFS驱动的8.3兼容性，或者也许是什么优化程序关闭的。）
然后我用GHOST恢复了系统分区，恢复的32位winXP并没有关闭8.3兼容性，
但关键问题是已经写入NTFS分区的（不具备短名称的）目录和文件并不会被
这个32位XP重建短文件名，系统只会对新建的文件或目录附加8.3文件名，
至于原先已经建立好的目录和文件，即使是重命名这种 *** 作，也无法
“提醒”XP检查并追加上一个短文件名——这一点让我百思不得其解。
于是，当我把软件放在E:\program files\的子目录中时，虽然子目录
“科技词典”，以及ncce_win.exe等文件名都符合8.3规范，但是全路径上
有一个“program files”是不符合8.3规范的，并且没有等效的短名称代替，
所以某个API就无法用“E:\progra~1\科技词典\xxxxxxxx.xxx”定位文件了，
这个程序当然无法正常启动。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）