EnvStudio で日韓のパスを見た瞬間、バグだと思った

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

¥（円）と ₩（ウォン）？？最初の反応は：パス表示のコードにバグがあるんだでした。

慎重に確認しましたが、EnvStudio 自体にはこれらの文字を変更するパス処理ロジックはありません。PATH の値は Windows レジストリからそのまま読み込まれています。つまり、システムがこの形で渡してきているのです。

調べてみると、この動作は数十年前から存在し、Windows 11 でも続いています。

話は文字エンコーディングに遡ります。ASCII では、バックスラッシュ \ のバイト値は 0x5C です。しかし日本語と韓国語の文字セットでは、このバイトは別の文字に割り当てられていました：

このマッピングは 1970 年代の JIS X 0201（日本工業規格）に遡ります。限られた 7 ビットの符号化空間で、0x5C は円記号に割り当てられました。後に Shift-JIS がこれを引き継ぎ、韓国語のエンコーディングも同様の道を歩みました。

Unicode では、バックスラッシュ（U+005C）、円記号（U+00A5）、ウォン記号（U+20A9）は完全に独立したコードポイントです。Windows が内部でパスを処理する際、0x5C は常にバックスラッシュです——パス区切り文字としての役割は一度も変わっていません。

ではなぜ ¥ や ₩ に見えるのでしょうか？

答えはフォントです。システムロケールが日本語または韓国語に設定されている場合、システムフォント（MS Gothic や Malgun Gothic など）は U+005C のグリフをバックスラッシュではなく、円記号やウォン記号としてレンダリングします。

マイクロソフトの Michael Kaplan はブログでこう説明しています：

"日本と韓国のコードページベースのシステムで、それぞれの通貨記号がパス区切り文字として使われてから長い年月が経っており、ユーザーはすでにこの表示に慣れていると考えられています。"

言い換えれば：変えられないのではなく、意図的に変えていないのです。

はい。何を使っているかによります：

そのため、同じ日本語 Windows でも、あるウィンドウでは C:\Users、別のウィンドウでは C:¥Users と表示されることがあります——そして両者は全く同じパスを指しています。

EnvStudio は WinUI 3 で構築され、.NET のネイティブ Unicode サポートを使用しています。そのため、EnvStudio 自体のインターフェースでは通常の \ が表示されます。

しかし、ユーザーが cmd.exe から ¥ を含むパスをコピーして貼り付けた場合、EnvStudio はそのまま受け入れます——Windows は内部的にこのコンテキストでの ¥ が \ であることを認識しており、パスの解決は正しく行われます。

最終的に、特別な処理はしないことにしました。理由はシンプルです：日本や韓国のユーザーはおそらくこの表示に慣れています。勝手に ¥ を \ に置き換えると、ローカルユーザーが逆に混乱するかもしれません——「このパスはシステムで見えるものと違う、間違っているのでは？」

時には、「何もしない」ことが最善の修正なのです。

もしあなたが開発者で、国際化テスト中に初めて日本語や韓国語のシステムで C:¥Users を見て驚いたのなら、この記事が「存在しないバグを追う時間」を節約する助けになれば幸いです。