When I Saw Japanese and Korean Paths in EnvStudio, I Thought It Was a Bug
2026-05-15
Tags: Windows · EnvStudio · Dev Journal
After finishing the 10-language internationalization for EnvStudio, I started testing under different language environments. Everything was going smoothly — until I looked at the PATH environment variable on Japanese and Korean systems.
Wait, Why Did the Path Separator Turn Into Currency?
On an English system, PATH looks like this:
C:\Users\Name\AppData\Local\ProgramsOn a Japanese system, it becomes:
C:¥Users¥Name¥AppData¥Local¥ProgramsOn a Korean system, it's:
C:₩Users₩Name₩AppData¥Local¥Programs¥ (Yen) and ₩ (Won)?? My first thought: my code has a bug in how it displays paths.
After carefully reviewing everything, EnvStudio itself has no path processing logic that would modify these characters. The PATH value is read as-is from the Windows registry. In other words, the system gave me these characters.
Not a Bug — a Decades-Old Windows "Feature"
After some research, I discovered this behavior has existed for decades and continues to this day on Windows 11.
0x5C: One Byte, Three Faces
It all goes back to character encoding. In ASCII, the backslash \ has byte value 0x5C. But in Japanese and Korean character sets, this byte was assigned to different characters:
| Encoding | Language | 0x5C Displays As |
|---|---|---|
| CP1252 | Western | \ Backslash |
| CP932 | Japanese (Shift-JIS) | ¥ Yen Sign |
| CP949 | Korean | ₩ Won Sign |
| CP936 | Simplified Chinese (GBK) | \ Backslash |
| CP950 | Traditional Chinese (Big5) | \ Backslash |
This mapping traces back to JIS X 0201 (Japanese Industrial Standard) from the 1970s. With limited 7-bit encoding space, 0x5C was assigned to the yen sign. Shift-JIS inherited this, and Korean encoding followed a similar path.
Is It an Encoding Issue or a Font Issue?
In Unicode, the backslash (U+005C), yen sign (U+00A5), and won sign (U+20A9) are three completely separate code points. When Windows processes paths internally, 0x5C is always the backslash — it's the path separator, and that has never changed.
So why does it look like ¥ and ₩?
The answer is fonts. When the system locale is set to Japanese or Korean, the system fonts (such as MS Gothic, Malgun Gothic) render the glyph at U+005C as the yen or won symbol instead of a backslash.
Microsoft's Michael Kaplan explained it this way in a blog post:
"After many years of code page based systems in Japan and Korea using their respective currency symbols as the path separators, it is believed customers were simply used to this appearance."
In other words: it's not that they can't change it — they deliberately don't.
Can You Still See This in 2026?
Yes. It depends on what you're using:
- cmd.exe: Still shows
¥/₩ - Legacy Win32 apps: Still show
¥/₩ - Windows Terminal + modern fonts (Cascadia Code, etc.): Shows
\ - WinUI 3 / UWP apps: Depends on the font
So on the same Japanese Windows machine, you might see C:\Users in one window and C:¥Users in another — and they point to the exact same path.
Back to EnvStudio: To "Fix" or Not to Fix?
EnvStudio is built with WinUI 3 and uses .NET's native Unicode support. So EnvStudio's own interface displays the normal \.
But if a user copies a path with ¥ from cmd.exe and pastes it in, EnvStudio accepts it as-is — because Windows internally knows that ¥ in this context is \, and path resolution works correctly.
In the end, I decided to do nothing special. The reason is simple: Japanese and Korean users are probably used to this display. If I went ahead and replaced ¥ with \, it might actually confuse local users — "this path looks different from what I see on my system, is it wrong?"
Sometimes, "doing nothing" is the best fix.
If you're a developer and this is your first time seeing C:¥Users on a Japanese or Korean system during internationalization testing, hopefully this article saves you from spending time debugging a non-existent bug.