在 EnvStudio 里看到日韩路径的那一刻，我以为代码出 Bug 了
2026-05-15
在给 EnvStudio 做完 10 语言国际化支持后，我开始了多语言环境下的测试。一切都很顺利——直到我在日语和韩语系统上看到了 PATH 环境变量的值。
等等，路径分隔符怎么变成钱了？
英语系统上，PATH 长这样：
C:\Users\Name\AppData\Local\Programs日语系统上，变成了：
C:¥Users¥Name¥AppData¥Local¥Programs韩语系统上，则是：
C:₩Users₩Name₩AppData¥Local¥Programs¥（日元）和 ₩（韩元）？？我第一反应是：我的代码在显示路径的时候出 Bug 了。
仔细排查了一遍，EnvStudio 本身没有任何路径处理逻辑会修改这些字符。PATH 的值是从 Windows 注册表原样读出来的。也就是说，系统给我的就是这个样子。
不是 Bug，是 Windows 的"历史遗留特性"
搜了一圈资料后发现，这是一个存在了几十年的行为，至今仍在 Windows 11 上延续。
0x5C：同一个字节，三种面孔
故事要从字符编码说起。在 ASCII 中，反斜杠 \ 的字节值是 0x5C。但在日语和韩语的字符集里，这个字节被分配给了别的字符：
| 编码 | 语言 | 0x5C 显示为 |
|---|---|---|
| CP1252 | 西文 | \ 反斜杠 |
| CP932 | 日语（Shift-JIS） | ¥ 日元 |
| CP949 | 韩语 | ₩ 韩元 |
| CP936 | 简体中文（GBK） | \ 反斜杠 |
| CP950 | 繁体中文（Big5） | \ 反斜杠 |
这个映射可以追溯到 1970 年代的 JIS X 0201（日本工业标准）。当时的 7 位编码空间有限，0x5C 被分配给了日元符号。后来 Shift-JIS 继承了这个设定，韩语编码也走了类似的路。
是编码问题还是字体问题？
在 Unicode 中，反斜杠（U+005C）、日元符号（U+00A5）和韩元符号（U+20A9）是三个完全独立的码位。Windows 在内部处理时，0x5C 始终是反斜杠——它是路径分隔符，这个从未改变。
那为什么看起来是 ¥ 和 ₩？
答案是字体。当系统区域设置为日语或韩语时，系统使用的字体（如 MS Gothic、Malgun Gothic）在 U+005C 这个码位上，渲染出的 glyph 是日元或韩元符号，而不是反斜杠。
微软的 Michael Kaplan 在一篇博客中这样解释：
"在日语和韩语的代码页系统上使用各自的货币符号作为路径分隔符这么多年之后，人们相信用户已经习惯了这个样子。"
换句话说：不是改不了，是故意不改。
2026 年了，还会看到吗？
会。取决于你用什么：
- cmd.exe：仍然显示
¥/₩ - 旧版 Win32 应用：仍然显示
¥/₩ - Windows Terminal + 现代字体（Cascadia Code 等）：显示
\ - WinUI 3 / UWP 应用：取决于字体
所以在同一台日语 Windows 上，你可能在一个窗口里看到 C:\Users，在另一个窗口里看到 C:¥Users，而它们指向的是完全相同的路径。
回到 EnvStudio：要不要"修复"？
EnvStudio 是用 WinUI 3 构建的，使用 .NET 的 Unicode 原生支持。所以 EnvStudio 自己的界面上显示的是正常的 \。
但如果用户从 cmd.exe 复制了一段带 ¥ 的路径粘贴进来，EnvStudio 会原样接受——因为 Windows 内部知道 ¥ 在这个上下文中就是 \，路径解析不会出错。
最终我决定不做任何特殊处理。原因很简单：日韩用户可能已经习惯了这个显示方式。如果我擅自把 ¥ 替换成 \，反而可能让本地用户感到困惑——"这个路径和我系统上看到的不一样，是不是错了？"
有时候，"不做处理"就是最好的处理。
如果你也是开发者，在做国际化的时候第一次在日韩系统上看到 C:¥Users，希望这篇文章能帮你省掉一段"排查不存在的 Bug"的时间。