为什么 Windows 11 仍不允许将文件命名为 CON？微软的解释要追溯到 MS-DOS

Windows 11 26H2 不允许将文件夹命名为 CON，这项规则可追溯至 DOS 时代

在 Windows 11 中，你可以给文件取一个长达 200 个字符、塞满空格和表情符号的名字，但千万别试着把文件或文件夹命名为 CON，因为文件资源管理器会直接拒绝。CON、PRN、AUX、NUL、COM1 到 COM9 以及 LPT1 到 LPT9 都是保留的设备名称。微软工程师 Raymond Chen 追溯发现，这些名称源自 DOS 1.0——那个连文件夹都不支持的版本！

我在运行 Windows 11 26H2 的电脑上试了一下，这项从 1981 年的操作系统沿用至今的规则依然存在。不过，Windows Latest 发现，其中部分规则的实际表现已与微软文档所述不符。

Windows 11 26H2 文件资源管理器在尝试将文件夹重命名为 CON 后显示错误。图片来源：Windows Latest

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

每个保留名称都对应一种设备，而我最喜欢的是 NUL：一个会吞掉所有输入内容的黑洞。

保留名称对应对象CON控制台（键盘和屏幕）PRN打印机AUX辅助设备NUL空设备（丢弃输出）COM1 到 COM9串行端口LPT1 到 LPT9并行端口（打印机端口）

 

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

Windows 11 拒绝将文件夹重命名为 PRN。图片来源：Windows Latest

添加扩展名按理说也没用（剧透：有些情况下确实有用）。微软表示：“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 Museum 的 Michal Necasek 称这是“致命缺陷”，因为像 CON 这样的名称无法让 DOS 判断你指的是文件还是控制台。

运行 CP/M 2.2 的 Sanco 8001 电脑（1982 年）。来源：Michael Specht

Chen 在 2003 年发表于他的 Old New Thing 博客的一篇文章中解释说：“DOS 1.0 不支持子目录、小写字母，也不支持超过 8.3 格式的文件名。”这也恰好解释了一个奇怪现象：Windows 11 中最古老的系统文件仍保留着 DOS 时代的名称。

当时，如果汇编程序问你要把输出保存到哪里，而你想打印出来，“就把‘PRN’输入为文件名。”输入 NUL 会丢弃输出，而 CON 则会把内容显示在屏幕上。

磁盘上只有一个目录时，这些神奇名称没有其他地方可用。1983 年 DOS 2.0 引入文件夹后，Chen 提到，如果这些名称在文件夹中不起作用，你就无法切换到某个文件夹、运行汇编程序，再输入 NUL 来丢弃输出。因此，微软让这些名称在每个文件夹中都能使用。这也就是为什么如今你的“文档”文件夹里不能有一个名为 PRN 的文件。

那么，微软为什么 40 多年来一直没有清理这摊乱象？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。

Windows 11 26H2 文件资源管理器显示 NUL.txt 和 CON.txt 已作为普通文件创建 图片来源：Windows Latest

微软文档尚未更新，但研究 Python 的 Windows 支持机制的开发者早在 2022 年就发现，Windows 11 处理文件路径时，已不再将带扩展名的设备名称视为特殊名称。

遗憾的是，这类文件的行为可能很奇怪。一位 Microsoft Q&A 用户发现，PowerShell 可以列出 NUL.txt，却无法打开或删除它。一位社区顾问回应说，“结果可能无法预测。”或许这就是微软坚持认为 NUL.txt 和 CON.txt 不受扩展名影响的原因。

开发者发现，带扩展名的保留文件名无法解析为对应的 NT 路径

想体验一下的话，可以用命令提示符展示 DOS 时代的“魔法”。运行 echo hello > CON 会在屏幕上显示“hello”，而不是创建文件；运行 echo test > COM¹ 则会失败，和微软文档描述的一样。

不过，在你批评 Windows 之前，要知道 Linux 维护者在 2024 年将一个图形驱动文件从 aux.c 重命名为 auxch.c，因为这个文件名导致人们无法在 Windows 上克隆 Linux 内核。

现在你可以批评 Windows 了：Linux 为了 Windows 修改了代码，Windows 却不肯废除一项 1981 年的规则，只为兼容那些几十年来都没人碰过的脚本。

不过，Windows 11 确实放宽了规则，至少让 NUL.txt 能够通过，但 CON 仍被视为设备，而不是文件名。就像 Windows 11 中仍保留着 Windows 95 的堆管理器一样，这又是一件微软无法移除的遗留问题，否则就可能破坏某人的 30 年历史的批处理文件。