Codificação de CSV e o misterioso BOM
O Excel abre um arquivo UTF-8 sem BOM com a página de código antiga do sistema, e “Coração” vira “Coração”. Isso não é um defeito do Excel nem do arquivo: um CSV simplesmente não tem onde dizer em que codificação está.
Um CSV não tem lugar para a codificação
O XML declara a codificação no prólogo, o JSON é por norma sempre UTF-8, o DBF guarda um código no cabeçalho. O CSV não tem nada: é só texto com vírgulas. O programa que lê precisa adivinhar — ou perguntar.
O Excel não pergunta. Ao dar um clique duplo ele usa a página de código ANSI do sistema — windows-1252 em um Windows brasileiro, o “Latin1”. Tudo o que não está nessa codificação sai como papa.
O que é o BOM e por que ele ajuda
O BOM (marca de ordem de bytes) são três bytes de serviço, EF BB BF, no início do arquivo. Formalmente significam “isto é UTF-8”, e o Excel os entende: um arquivo com BOM abre certo mesmo com um clique duplo.
O outro lado: todos os demais também veem esses bytes. Um programa que não conhece o BOM lê o nome da primeira coluna como id com um caractere invisível na frente — o que quebra a correspondência de campos. É a causa clássica do misterioso “coluna id não encontrada”.
Então a regra é simples: use BOM se o arquivo é para uma pessoa com Excel; deixe-o de fora se o arquivo é para um programa.
Detectando a codificação pelo conteúdo
O UTF-8 é reconhecível pela estrutura: seus bytes altos seguem sequências estritamente definidas. Se o arquivo obedece à regra e contém bytes não ASCII, quase certamente é UTF-8.
Se a estrutura não se encaixa, restam as candidatas de um byte, e o conteúdo decide: o texto é decodificado com cada candidata e vence a que parece texto de verdade — sem caracteres de desenho de caixa, sem caracteres de controle ou de substituição. Quando isso não é conclusivo, você pode trocar a codificação manualmente sem salvar o arquivo de novo. O mesmo mecanismo é usado para o DBF; veja caracteres estranhos em DBF.
Latin1, windows-1252 e ISO-8859-1
Muitos sistemas brasileiros antigos exportam em “Latin1”. Na prática, quase sempre é o windows-1252, que difere do ISO-8859-1 em uns poucos caracteres (aspas curvas, travessão, o símbolo do euro). Para texto em português, a diferença quase nunca aparece — mas se o seu arquivo tem “aspas curvas” ou “–” e elas saem erradas, a escolha entre os dois é o motivo.
Como salvar para que ninguém tenha problemas
- Para troca entre programas: UTF-8 sem BOM, vírgula como delimitador, quebras de linha
\n. - Para uma pessoa usando o Excel em português: UTF-8 com BOM e ponto e vírgula como delimitador.
- Para sistemas mais antigos: windows-1252 (ou a página de código que eles esperam), ponto e vírgula. Confira se todos os caracteres cabem — aspas curvas, travessões e o símbolo do euro faltam em algumas páginas de código.
Na janela de exportação do Tabulens essas são combinações prontas, e não uma lista abstrata de codificações.
Perguntas frequentes
Por que meu arquivo virou windows-1252 depois de salvar pelo Excel?
O Excel salva o “CSV” simples na página de código do sistema. Para UTF-8, escolha “CSV UTF-8 (delimitado por vírgulas)” como uma opção separada.
Posso remover o BOM?
Pode, são apenas os três primeiros bytes do arquivo. Qualquer editor que deixe escolher a codificação pode salvar sem ele.
E se o arquivo mistura codificações?
Divida-o por origem e trate as partes separadamente: uma única tabela não pode ser recodificada quando as codificações estão misturadas dentro dela.
Grátis para uso pessoal. Seu arquivo não é enviado a nenhum servidor. Versão para Windows — 3.5 MB, sem instalação: detalhes. Para organizações — licença.