在 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」的時間。