Conversor de Codificação e Corretor de Mojibake

Respostas rápidas

O que é mojibake?

// The mistake, in three lines of JavaScript
const bytes = new TextEncoder().encode('测试');   // UTF-8: E6 B5 8B E8 AF 95
new TextDecoder('gbk').decode(bytes);            // '娴嬭瘯'  ← mojibake
new TextDecoder('windows-1252').decode(bytes);   // '测试'  ← same bytes, other mistake

O que esta ferramenta faz

Exemplos resolvidos

娴嬭瘯

测试

测试

测试

B2 E2 CA D4

测试

鏁版嵁搴�

(apenas parcial)

Como usar esta ferramenta

1. 1

   Cole o texto corrompido

   Jogue direto na caixa — não precisa identificar a codificação antes. Um fragmento curto basta; uma dúzia de caracteres costuma fixar a cadeia.

2. 2

   Leia o primeiro candidato e o selo dele

   Exata significa que a cadeia volta à sua entrada sem diferença nenhuma. Parcial significa que não volta, então trate o resultado como pista.

3. 3

   Confira a cadeia de codificação

   Cada candidato mostra em qual codificação o texto foi realmente escrito e qual o leu errado. Isso diz o que corrigir lá na origem, não só o que o texto dizia.

4. 4

   Inspecione os bytes se precisar

   A segunda seção mostra qualquer texto como bytes em todas as codificações comuns e decodifica hex bruto no sentido inverso. Use para dimensionar colunas ou conferir quadros de protocolo.

Erros que pioram a situação

iconv -f UTF-8 -t GBK correct.txt > broken.txt

# Confirme antes qual é a codificação atual
file -I correct.txt   # charset=utf-8 → nada a converter

ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

-- Passe por um tipo binário para os bytes serem preservados, não reinterpretados
ALTER TABLE t MODIFY c VARBINARY(255);
ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

// Pega o primeiro candidato, diga o selo o que disser
db.update(row.id, candidates[0].text);

// Só grave de volta o que fecha a ida e volta
if (candidates[0].lossless) db.update(row.id, candidates[0].text);

text = raw.decode('utf-8').encode('gbk').decode('utf-8')

# Decodifique uma vez na fronteira, com a codificação que o arquivo realmente usa
with open(path, encoding='gbk') as f:
    text = f.read()

Quando você precisa disto

Uma migração de banco de dados gerou lixo

Tabelas MySQL legadas declaradas como latin1 mas contendo bytes UTF-8 são, isoladamente, a origem mais comum. Cole aqui uma linha corrompida para confirmar a cadeia real antes de escrever o ALTER TABLE — rodar a conversão na direção errada transforma um problema recuperável num problema permanente.

Um CSV aberto no Excel mostra bobagem

O Excel no Windows ainda assume a página de código do sistema para arquivos CSV sem BOM, então exportações UTF-8 saem como mojibake. Confirme a cadeia aqui e depois reexporte com BOM ou importe pelo assistente de texto com a codificação definida explicitamente.

Arquivos de log de um serviço legado

Aplicações escritas contra GBK ou Shift_JIS gravam logs nessas codificações, e os agregadores de log modernos leem tudo como UTF-8. Cole uma linha para recuperá-la — e, como nada é enviado para lugar nenhum, você pode fazer isso com logs de produção.

Nomes de arquivo quebrados por um arquivo ZIP

O formato ZIP não tem campo de codificação, então pacotes criados em Windows chinês ou japonês carregam nomes de arquivo em GBK ou Shift_JIS que as ferramentas Unix leem como UTF-8. Recupere os nomes reais aqui antes de renomear qualquer coisa.

Dimensionar uma coluna de banco de dados

A visão de bytes mostra o mesmo texto em todas as codificações de uma vez. Um caractere chinês ocupa 3 bytes em UTF-8 e 2 em GBK, e é exatamente esse tipo de diferença que transforma um VARCHAR(50) num bug de truncamento.

Como o mojibake acontece

Os bytes sobrevivem, o significado não

Codificar mapeia caracteres para bytes; decodificar mapeia bytes de volta. Mojibake é uma decodificação com o mapa errado. Os bytes nunca foram danificados, e é por isso que rodar a decodificação errada ao contrário recupera o original exatamente — desde que a decodificação errada não tenha descartado nada.

Por que o texto CJK sofre mais

O ASCII ocupa 0x00–0x7F e toda codificação comum concorda quanto a ele, então texto em inglês passa ileso. Chinês, japonês e coreano precisam de sequências multibyte, e as codificações discordam sobre como agrupá-las. O UTF-8 usa três bytes por caractere chinês; o GBK usa dois. Entregue bytes UTF-8 a um decodificador GBK e o agrupamento se desloca, produzindo uma quantidade diferente de caracteres diferentes.

O teste de ida e volta

Para cada cadeia candidata, a ferramenta recodifica o texto recuperado com a primeira codificação e o redecodifica com a segunda. Se isso reproduz a entrada exatamente, a cadeia explica cada caractere e o candidato é marcado como Exata. Candidatos que falham no teste continuam sendo exibidos, porque uma recuperação parcial muitas vezes identifica o texto mesmo sem conseguir reproduzi-lo.

De onde vêm as tabelas de codificação

O TextDecoder do navegador fornece as tabelas. Codificar no sentido inverso é mais complicado, porque o TextEncoder só suporta UTF-8 — então a ferramenta constrói um mapa reverso percorrendo o espaço de bytes e perguntando ao decodificador o que cada sequência significa. O mapeamento fica, portanto, sempre coerente com o comportamento do próprio navegador, e nenhuma tabela de consulta é enviada ao seu dispositivo.

A heurística de ordenação e seus limites

Além do teste de ida e volta, os candidatos recebem uma pontuação por quanto do texto é formado por caracteres chineses comuns (aqueles cujo byte-líder GBK cai em 0xB0–0xF7), menos penalidades por caracteres de substituição, katakana de meia largura e caracteres de controle. Katakana de meia largura é um sinal forte de Shift_JIS, porque texto japonês normal quase nunca o usa. Isto é uma heurística: ela desempata, não estabelece a verdade.

Como impedir que aconteça de novo

Corrija a origem, não só a string

A cadeia de codificação mostrada sob cada candidato diz qual componente está mal configurado. Reparar o texto sem corrigir o charset da conexão, o leitor de arquivos ou a configuração de exportação significa fazer tudo de novo amanhã, com dados novos.

Confirme a direção antes de converter um arquivo inteiro

Passe uma linha representativa por esta página primeiro. Converter na direção errada pode produzir caracteres de substituição e, ao contrário do engano original, esse passo não é reversível.

Defina a codificação explicitamente em todo lugar

Charset da conexão do banco, Content-Type do HTTP, chamadas de abertura de arquivo, exportações de CSV. Todo ponto que assume "a codificação do sistema" é um ponto onde o mesmo bug volta quando o código muda de máquina.

Prefira utf8mb4 a utf8 no MySQL

O utf8 do MySQL guarda no máximo três bytes por caractere, então emojis e alguns caracteres chineses mais raros são truncados em silêncio. O utf8mb4 é UTF-8 de verdade. Essa falha é diferente do mojibake e a ferramenta de recuperação não ajuda, porque aí os bytes realmente se foram.

Guarde os bytes originais até verificar a correção

Faça uma cópia antes de converter qualquer coisa. Enquanto os bytes originais existirem, toda decodificação errada é reversível — depois que forem sobrescritos por caracteres de substituição, nenhuma ferramenta desta página nem de lugar nenhum os traz de volta.

Perguntas frequentes