第 1154 期：为什么 Windows 11 至今仍不允许将文件命名为 CON|dos|linux|windows|命令提示符|微软|文件名|知名企业|管理器

在 Windows 11 中，您可以给文件起一个长达 200 个字符、充满空格和表情符号的名称，但请千万别尝试将文件或文件夹命名为“CON”，因为文件资源管理器会直接拒绝。CON、PRN、AUX、NUL 以及 COM1 至 COM9 和 LPT1 至 LPT9 都是操作系统保留的。微软资深工程师 Raymond Chen 指出，这些名称的由来源于 DOS 1.0——那个连文件夹都没有的操作系统！

我在运行 Windows 11 26H2 的电脑上试了一下，发现这个 1981 年沿袭至今的规则依然有效，不过我们发现，其中一部分行为已不再完全符合微软官方文档的描述。

在 Windows 11 中，CON、PRN、AUX 和 NUL 都是设备，而不是文件名

每个保留名称都对应一个设备，而 NUL 是我最喜欢的：一个会吞噬您发送给它的任何内容的 “黑洞”。

微软的文件命名文档仍然告知开发者：“请勿将以下保留名称用作文件名”，这些规则同样适用于文件夹，因为 Windows 将文件夹视为一种特殊类型的文件。

添加扩展名本不应该有任何作用（剧透：在某些情况下确实会起作用）。据微软称，“NUL.txt 和 NUL.tar.gz 都等同于 NUL”。就连上标数字也不例外，因为 Windows 会将 ¹、² 和 ³ 视为数字，所以 COM¹ 和 LPT³ 在 “每个目录” 中都被保留。

从架构上看，COM1 是 Windows 内核中串行端口的一个链接，微软将其称为 MS-DOS 设备名，因此输入 COM1 实际上是访问该端口，而不是某个文件。

Raymond Chen 解释了为何 DOS 1.0 的一条规则在 Windows 11 中仍然有效

故事始于 CP/M——MS-DOS曾试图与其保持兼容的操作系统。在 CP/M 中，设备名称总是带有冒号，例如 CON:。而 MS-DOS 则将冒号设为可选，OS/2 博物馆的米哈尔·内卡塞克称其为 “致命缺陷”，因为像 CON 这样简单的名称无法让 DOS 判断用户指的是文件还是控制台。

在 2003 年发表于其 “Old New Thing” 博客的一篇文章中，Raymond Chen 解释道：“DOS 1.0 不支持子目录、小写字母，也不允许文件名超过 8.3 格式”，这也正是为何 Windows 11 中最古老的系统文件至今仍沿用 DOS 时代的命名规则的奇特原因。

那时，如果汇编器询问输出应保存到何处，而您又想要一份打印输出，“只需将文件名设为 ‘PRN’ 即可”。输入 “NUL” 则会丢弃输出，而输入 “CON” 则会将其显示在屏幕上。

由于磁盘上只有一个目录，这些特殊名称也只能在此目录下生效。等到 1983 年 DOS 2.0 引入了文件夹功能后，Raymond Chen 提到：如果这些特殊名称在文件夹内不起作用，您就无法切换到某个文件夹、运行汇编器，再输入 “NUL” 来丢弃输出。因此，微软决定，让这些特殊名称在每一个文件夹中都能正常使用，而这一决策，也导致如今您的 “文档” 文件夹中无法创建名为 “PRN” 的文件。

那么，为什么微软在四十多年里一直没有解决这个问题呢？“因为大家仍然依赖它们，”Raymond Chen 写道。批处理文件通过将输出重定向到 >NUL 来隐藏输出，脚本则用 “if exist directoryname\nul” 来检查某个文件夹是否存在，而一些老旧的使用指南还会教您用 “copy CON” 来创建文件。

更巧的是，如果取消这条规则，所有将输出重定向到 NUL 的脚本都会开始真正地写入文件。

有趣的是，这条规则曾经导致整台电脑崩溃。Windows 95 和 98 对只包含一个设备名的路径能够正常处理，但遇到像 C:\con\con 这样的双设备名路径时就会出错。微软在 2000 年 3 月发布的 MS00-017 公告中也承认，这种情况 “通常会导致系统崩溃”。

我在 Windows 11 26H2 上测试了 DOS 时代的命名规则，结果 NUL.txt 竟然 “蒙混过关” 了

在我运行 Windows 11 26H2 的电脑上，将一个新创建的文件夹重命名为 CON 时，系统提示 “指定的设备名无效”，而 PRN、AUX、NUL 和 COM1 也被拒绝。

然而，NUL.txt 却顺利通过了，CON.txt 也是如此，尽管微软的官方文档仍然明确指出 NUL.txt 就是 NUL。