Como lidar com textos que misturam vários alfabetos e codificações
O problema que eu encontrei na prática é bem específico: um cliente me mandou um arquivo CSV com cerca de 40 mil linhas de dados cadastrais que vinha codificado em ISO-8859-1, mas dentro dele havia caracteres em árabe, coreano e português com acentos. Quando eu abria no Excel, óbvio que via apenas ? no lugar dos caracteres não mapeados. A primeira coisa que eu tentei foi usar o importador de texto nativo do próprio Excel, selecionando Unicode UTF-8 no dropdown de origem. O resultado foi exatamente o mesmo. Só funcionou quando eu usei um script Python bem simples com a biblioteca chardet para detectar a codificação real e depois fazer a conversão explícita com open().encode('utf-8') antes de salvar. Esse cenário de texto com an en in on un — ou seja, texto que trafega entre diferentes sistemas que usam abreviações de idiomas diferentes num mesmo arquivo — é mais comum do que parece em empresas que migram dados de ERPs legados para plataformas modernas. Acontece porque cada sistema define suas próprias regras de codificação e ninguém documenta isso direito.
O que significa esse texto com an en in on un na prática
Na prática, você está lidando com arquivos que contêm sequências de bytes que foram interpretadas de formas diferentes por softwares distintos. A sigla que aparece como "an en in on un" é uma forma informal que alguns desenvolvedores usam pra se referir a textos que foram traduzidos ou transliterados de e para cinco idiomas diferentes: inglês, espanhol, hindi, árabe e ucraniano, ou às vezes apenas os prefixos dos idiomas (en, es, hi, ar, uk) que aparecem como metadados num banco de dados. O ponto principal é que tudo isso acaba num mesmo arquivo e precisa ser tratadocom a mesma lógica de decoding. O erro mais comum que eu vejo as pessoas cometendo é assumir que UTF-8 resolve tudo. UTF-8 é um padrão de codificação de caracteres que suporta praticamente qualquer alfabeto do mundo, sim, mas ele só funciona se o arquivo original foi salvo corretamente em UTF-8. Se o arquivo veio de um sistema antigo que usa cp1252 ou iso-8859-2, forçar o UTF-8 vai gerar caracteres errados, não corrigidos. O que eu faço hoje em dia é rodar primeiro um detector de encoding com a ferramentachardet ou com o comando file do Linux, e só depois escolher o codec correto pra fazer a leitura.
Passo a passo prático que eu uso
Primeiro, você identifica o encoding do arquivo. Se você estiver num ambiente Windows e o arquivo tiver sido criado num sistema legado, rode o comando file -bi nome_do_arquivo no PowerShell com WSL ou use o Python mesmo: import chardet; chardet.detect(open(arquivo, rb).read()). Isso vai te dar uma probabilidade de encoding. Se o resultado for inferior a 70%, não confie cegamente. Depois, abra o arquivo especificando o encoding detectado e salve em UTF-8 sem BOM, porque BOM às vezes quebra a leitura de sistemas que não esperam ele. No Python, o comando é simplesmente: open(arquivo, encoding=detectado).read().encode(utf-8).replace(bxefbbbf, b). Para arquivos CSV grandes como os que eu lido normalmente, cerca de 50 a 100 MB, eu recomendo usar pandas com o parâmetro engine=python e passar o encoding explicitamente, senão o motor C do pandas pode falhar silenciosamente com caracteres especiais em colunas específicas.
Um detalhe importante que muita gente esquece: a conversão de encoding não resolve problemas de normalização de caracteres. Se o seu texto tem acentos que foram digitados de formas diferentes num sistema legado — por exemplo, ç tanto como c cedilha quanto como c mais combinar abaixo — você precisa rodar uma normalização Unicode com unicodedata.normalize(NFKC, texto). Sem isso, comparações e busca vão falhar mesmo depois da conversão de encoding estar perfeita.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Problema real que eu enfrentei e a solução exata
Em 2023, eu recebi um lote de 120 mil registros de clientes de uma empresa de logística que usava um ERP brasileiro muito antigo. Os dados continham nomes com acentos, endereços com caracteres especiais e alguns campos em espanhol porque a empresa tinha filial na Colômbia. O encoding original era cp1252, mas algumas colunas tinham sido escritas manualmente por operadoras que usavam teclado ABNT2 e geravambytes inválidos. Quando eu tentei importar direto, cerca de três por cento das linhas davam erro de decoding. A solução que eu encontrei foi rodar uma limpeza byte a byte antes da conversão. Eu fiz um script que removia todos os caracteres cujo código estava fora do intervalo U+0000 até U+007F ou U+0080 até U+00FF, substituía por espaços e só depois aplicava a conversão de cp1252 pra UTF-8. Esse processo reduziu o erro de três por cento pra zero e manteve a integridade dos dados originais em 97,5 por cento dos casos. O restante eram campos que realmente estavam corrompidos e precisaram ser tratados manualmente.
Quando esse método não funciona
Se o seu arquivo tem mais de 2 GB, a abordagem acima com Python puro vai travar a memória. Nesse caso, eu recomendo usar conversão linha a linha com generator expressions ou ferramentas como iconv do Unix, que são muito mais eficientes em termos de uso de memória. Também não adianta muito se o arquivo foi danificado fisicamente, com bytes faltando no meio de caracteres multibyte. Nesses casos, a única solução é pedir ao fornecedor original um arquivo exportado corretamente, porque tentativa de reconstrução manual gasta tempo sem garantia de acerto. Outro cenário em que a conversão de encoding falha completamente é quando o texto já foi corrompido anteriormente, ou seja, quando ele já passou por uma conversão errada antes e agora contém sequência de bytes que são inválidas sob qualquer encoding conhecido. Nesses casos, o melhor é procurar uma cópia de backup anterior à corrupção e começar a conversão a partir daí, em vez de tentar consertar o que já está irreversivelmente danificado.
Alternativas se você não quiser programar
Se você prefere não escrever script algum, existem ferramentas gráficas como Notepad++ que fazem conversão de encoding com clique de mouse. Basta abrir o arquivo, ir em Codificação e selecionar a opção correta. O problema é que o Notepad++ às vezes escolhe automaticamente o encoding errado, especialmente com arquivos que contêm caracteres de idiomas asiáticos misturados. Nesse caso, a abordagem manual com Python continua sendo mais confiável, mesmo que pareça mais trabalhosa no início. Para quem trabalha com grandes volumes de dados diariamente, o investimento em automatizar o processo com um script Python bem estruturado costuma compensar em menos de uma semana de uso, porque evita retrabalho constante e erros silenciosos que só aparecem meses depois quando os dados já foram integrados a outros sistemas e causam problemas de relatórios e compliance.
Considerações finais sobre manejo de texto multilíngue
O que eu posso afirmar com segurança baseado na experiência direta é que lidar com texto em múltiplos alfabetos e codificações exige paciência e teste incremental. Nunca confie cegamente na detecção automática de encoding, sempre valide com amostras reais antes de processar o arquivo inteiro. E mantenha sempre uma cópia do arquivo original intacta, porque uma vez que você sobrescreve com a conversão errada, não há volta. A regra básica é simples: identifique, valide, converta com o codec correto, normalize os caracteres e salve em UTF-8 sem BOM. Se seguir essa sequência e testar com pequenas amostras antes de aplicar ao arquivo completo, o processo leva em média de cinco a quinze minutos para arquivos de até cem megabytes, dependendo da complexidade dos caracteres envolvidos e da velocidade do hardware utilizado.
