Quando os caracteres aparecem e nada faz sentido
Você abre um arquivo e encontra isso: 《㎚ペールドãƒåŠ å‹•æ•°ã‚'実装ã™ã€‚A휜リーãŠãƒ†ã‚¹ãƒãƒ»ãƒªãƒ¼ã•ãƒ¼ã©ãƒ•ãƒ¼ãƒ«ãƒ‰. A휜リーãŠãƒ†ã‚¹ãƒãƒ»ãƒªãƒ¼ã•ãƒ¼ã©ãƒ•ãƒ¼ãƒ«ãƒ‰. Você não consegue ler nada. Isso é mais comum do que parece acontecer. O problema principal não é o arquivo em si. É a forma como os bytes são interpretados. Um arquivo UTF-8 sendo lido como ISO-8859-1 ou Windows-1252 produz exatamente esse tipo de sujeira visual. Acontece com frequência em servidores rodando scripts antigos, arquivos exportados de plataformas que não especificam encoding, e bancos de dados que foram configurados com collation errada desde o início.
Como identificar e corrigir personagens estranhos na prática
A primeira coisa que eu faço é verificar o encoding real do arquivo. Ferramentas como o comando `file` no Linux (`file -bi nome-do-arquivo`) ou o Notepad++ com "Encoding" visível já resolvem 80% dos casos. Mas às vezes o arquivo foi corrompido de forma que o encoding correto se perdeu completamente, e aí o problema fica mais chato. Uma vez, processei um dump de banco de dados SQL de uma aplicação legado que tinha sido migrado três vezes. O resultado eram colunas inteiras de personagens estranhos, variando entre Mojibake japonês e ruína latino-americana no mesmo arquivo. O encoding real era UTF-8, mas partes do arquivo tinham sido salvas em ISO-8859-1 por um script mal escrito durante uma das migrações. A solução foi um script Python que detectava os padrões de bytes, separava os segmentos por encoding e reconvertia cada parte individualmente antes de reconstruir o arquivo. Levei cerca de quatro horas porque o volume era grande, mas funcionou.
Para o caso básico, onde o arquivo todo está num encoding errado, o processo é mais direto: Ler o arquivo como bytes brutos. Converter de volta para a string correta. Escrever com o encoding apropriado. Em Python, isso seria algo como ler com `encoding='latin1'`, depois reescrever com `encoding='utf-8'`. Em Bash, o comando `iconv` faz isso em uma linha: `iconv -f ISO-8859-1 -t UTF-8 entrada.txt > saida.txt`.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O detalhe que poucos mencionam é que nem sempre o encoding errado é óbvio. Characters como ç, ã, õ, é, á aparecem corrompidos de formas diferentes dependendo da combinação errada. Se você vê sequências que parecem começar com C3 ou C2, é praticamente certo que é UTF-8 sendo interpretado como Latin-1. Se vê caracteres que parecem katakana japonês, também é quase sempre o mesmo problema: UTF-8 mal interpretado. Outro cenário frequente acontece com ferramentas de importação. Planilhas do Excel salvas como CSV mantêm o encoding como ANSI (que no Brasil geralmente é Windows-1252). Quando essas planilhas são processadas por scripts Python ou PHP que assumem UTF-8 por padrão, os acentos viram personajes estranhos instantaneamente. A correção é simples mas esquecida: especificar o encoding na leitura. `pd.read_csv('arquivo.csv', encoding='cp1252')` no pandas, ou `fopen('arquivo.csv', 'r', null, 'ISO-8859-1')` no PHP.
Se o problema é no banco de dados, a coisa fica mais séria. Colunas que já foram salvas comencoding errado não podem ser corrigidas apenas mudando a collation. Você precisa reimportar os dados. O procedimento padrão é: criar uma tabela temporária com encoding correto, usar uma conversão explícita durante o INSERT, e só depois trocar as tabelas. Em MySQL, `ALTER TABLE nome CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci` funciona para colunas que ainda têm dados recuperáveis, mas se os dados já estão corrompidos na tabela, esse comando só piora. Um ponto que causa confusão constante é a diferença entre UTF-8 e UTF-8mb4 no MySQL. UTF-8 padrão no MySQL suporta apenas até 3 bytes por character. Emojis e caracteres Unicode mais recentes precisam de 4 bytes. Se você tem uma aplicação que precisa lidar com emojis ou caracteres asiáticos e usa UTF-8 (não mb4), esses caracteres simplesmente não entram no banco. Aparecem como interrogações ou são truncados. A correção émigration para utf8mb4 em todas as camadas: connection, table, column.
Quanto a ferramentas úteis, além do iconv e dos conversores embutidos nas linguagens, existe o `recode` no Unix que lida com uma gama maior de encodings do que o iconv. Para quem trabalha muito com isso no dia a dia, o `uchardet` é interessante porque tenta detectar automaticamente o encoding de um arquivo. O problema é que a detecção automática não é 100% confiável, especialmente com textos curtos ou mistos. Use como orientação, não como decisão final. Para quem está lidando com personagens estranhos em arquivos de configuração, logs ou saída de terminal, uma solução rápida é configurar o ambiente todo para UTF-8. No Linux, adicionar `export LANG=pt_BR.UTF-8` e `export LC_ALL=pt_BR.UTF-8` no `.bashrc` resolve muitos problemas de exibição. No Windows, mudar a codificação da página de código no prompt de comando com `chcp 65001` ajuda, mas o PowerShell geralmente já lida melhor com Unicode nativamente.
O que menos funciona é tentar corrigir personagens estranhos usando substituição manual ou busca e substituição em editor de texto. Você vai perder tempo e provavelmente vai deixar passar alguns casos. A correção deve ser no nível do byte, não no nível do caractere exibido.
