Когда я увидел японские и корейские пути в EnvStudio, я думал, что это баг
2026-05-15
Теги: Windows · EnvStudio · Дневник разработчика
Завершив интернационализацию EnvStudio на 10 языков, я начал тестирование в многоязычных средах. Всё шло гладко — пока не увидел значение переменной окружения PATH на японских и корейских системах.
Погодите, почему разделитель пути превратился в валюту?
В англоязычной системе PATH выглядит так:
C:\Users\Name\AppData\Local\ProgramsВ японской системе это превращается в:
C:¥Users¥Name¥AppData¥Local¥ProgramsВ корейской системе:
C:₩Users₩Name₩AppData¥Local¥Programs¥ (иена) и ₩ (вона)?? Первая мысль: в моём коде баг в отображении путей.
После тщательной проверки оказалось, что EnvStudio не содержит никакой логики обработки путей, модифицирующей эти символы. Значение PATH считывается как есть из реестра Windows. Система передаёт его именно в таком виде.
Это не баг — это «историческое наследие» Windows десятилетней давности
Изучив вопрос, я обнаружил, что это поведение существует уже десятилетия и продолжается в Windows 11.
0x5C: один байт, три лица
История начинается с кодировки символов. В ASCII обратный слеш \ имеет байтовое значение 0x5C. Но в японских и корейских наборах символов этот байт был назначен другим символам:
| Кодировка | Язык | 0x5C отображается как |
|---|---|---|
| CP1252 | Западный | \ Обратный слеш |
| CP932 | Японский (Shift-JIS) | ¥ Знак иены |
| CP949 | Корейский | ₩ Знак воны |
| CP936 | Упрощённый китайский (GBK) | \ Обратный слеш |
| CP950 | Традиционный китайский (Big5) | \ Обратный слеш |
Это соответствие восходит к JIS X 0201 (Японский промышленный стандарт) 1970-х годов. В ограниченном 7-битном пространстве кодировки 0x5C был назначен знаку иены. Shift-JIS унаследовал это, а корейская кодировка пошла по похожему пути.
Проблема кодировки или проблема шрифта?
В Unicode обратный слеш (U+005C), знак иены (U+00A5) и знак воны (U+20A9) — три полностью отдельных кодовых точки. Когда Windows обрабатывает пути внутренне, 0x5C всегда является обратным слешем — он является разделителем путей, и это никогда не менялось.
Тогда почему он выглядит как ¥ и ₩?
Ответ — шрифты. Когда языковой стандарт системы установлен на японский или корейский, системные шрифты (такие как MS Gothic, Malgun Gothic) отображают глиф в U+005C как символ иены или воны вместо обратного слеша.
Майкл Каплан из Microsoft объяснил это в блоге так:
«После многих лет работы систем на базе кодовых страниц в Японии и Корее, где соответствующие символы валют использовались как разделители путей, считается, что клиенты просто привыкли к такому отображению.»
Иными словами: дело не в том, что нельзя изменить — дело в том, что намеренно не меняют.
Можно ли увидеть это в 2026 году?
Да. Зависит от того, что вы используете:
- cmd.exe: По-прежнему показывает
¥/₩ - Устаревшие приложения Win32: По-прежнему показывают
¥/₩ - Windows Terminal + современные шрифты (Cascadia Code и т.д.): Показывает
\ - Приложения WinUI 3 / UWP: Зависит от шрифта
Поэтому на одной и той же японской Windows вы можете видеть C:\Users в одном окне и C:¥Users в другом — и они указывают на один и тот же путь.
Возвращаясь к EnvStudio: нужно ли «исправлять»?
EnvStudio создан на WinUI 3 и использует встроенную поддержку Unicode в .NET. Поэтому интерфейс EnvStudio отображает обычный \.
Но если пользователь скопирует путь с ¥ из cmd.exe и вставит его, EnvStudio примет как есть — потому что Windows внутренне знает, что ¥ в этом контексте — это \, и разрешение пути работает корректно.
В итоге я решил не делать ничего специального. Причина проста: японские и корейские пользователи, вероятно, привыкли к такому отображению. Если бы я самовольно заменил ¥ на \, это могло бы запутать местных пользователей — «этот путь выглядит не так, как на моей системе, он неправильный?»
Иногда «ничего не делать» — лучшее исправление.
Если вы разработчик и впервые видите C:¥Users на японской или корейской системе во время тестирования интернационализации, надеюсь, эта статья сэкономит вам время на поиски несуществующего бага.