Quando vi os caminhos japonês e coreano no EnvStudio, achei que era um bug
2026-05-15
Etiquetas: Windows · EnvStudio · Diário de dev
Depois de concluir a internacionalização em 10 idiomas para o EnvStudio, comecei a testar em diferentes ambientes de idioma. Tudo estava correndo bem — até eu ver o valor da variável de ambiente PATH em sistemas japonês e coreano.
Espera, por que o separador de caminho virou moeda?
Em um sistema em inglês, PATH se parece com isso:
C:\Users\Name\AppData\Local\ProgramsEm um sistema em japonês, vira:
C:¥Users¥Name¥AppData¥Local¥ProgramsEm um sistema em coreano:
C:₩Users₩Name₩AppData¥Local¥Programs¥ (Iene) e ₩ (Won)?? Minha primeira reação: meu código tem um bug na exibição de caminhos.
Depois de verificar cuidadosamente, o EnvStudio não tem nenhuma lógica de processamento de caminho que modificasse esses caracteres. O valor de PATH é lido diretamente do registro do Windows. Ou seja, o sistema me entregou assim.
Não é um bug — é uma "herança histórica" do Windows com décadas de idade
Após algumas pesquisas, descobri que esse comportamento existe há décadas e continua no Windows 11.
0x5C: um byte, três faces
A história começa com a codificação de caracteres. No ASCII, a barra invertida \ tem o valor de byte 0x5C. Mas nos conjuntos de caracteres japonês e coreano, esse byte foi atribuído a outros caracteres:
| Codificação | Idioma | 0x5C exibido como |
|---|---|---|
| CP1252 | Ocidental | \ Barra invertida |
| CP932 | Japonês (Shift-JIS) | ¥ Sinal de Iene |
| CP949 | Coreano | ₩ Sinal de Won |
| CP936 | Chinês simplificado (GBK) | \ Barra invertida |
| CP950 | Chinês tradicional (Big5) | \ Barra invertida |
Esse mapeamento remonta à JIS X 0201 (Padrão Industrial Japonês) dos anos 1970. Com espaço limitado de codificação de 7 bits, 0x5C foi atribuído ao sinal de iene. O Shift-JIS herdou isso, e a codificação coreana seguiu um caminho similar.
Problema de codificação ou problema de fonte?
No Unicode, a barra invertida (U+005C), o sinal de iene (U+00A5) e o sinal de won (U+20A9) são três code points completamente separados. Quando o Windows processa caminhos internamente, 0x5C é sempre a barra invertida — é o separador de caminho, e isso nunca mudou.
Então por que aparece como ¥ e ₩?
A resposta são as fontes. Quando a localidade do sistema está configurada para japonês ou coreano, as fontes do sistema (como MS Gothic, Malgun Gothic) renderizam o glyph em U+005C como símbolo de iene ou won em vez de barra invertida.
Michael Kaplan da Microsoft explicou assim em um post de blog:
"Após muitos anos de sistemas baseados em code pages no Japão e na Coreia usando seus respectivos símbolos monetários como separadores de caminho, acredita-se que os clientes simplesmente se acostumaram com essa aparência."
Em outras palavras: não é que não possa ser mudado — é que deliberadamente não se muda.
Ainda se vê isso em 2026?
Sim. Depende do que você está usando:
- cmd.exe: Ainda mostra
¥/₩ - Aplicativos Win32 antigos: Ainda mostram
¥/₩ - Windows Terminal + fontes modernas (Cascadia Code, etc.): Mostra
\ - Aplicativos WinUI 3 / UWP: Depende da fonte
Então no mesmo Windows japonês, você pode ver C:\Users em uma janela e C:¥Users em outra — e ambas apontam para exatamente o mesmo caminho.
De volta ao EnvStudio: deve ser "corrigido"?
O EnvStudio é construído com WinUI 3 e usa o suporte Unicode nativo do .NET. Então a interface do EnvStudio exibe o \ normal.
Mas se um usuário copiar um caminho com ¥ do cmd.exe e colar, o EnvStudio aceita como está — porque o Windows sabe internamente que ¥ neste contexto é \, e a resolução do caminho funciona corretamente.
No final, decidi não fazer nenhum tratamento especial. O motivo é simples: usuários japoneses e coreanos provavelmente já estão acostumados com essa exibição. Se eu substituísse ¥ por \ por conta própria, poderia confundir os usuários locais — "esse caminho parece diferente do que vejo no meu sistema, está errado?"
Às vezes, "não fazer nada" é a melhor correção.
Se você é desenvolvedor e está vendo C:¥Users pela primeira vez em um sistema japonês ou coreano durante testes de internacionalização, espero que este artigo te economize o tempo de caçar um bug que não existe.