Navegando por aí, acabei esbarrando no blog do meu amigo Marcos Rossow (nossa, quanto tempo!)
E encontrei esse post: JavaScript UTF-8 Decode, com um código tirado daqui: JavaScript utf8_decode.
Tem duas coisas que me incomodam nessa abordagem. A primeira é essa mania que muita gente tem, particularmente programadores PHP, de tratar UTF-8 como um “código alienígena” e ISO-8859-1 como normal e padrão. Alô, ISO-8859-1 é usado por parte do mundo. Não dá para escrever hebraico, mandarim, japonês, árabe ou russo com isso. ISO-8859-1 é uma das diversas tabelas de caracteres que existem mundo afora. E Unicode é a única maneira sensata de escrever um sistema que possa ser usado aqui e na China.
A segunda coisa que me incomoda é a quantidade de código. Não testei profundamente, mas tenho a impressão de que o código abaixo resolve o problema:
function utf8_decode(t){
return decodeURIComponent(escape(t))
}
Melhor usar o charset correto do que ter que usar depois uma POG dessas, né? rs
Hmm… como alguém que já escreveu um utf8_decode antes, eu realmente não tinha pensado nessa sua solução, é criativa 🙂
Ela tem problemas com certos caracteres (se minha conta estiver correta, são apenas os do intervalo U+0400—U+041f), mas nada que seja relevante a quem se limita a ISO-8859-1 ou Windows-1252.
Quanto à necessidade de um utf8_decode, no meu caso ao menos se tratava de conformidade e compatibilidade com o que já existia: a empresa já havia decidido se fixar em ISO-8859-1 anos antes de eu ter entrado, e usava essa codificação sempre que possível. Porém, devido ao IE6 sempre tratar dados recebidos via XMLHttpRequest como UTF-8, quando os sistemas começaram a usar AJAX surgiram esses problemas de sermos forçados a converter certas partes para UTF-8, e por algum motivo que não me recordo agora em certos pontos ocorria a dupla conversão. Tentar reestruturar o framework interno para que isso não ocorresse mais traria muito mais dores de manutenção em todas as dezenas de sistemas que já estavam rodando do que simplesmente resolver isso do lado do cliente. Se eu tivesse poder de decisão, teria padronizado o UTF-8 ali, sem dúvida. 😉