对windows文件名合法性的测试

Windows文件名能有多野？对w的测我试过在资源管理器里新建一个文件，名字叫 `con.txt`，文件结果系统直接弹窗拒绝。名合这不是法性权限问题，也不是对w的测文件被占用——`CON` 是DOS时代的保留设备名，从Windows 95到今天，文件它依然是名合禁区。类似的法性名字还有 `PRN`、`AUX`、对w的测`NUL`、文件`COM1` 到 `COM9`、名合`LPT1` 到 `LPT9`。法性你可以在命令行里 `echo test > con` 试试，对w的测输出会直接送到控制台设备，文件而不是名合创建文件。这种“历史债”藏得极深，普通用户根本不会撞上，但程序员写批量重命名工具时，稍不留神就会踩雷。

除了保留名，字符本身也有讲究。Windows文件名不能包含 `\ / : * ? " < > |` 这九个字符，这是文件系统解析路径的硬规则，改了就会导致路径歧义。比如 `:` 在NTFS里是数据流的分隔符，`?` 和 `*` 是通配符，`/` 和 `\` 是路径分隔符。这些限制不是拍脑袋定的，而是为了兼容旧系统。但有个冷门细节：空格和点号在文件名末尾会被自动修剪。你建一个 `test.txt `（末尾带空格），系统会静默改成 `test.txt`。同样，`test..txt` 中间的连续点号会被保留，但末尾的点号会被去掉——这导致某些从Linux拷贝过来的文件名，在Windows上会悄悄“变形”。

长度限制更隐蔽。Windows完整路径最长260个字符（`MAX_PATH`），但文件名本身最多255个字符。这看起来够用，可如果你把文件放在深层目录里，比如 `C:\Users\张三\Documents\项目A\2025年报告\最终版\修改3\` 这种嵌套结构，光路径就占了200多字符，文件名稍微长一点就报“文件名或扩展名太长”。Windows 10 1607版本后可以在注册表里开启长路径支持，但默认关闭，而且开启后某些老软件依然不认。我实际测过，开启后能用超过260字符的路径，但资源管理器的搜索功能会抽风——它索引不了超长路径，结果就是文件明明存在，搜索却找不到。

还有一类坑是Unicode规范化。Windows文件名存储用的是UTF-16编码，但同一字符可能有不同码位。比如韩文 `가` 有两种编码方式，一个完整码位和一个组合序列。NTFS默认不做规范化，所以你在程序A里用组合序列创建的文件，程序B用完整码位去访问，会提示文件不存在。这问题在macOS上也有，但Windows更隐蔽，因为资源管理器显示时做了规范化，你看不出区别。我自己写文件同步工具时就栽过——从Mac拷贝来的文件名，在Windows上偶尔出现“幽灵文件”，删不掉也打不开，最后用 `dir /x` 查出短文件名才删掉。

测试文件名合法性，最土的办法是直接调 `Path.GetInvalidFileNameChars()`，但那只查字符，不查保留名、长度和末尾空格。更靠谱的是实际调用 `File.Create()` 试试，让系统告诉你行不行。可这也不够——有些名字在创建时合法，但后续操作会出问题。比如文件名以点号开头，Windows允许创建，但某些老旧程序会把它当成隐藏文件，直接不显示。再比如文件名里带emoji，NTFS存得下，但如果你用FAT32格式的U盘拷过去，直接报错，因为FAT32不支持某些Unicode码位。

最讽刺的是，Windows自己有时也违反规则。系统更新时偶尔会生成带 `~` 的临时文件名，短横线开头，这本身合法，但某些杀毒软件会误报。还有OneDrive同步时，会把本地文件名里的非法字符自动替换成 `_`，等你同步回来，文件名已经变了，你根本不知道哪个文件被改过。所以，测试文件名合法性，别只看规则，得结合使用场景——如果你是写工具的人，最好在保存前就做完整校验，别依赖系统报错，因为报错信息往往很模糊，用户根本看不懂。