Cuando vi las rutas japonesas y coreanas en EnvStudio, pensé que era un bug
2026-05-15
Etiquetas: Windows · EnvStudio · Diario de desarrollo
Después de completar la internacionalización en 10 idiomas para EnvStudio, comencé a probar en diferentes entornos de idioma. Todo iba bien — hasta que vi el valor de la variable de entorno PATH en sistemas japoneses y coreanos.
Espera, ¿por qué el separador de ruta se convirtió en moneda?
En un sistema en inglés, PATH se ve así:
C:\Users\Name\AppData\Local\ProgramsEn un sistema en japonés, se convierte en:
C:¥Users¥Name¥AppData¥Local¥ProgramsEn un sistema en coreano:
C:₩Users₩Name₩AppData¥Local¥Programs¿¥ (Yen) y ₩ (Won)?? Mi primera reacción: mi código tiene un bug al mostrar las rutas.
Después de revisar todo con cuidado, EnvStudio no tiene ninguna lógica de procesamiento de rutas que modifique estos caracteres. El valor de PATH se lee tal cual del registro de Windows. Es decir, el sistema me lo estaba entregando así.
No es un bug — es un "rasgo heredado" de Windows con décadas de antigüedad
Tras investigar un poco, descubrí que este comportamiento existe desde hace décadas y continúa en Windows 11.
0x5C: un byte, tres caras
La historia se remonta a la codificación de caracteres. En ASCII, la barra invertida \ tiene el valor de byte 0x5C. Pero en los conjuntos de caracteres japonés y coreano, este byte se asignó a otros caracteres:
| Codificación | Idioma | 0x5C se muestra como |
|---|---|---|
| CP1252 | Occidental | \ Barra invertida |
| CP932 | Japonés (Shift-JIS) | ¥ Signo de Yen |
| CP949 | Coreano | ₩ Signo de Won |
| CP936 | Chino simplificado (GBK) | \ Barra invertida |
| CP950 | Chino tradicional (Big5) | \ Barra invertida |
Esta asignación se remonta a JIS X 0201 (Estándar Industrial Japonés) de los años 70. Con un espacio de codificación de 7 bits limitado, 0x5C se asignó al signo de yen. Shift-JIS heredó esto, y la codificación coreana siguió un camino similar.
¿Es un problema de codificación o de fuente?
En Unicode, la barra invertida (U+005C), el signo de yen (U+00A5) y el signo de won (U+20A9) son tres puntos de código completamente independientes. Cuando Windows procesa rutas internamente, 0x5C siempre es la barra invertida — es el separador de ruta, y eso nunca ha cambiado.
Entonces, ¿por qué se ve como ¥ y ₩?
La respuesta son las fuentes. Cuando la configuración regional del sistema está en japonés o coreano, las fuentes del sistema (como MS Gothic, Malgun Gothic) renderizan el glifo en U+005C como símbolo de yen o won en lugar de una barra invertida.
Michael Kaplan de Microsoft lo explicó así en una entrada de blog:
"Después de muchos años de sistemas basados en páginas de códigos en Japón y Corea usando sus respectivos símbolos monetarios como separadores de ruta, se cree que los clientes simplemente se han acostumbrado a esta apariencia."
En otras palabras: no es que no se pueda cambiar — es que deliberadamente no se cambia.
¿Se puede seguir viendo esto en 2026?
Sí. Depende de qué estés usando:
- cmd.exe: Sigue mostrando
¥/₩ - Aplicaciones Win32 antiguas: Siguen mostrando
¥/₩ - Windows Terminal + fuentes modernas (Cascadia Code, etc.): Muestra
\ - Aplicaciones WinUI 3 / UWP: Depende de la fuente
Así que en un mismo Windows japonés, puedes ver C:\Users en una ventana y C:¥Users en otra — y ambas apuntan exactamente a la misma ruta.
De vuelta a EnvStudio: ¿hay que "corregirlo"?
EnvStudio está construido con WinUI 3 y utiliza el soporte Unicode nativo de .NET. Así que la interfaz de EnvStudio muestra el \ normal.
Pero si un usuario copia una ruta con ¥ desde cmd.exe y la pega, EnvStudio la acepta tal cual — porque Windows sabe internamente que ¥ en este contexto es \, y la resolución de ruta funciona correctamente.
Al final, decidí no hacer ningún tratamiento especial. La razón es simple: los usuarios japoneses y coreanos probablemente están acostumbrados a esta forma de mostrarlo. Si yo reemplazara ¥ por \ por mi cuenta, podría confundir a los usuarios locales — "esta ruta se ve diferente a lo que veo en mi sistema, ¿está mal?"
A veces, "no hacer nada" es la mejor solución.
Si eres desarrollador y es la primera vez que ves C:¥Users en un sistema japonés o coreano durante pruebas de internacionalización, espero que este artículo te ahorre tiempo persiguiendo un bug que no existe.