Quand j'ai vu les chemins japonais et coréen dans EnvStudio, j'ai cru à un bug
2026-05-15
Tags : Windows · EnvStudio · Journal de dev
Après avoir terminé l'internationalisation en 10 langues d'EnvStudio, j'ai commencé les tests dans différents environnements linguistiques. Tout se passait bien — jusqu'à ce que je regarde la variable d'environnement PATH sur des systèmes japonais et coréen.
Attendez, pourquoi le séparateur de chemin est devenu une devise ?
Sur un système anglais, PATH ressemble à ça :
C:\Users\Name\AppData\Local\ProgramsSur un système japonais, ça devient :
C:¥Users¥Name¥AppData¥Local¥ProgramsSur un système coréen :
C:₩Users₩Name₩AppData¥Local¥Programs¥ (Yen) et ₩ (Won) ?? Ma première réaction : mon code a un bug dans l'affichage des chemins.
Après vérification approfondie, EnvStudio n'a aucune logique de traitement de chemin qui modifierait ces caractères. La valeur de PATH est lue telle quelle depuis le registre Windows. En d'autres termes, le système me fournit ces caractères.
Pas un bug — un « héritage historique » de Windows vieux de plusieurs décennies
Après quelques recherches, j'ai découvert que ce comportement existe depuis des décennies et perdure sous Windows 11.
0x5C : un octet, trois visages
L'histoire remonte à l'encodage des caractères. En ASCII, l'antislash \ a la valeur d'octet 0x5C. Mais dans les jeux de caractères japonais et coréen, cet octet a été attribué à d'autres caractères :
| Encodage | Langue | 0x5C affiché comme |
|---|---|---|
| CP1252 | Occidental | \ Antislash |
| CP932 | Japonais (Shift-JIS) | ¥ Signe Yen |
| CP949 | Coréen | ₩ Signe Won |
| CP936 | Chinois simplifié (GBK) | \ Antislash |
| CP950 | Chinois traditionnel (Big5) | \ Antislash |
Ce remplacement remonte à JIS X 0201 (norme industrielle japonaise) des années 1970. Avec un espace d'encodage 7 bits limité, 0x5C a été attribué au signe yen. Shift-JIS a hérité de cette convention, et l'encodage coréen a suivi un chemin similaire.
Problème d'encodage ou problème de police ?
En Unicode, l'antislash (U+005C), le signe yen (U+00A5) et le signe won (U+20A9) sont trois points de code complètement séparés. Quand Windows traite les chemins en interne, 0x5C est toujours l'antislash — c'est le séparateur de chemin, et ça n'a jamais changé.
Alors pourquoi apparaît-il comme ¥ et ₩ ?
La réponse, ce sont les polices. Quand les paramètres régionaux sont définis sur japonais ou coréen, les polices système (comme MS Gothic, Malgun Gothic) affichent le glyphe à U+005C comme symbole yen ou won au lieu d'un antislash.
Michael Kaplan de Microsoft l'a expliqué ainsi dans un article de blog :
« Après de nombreuses années de systèmes basés sur des pages de code au Japon et en Corée utilisant leurs symboles monétaires respectifs comme séparateurs de chemin, on considère que les clients se sont simplement habitués à cet affichage. »
En d'autres termes : ce n'est pas qu'on ne peut pas le changer — c'est qu'on ne le change pas exprès.
Peut-on encore voir ça en 2026 ?
Oui. Cela dépend de ce que vous utilisez :
- cmd.exe : Affiche toujours
¥/₩ - Applications Win32 anciennes : Affichent toujours
¥/₩ - Windows Terminal + polices modernes (Cascadia Code, etc.) : Affiche
\ - Applications WinUI 3 / UWP : Dépend de la police
Sur un même Windows japonais, vous pouvez donc voir C:\Users dans une fenêtre et C:¥Users dans une autre — et les deux pointent vers exactement le même chemin.
Retour à EnvStudio : faut-il « corriger » ?
EnvStudio est construit avec WinUI 3 et utilise le support Unicode natif de .NET. L'interface d'EnvStudio affiche donc le \ normal.
Mais si un utilisateur copie un chemin contenant ¥ depuis cmd.exe et le colle, EnvStudio l'accepte tel quel — car Windows sait en interne que ¥ dans ce contexte est \, et la résolution de chemin fonctionne correctement.
Finalement, j'ai décidé de ne rien faire de spécial. La raison est simple : les utilisateurs japonais et coréen sont probablement habitués à cet affichage. Si je remplaçais ¥ par \ de mon propre chef, cela pourrait confondre les utilisateurs locaux — « ce chemin est différent de ce que je vois sur mon système, c'est une erreur ? »
Parfois, « ne rien faire » est la meilleure correction.
Si vous êtes développeur et que vous découvrez C:¥Users pour la première fois sur un système japonais ou coréen lors de tests d'internationalisation, j'espère que cet article vous fera gagner du temps en évitant de traquer un bug inexistant.