Windows Script Host e UTF-8

Olá a todos! Primeiramente, feliz 2007. Que seja bom pra todos nós. Estive fora um tempo para as festas de fim de ano, e voltei agora. Dentre as minhas metas para as férias ainda estão fazer um curso para aprimorar meu inglês e estudar Estatística. Logo, começamos o ano bem... e sem descanso. Para começar, encontrei a solução para um problema antigo, daqueles que eu e várias pessoas já passaram e não souberam explicar como. Trata-se da questão entre o Windows Script Host e o UTF-8. Já cheguei a postar sobre ele aqui mesmo. Até 10 minutos atrás, sempre que alguém me perguntava assim: "Vinicius, estou encontrando, em alguns arquivos, um erro estranho, na linha 0, caractere 0. Já cansei de olhar e não encontrei nada..." eu respondia usando a resposta mais simples, que encontrei experimentalmente na faculdade: "esse é um problema do Windows Script Host, que não consegue trabalhar com arquivos UTF-8". Com o que eu acabo de ler, agora sei que isso é meia verdade. O problema é mais embaixo e tem a ver diretamente com a forma como os caracteres são codificados. Vamos primeiro à uma breve (e sem muitos detalhes) explicação sobre o que é essa codificação. Tome, por exemplo, um arquivo de texto simples qualquer. Como os dados são armazenados em disco? Nos primórdios da computação, cada caractere tinha um código numérico associado, que era usado diretamente no disco rígido (uma vez que tudo que um computador faz é manipular números... nada mais que isso). A forma como esses caracteres são transformados para números e vice-versa recebe o nome de codificação (encoding, em Inglês). A famosa tabela ASCII é um exemplo disso. Para quem fala e escreve em inglês, os caracteres da tabela ASCII dão conta de quase todas as possibilidades. Ela tem 128 caracteres, o que representa quase tudo nesse idioma. No entanto, para o Português e vários outros idiomas, ela não é totalmente adequada, e falta espaço para alguns caracteres, como as vogais acentuadas, por exemplo. Para isso foram criados outras codificações, como o UTF-8. A idéia básica é usar de um a quatro bytes para representar os caracteres, o que garante muito mais possibilidades. Mais detalhes podem ser encontrados aqui. Até aqui eu sabia, e boa parte de vocês também. O que há de novo é o fato de como o Windows Script Host e o bloco de notas (curioso, não?) trabalham. Tudo começou quando eu percebi que os arquivos gerados no Bloco de Notas algumas raras vezes continham falhas nos 3 ou 4 primeiros caracteres. Resolvi buscar isso e encontrei em um site a explicação sobre um suposto Bug no Bloco de Notas (na Internet também cheguei a ver isso como um Ovo de Páscoa ou Easter Egg, aquelas mensagens escondidas no meio do código-fonte dos programas pelos próprios programadores). O site explica, dentre outras coisas, que não se trata de uma falha no Bloco de Notas, mas sim um detalhes (daqueles que você lê na seção Remarks da documentação) sobre uma função da Win32 API, que descobre qual a codificação de um arquivo texto. Esse detalhe faz com que o Bloco de Notas se engane ao tentar abrir um arquivo "pensa" que é Unicode e mostra caracteres errados. A propósito: a "falha" no Bloco de Notas funciona assim: 1. Abra o Bloco de Notas. 2. Digite "This app can break", sem aspas. Na verdade, vale qualquer texto de exatas 4 palavras, sendo cada uma delas com 4, 3, 3 e 5 caracteres, respectivamente. Vale "This API can break" ou "AAAA BBB CCC DDDDD"... qualquer coisa nesse padrão. 3. Salve o arquivo e feche o bloco de notas. 4. Abra o arquivo novamente. Você vai ver vários caracteres estranhos (quadradinhos, nesse caso) ao invés do texto digitado. Aí você se pergunta: e o WSH? E os scripts? Isso aqui não era um blog sobre scripting? É simples. Da mesma forma que o Bloco de Notas se engana ao abrir arquivos, acredito que o WSH também se enrole. Isso explica o fato dele abrir arquivos Unicode e ANSI, mas não os UTF-8. Procurei por documentos oficiais na MS e nos Newsgroups e não encontrei nada especificamente sobre esse problema do WSH x UTF-8. Continuo procurando a resposta pra isso... e aparentemente, esta é a que mais se parece com a verdadeira. Até mais e bom 2007! Vinicius

Categorias dessa postagem:

Comentários

Anônimo : Fiz o teste e não ocorreu o problema. Acho que já resolveram este fato. [9/10/07 13:11 - link]

Vinicius Canto : Olá Arthur,

O Notepad no Windows Vista realmente não tem mais esse bug, provavelmente por usar outra API para identificar se os arquivos são UTF-8 ou não. No entanto, o WSH ainda não abre arquivos UTF-8, acusando o mesmo erro na linha 0 col 0.

[]s,

Vinicius [28/10/07 10:33 - link]