Correção de Mojibake — Conserta Texto Ilegível

Visão geral

Texto ilegível não é dano. São bytes corretos lidos com a tabela errada. 日本語 codificado em UTF-8 são nove bytes; lidos como Windows-1252, esses mesmos nove bytes dão 日本語. Nada foi perdido — a interpretação estava errada, e revertê-la restitui o original exatamente.

Esta ferramenta volta a codificar em bytes o texto que colar, usando a codificação sob a qual ele foi provavelmente mal lido, descodifica esses bytes com cada codificação em que ele poderia realmente estar, e ordena os resultados. O primeiro candidato é o par que produz UTF-8 válido sem caracteres de substituição.

Como usar

1. Cole o texto ilegível.
2. Leia o primeiro candidato, marcado com uma estrela.
3. Se não estiver correto, veja os outros — cada um traz a etiqueta do par que o produziu.

Porque é que o primeiro candidato está normalmente correto

A ordenação não é uma suposição sobre a língua. Assenta numa propriedade estrutural do UTF-8: a codificação declara ela própria o comprimento das suas sequências. Um byte inicial indica quantos bytes de continuação seguem, e cada byte de continuação é identificável como tal. Por isso uma sequência de bytes arbitrária falha a descodificação como UTF-8 quase de imediato, e o descodificador do navegador relata essa falha com caracteres de substituição.

Assim, quando um candidato se descodifica como UTF-8 sem qualquer carácter de substituição, isso é uma prova sólida e não uma preferência — os bytes eram UTF-8 válido desde o início, que é exatamente o que se espera de um texto que estava em UTF-8 antes de algo o ler como Latin-1. Os candidatos são ainda ordenados pela persistência das assinaturas de corrupção no resultado, e um candidato só é oferecido se as reduzir.

Porque é que o texto correto é deixado intacto

Antes de produzir qualquer candidato, a entrada é examinada à procura das assinaturas do texto ilegível: os pares de bytes específicos que as leituras erradas em Latin-1 produzem (à /  / †/ ã e os seus parentes), os caracteres de controlo C1 do intervalo U+0080–U+009F, e os caracteres de substituição U+FFFD.

Um texto sem nenhuma delas é relatado como limpo e nenhum candidato é oferecido. Isto importa porque a transformação é destrutiva quando aplicada a texto correto. Grüße e señor são alemão e espanhol correntes; passe-os por uma reparação que os suponha corrompidos e obtém um resultado sem sentido. Uma ferramenta que oferece sempre candidatos convida precisamente a esse erro.

O que não pode ser recuperado

Se o texto contiver ?, � ou quadrados vazios, os bytes originais desapareceram.

Vale a pena ser preciso na distinção. O texto ilegível preserva os bytes e perde a interpretação, pelo que é reversível. A substituição perde os bytes: quando um conversor encontra um carácter que a sua codificação de destino não consegue representar, escreve uma substituição e descarta o original. Nenhuma ferramenta recupera isso, porque não resta nada para reinterpretar. Se ainda conseguir obter o ficheiro de origem, esse é o único caminho.

A corrupção dupla — corrompido, guardado e corrompido outra vez — é por vezes recuperável aplicando a reparação duas vezes, mas cada passagem agrava qualquer perda e os resultados degradam-se.

De onde vem o texto ilegível

O padrão é quase sempre uma predefinição que nunca foi declarada:

• Um CSV aberto numa folha de cálculo. O Excel no Windows assumiu historicamente a página de código do sistema para os .csv na ausência de BOM UTF-8, e é por isso que ficheiros exportados cheios de acentos abrem ilegíveis. Assim café fica café.
• Uma ligação de base de dados sem conjunto de caracteres definido. Os dados estão guardados corretamente e é a ligação que converte mal, pelo que as mesmas linhas se leem bem por um cliente e mal por outro.
• As linhas de assunto de e-mail. Os cabeçalhos são apenas ASCII, pelo que o não-ASCII viaja como encoded-words da RFC 2047 que nomeiam o seu próprio conjunto de caracteres. Os assuntos em japonês ainda usam ISO-2022-JP com frequência, e um descodificador que assume UTF-8 corrompe-os todos.
• Uma resposta sem charset no seu Content-Type. O navegador adivinha, e a sua suposição depende da configuração regional.
• Um nome de ficheiro antigo num arquivo. O ZIP não tem um campo de conjunto de caracteres fiável, pelo que nomes criados sob uma página de código são lidos sob outra.

Exemplos

• Reparar um CSV importado — cole um campo afetado para identificar o par e volte a importar com a codificação correta, em vez de reparar linhas uma a uma.
• Ler um assunto de e-mail corrompido — para uma mensagem completa, o visualizador .eml descodifica os encoded-words com o conjunto de caracteres que o cabeçalho declara, incluindo ISO-2022-JP, pelo que o assunto se lê corretamente sem qualquer reparação.
• Diagnosticar uma cadeia de processamento — o par que produz a correção diz-lhe onde a conversão está errada. «Escrito em UTF-8, lido em Windows-1252» aponta para uma declaração de charset ausente no lado da leitura, não para um problema dos dados.
• Verificar a saída de um log — um serviço que registra numa codificação e um agregador que lê noutra só produzem texto ilegível nas linhas não ASCII, e é por isso que passa despercebido até aparecer um nome ou uma mensagem de erro de um sistema traduzido.

Observações

Os candidatos são descodificados com o TextDecoder do próprio navegador, pelo que as tabelas são as que a plataforma usa — esta página não inclui nenhuma tabela de codificação. O suporte das codificações multibyte antigas é exigido pelo Encoding Standard e está presente em todos os navegadores atuais.

As codificações cobertas são windows-1252, iso-8859-1, windows-1251 e macintosh do lado da leitura errada, e utf-8, shift_jis, euc-jp, iso-2022-jp, gbk, big5 e euc-kr do lado original. São mostrados até oito candidatos.

Leia sempre o candidato antes de o usar. Numa amostra curta, vários pares podem produzir uma saída plausível, e a verificação estrutural não lhe pode dizer em que língua o texto deveria estar. Tudo acontece no seu navegador — ver a política de privacidade.