Windows文件命名六大禁忌 原因要追到1981年的DOS 1.0：40多年没动

在Windows上用户可以给文件起甚至200个字符的命名，塞满空格和emoji都没问题，但有几个特殊的名字，系统却会直接拒绝。

即便是在最新的Windows 11 26H2上，用户仍无法将文件或文件夹命名为CON、PRN、AUX、NUL、COM1-COM9、LPT1-LPT9，会直接提示指定的设备名无效。

原因在于这些是保留设备名，每个对应一个设备：CON是控制台（键盘和屏幕），PRN是打印机，AUX是辅助设备，NUL是空设备（吞掉一切输出），COM1至COM9是串口，LPT1至LPT9是并口。

微软文件命名文档也告诉开发者不要使用这些保留名作为文件名，这一规则也适用于文件夹，因为Windows把文件夹当作特殊类型的文件。加扩展名也没用，像NUL.txt和NUL.tar.gz都等同于NUL。

根据微软资深工程师Raymond Chen在2003年博客中解释，这条规则要追溯到1981年的DOS 1.0，DOS 1.0不支持子目录、小写字母和超过8.3的文件名。

但根源并不在DOS本身，而是DOS想兼容的CP/M，CP/M里设备名会带冒号，比如CON:，一看就知道是设备不是文件，MS-DOS为了兼容CP/M，把冒号变成了可选。

DOS 1.0时代只有一个目录，这些名字没有歧义，汇编器问输出存哪，输入PRN就是打印，输入NUL就是丢弃，输入CON就是显示在屏幕上。

1983年DOS 2.0引入文件夹后问题来了，如果保留名只在根目录生效，切到子文件夹运行汇编器时输入NUL就不管用了。

微软的解决办法是让这些名字在每个文件夹里都生效，这就是如今文件夹里不能有这些命名的原因。

之所以40多年没清理，Chen的回答很简单：“大家还在依赖它们。”，比如批处理用>NUL隐藏输出，脚本用if exist directoryname/nul检查文件夹是否存在，老教程教人用copy CON创建文件。一旦规则被删，每个重定向到NUL的脚本都会开始往磁盘写真实文件，后果不堪设想。

不过根据Windows Latest在Windows 11 26H2上逐一测试后发现，NUL.txt和CON.txt两个文件名均顺利通过，没有任何报错提示，虽然微软官方文档明确写着NUL.txt等于NUL，但实际行为已经与之矛盾。

这一变化并非26H2才出现。早在2022年，参与Python Windows支持开发的程序员就注意到，Windows 11在处理文件路径时不再将带扩展名的设备名视为特殊设备。也就是说，NUL.txt不再被系统解析为NUL设备，而是当作普通文件名处理，微软文档未能及时跟进这一底层逻辑变更。

但有用户在Microsoft Q&A反馈称，PowerShell能列出NUL.txt，却无法打开或删除它，社区顾问回复也称“结果可能不可预测”。