Als ich japanische und koreanische Pfade in EnvStudio sah, dachte ich an einen Bug
2026-05-15
Tags: Windows · EnvStudio · Entwicklertagebuch
Nachdem die 10-sprachige Internationalisierung für EnvStudio abgeschlossen war, begann ich mit dem Test unter verschiedenen Spracheinstellungen. Alles lief reibungslos — bis ich mir die PATH-Umgebungsvariable auf japanischen und koreanischen Systemen ansah.
Moment, warum wurde das Pfadtrennzeichen zur Währung?
Auf einem englischen System sieht PATH so aus:
C:\Users\Name\AppData\Local\ProgramsAuf einem japanischen System wird daraus:
C:¥Users¥Name¥AppData¥Local¥ProgramsAuf einem koreanischen System:
C:₩Users₩Name₩AppData¥Local¥Programs¥ (Yen) und ₩ (Won)?? Mein erster Gedanke: Mein Code hat einen Bug bei der Pfadanzeige.
Nach sorgfältiger Überprüfung stellte ich fest, dass EnvStudio selbst keine Pfadverarbeitungslogik enthält, die diese Zeichen verändert. Der PATH-Wert wird unverändert aus der Windows-Registry gelesen. Das System liefert die Werte also bereits so.
Kein Bug — ein jahrzehntealtes Windows-"Feature"
Nach einiger Recherche stellte sich heraus, dass dieses Verhalten seit Jahrzehnten existiert und bis heute unter Windows 11 fortbesteht.
0x5C: Ein Byte, drei Gesichter
Die Geschichte beginnt bei der Zeichenkodierung. In ASCII hat der Backslash \ den Bytewert 0x5C. In japanischen und koreanischen Zeichensätzen wurde dieses Byte jedoch anderen Zeichen zugeordnet:
| Kodierung | Sprache | 0x5C wird angezeigt als |
|---|---|---|
| CP1252 | Westlich | \ Backslash |
| CP932 | Japanisch (Shift-JIS) | ¥ Yen-Zeichen |
| CP949 | Koreanisch | ₩ Won-Zeichen |
| CP936 | Vereinfachtes Chinesisch (GBK) | \ Backslash |
| CP950 | Traditionelles Chinesisch (Big5) | \ Backslash |
Diese Zuordnung reicht bis zu JIS X 0201 (Japanischer Industriestandard) aus den 1970er Jahren zurück. Mit begrenztem 7-Bit-Kodierungsraum wurde 0x5C dem Yen-Zeichen zugewiesen. Shift-JIS übernahm dies, und die koreanische Kodierung ging einen ähnlichen Weg.
Kodierungsproblem oder Schriftartenproblem?
In Unicode sind der Backslash (U+005C), das Yen-Zeichen (U+00A5) und das Won-Zeichen (U+20A9) drei völlig separate Codepoints. Wenn Windows intern Pfade verarbeitet, ist 0x5C immer der Backslash — er ist das Pfadtrennzeichen, und das hat sich nie geändert.
Warum also sieht es wie ¥ und ₩ aus?
Die Antwort sind Schriftarten. Wenn das Systemgebietsschema auf Japanisch oder Koreanisch eingestellt ist, rendern die Systemschriftarten (wie MS Gothic, Malgun Gothic) das Glyph an U+005C als Yen- oder Won-Symbol statt als Backslash.
Microsofts Michael Kaplan erklärte es in einem Blogpost so:
"Nach vielen Jahren codepage-basierter Systeme in Japan und Korea, in denen die jeweiligen Währungssymbole als Pfadtrennzeichen verwendet wurden, glaubt man, dass die Kunden sich einfach an diese Darstellung gewöhnt haben."
Mit anderen Worten: Es ist nicht so, dass man es nicht ändern könnte — man tut es absichtlich nicht.
Kann man das 2026 noch sehen?
Ja. Es kommt darauf an, was Sie verwenden:
- cmd.exe: Zeigt immer noch
¥/₩ - Ältere Win32-Anwendungen: Zeigen immer noch
¥/₩ - Windows Terminal + moderne Schriftarten (Cascadia Code usw.): Zeigt
\ - WinUI 3 / UWP-Apps: Hängt von der Schriftart ab
Auf demselben japanischen Windows können Sie also in einem Fenster C:\Users sehen und in einem anderen C:¥Users — und beide zeigen auf denselben Pfad.
Zurück zu EnvStudio: "Reparieren" oder nicht?
EnvStudio ist mit WinUI 3 erstellt und nutzt .NETs native Unicode-Unterstützung. Deshalb zeigt EnvStudios eigene Oberfläche das normale \.
Wenn ein Benutzer jedoch einen Pfad mit ¥ aus cmd.exe kopiert und einfügt, akzeptiert EnvStudio ihn unverändert — da Windows intern weiß, dass ¥ in diesem Kontext \ ist, und die Pfadauflösung korrekt funktioniert.
Am Ende entschied ich mich, keine Sonderbehandlung vorzunehmen. Der Grund ist einfach: Japanische und koreanische Benutzer sind wahrscheinlich an diese Darstellung gewöhnt. Wenn ich ¥ eigenmächtig durch \ ersetzen würde, könnten lokale Benutzer verwirrt werden — "Dieser Pfad sieht anders aus als auf meinem System, ist da was falsch?"
Manchmal ist "Nichts tun" die beste Lösung.
Wenn Sie als Entwickler bei Internationalisierungstests zum ersten Mal C:¥Users auf einem japanischen oder koreanischen System sehen, hoffe ich, dass dieser Artikel Ihnen hilft, Zeit bei der Suche nach einem nicht existierenden Bug zu sparen.