CSV para Excel e vice-versa sem estragar seus dados

O problema do separador começa antes mesmo de o arquivo abrir

O Excel decide como dividir um CSV em colunas usando o separador de listas definido nas configurações regionais do sistema operacional, e não olhando o arquivo. Em um computador configurado com uma localidade europeia, esse separador é o ponto e vírgula por padrão, e uma exportação comum separada por vírgulas vai parar inteira em uma única coluna de texto sem divisão. Em um computador configurado para os Estados Unidos, acontece o contrário com um arquivo separado por ponto e vírgula. Nenhum dos dois resultados quer dizer que o arquivo está corrompido. Quer dizer que o Excel tentou adivinhar com base em configurações que não têm nada a ver com o modo como o arquivo foi escrito. Um conversor como CSV para Excel, que lê o arquivo com vários separadores candidatos e verifica qual deles produz um número de campos consistente nas linhas de amostra, elimina a adivinhação por completo, em vez de confiar na extensão do arquivo ou em uma configuração do sistema.

Zeros à esquerda e números longos são as vítimas silenciosas

O maior estrago que pode acontecer em uma conversão de CSV para Excel é a pressa em transformar texto em número. Um código de produto escrito como 00123 vira o número 123 no instante em que a planilha decide que ele parece numérico, e esse zero à esquerda não pode ser recuperado depois. Ele simplesmente some. Identificadores mais longos falham de outro jeito. Um número de cartão ou de código de barras com dezesseis dígitos perde os últimos dígitos sem nenhum aviso, porque os números comuns de uma planilha não comportam mais do que cerca de quinze algarismos significativos sem arredondar. Os dois casos devem continuar como texto, sem conversão, e a mesma regra vale quando o destino é um programa, e não o Excel: CSV para JSON os mantém como strings. Valores que são de fato números, como quantidades, preços e totais, devem continuar sendo convertidos normalmente, para que possam ser somados e usados em cálculos.

É na codificação que quebram os dados que não estão em inglês

Arquivos exportados de sistemas contábeis ou bancos de dados mais antigos muitas vezes nem estão em UTF-8. Os casos comuns são Windows-1251, para texto em cirílico, e Windows-1252, para caracteres acentuados da Europa Ocidental, e abrir um desses arquivos com a suposição errada produz a conhecida parede de caracteres embaralhados. Detectar a codificação real, procurando primeiro uma marca de ordem de bytes (BOM), depois validando estritamente como UTF-8 e, se isso falhar, recorrendo à distribuição dos bytes altos, identifica o problema automaticamente. Ninguém precisa adivinhar a opção certa em um menu de codificações.

A própria marca de ordem de bytes pode causar um estrago silencioso

A marca de ordem de bytes do UTF-8 é formada por três bytes invisíveis bem no começo do arquivo, que avisam ao Excel que o texto a seguir é Unicode. Isso é útil quando o destino é o Excel. Vira um problema no momento em que o arquivo vai para qualquer outro lugar. Uma ferramenta de linha de comando ou um pipeline de dados mais antigo que não remove esses bytes acaba com eles grudados no primeiro caractere da primeira célula do cabeçalho. Assim, uma coluna que deveria se chamar “id” deixa de corresponder a qualquer coisa que espere exatamente esse nome. Manter ou descartar o BOM depende inteiramente do que vai ler o arquivo em seguida, e não de um único padrão universal.

O caminho inverso tem as próprias decisões

Converter uma planilha de volta para CSV com Excel para CSV levanta uma questão que o caminho de ida nunca levanta. Uma célula com fórmula tem dois valores, o texto da própria fórmula e o número que ela calculou da última vez, e o CSV só consegue levar um deles por vez. Exportar o valor calculado é o que a maioria dos sistemas espera importar. Exportar o texto da fórmula é o que uma pessoa que revisa o arquivo quer ler. As datas merecem o mesmo cuidado explícito. Gravá-las em um formato fixo, escolhido de antemão, em vez de confiar no que a planilha por acaso exibia, impede que o mesmo arquivo gere datas com aparência diferente conforme as configurações regionais do computador que fez a formatação.

Erros comuns e a configuração que evita cada um

Deixar o separador decimal no ponto. Uma exportação separada por ponto e vírgula, vinda de um país que escreve um e meio como 1,50, precisa de “Separador decimal” em “Vírgula” na ferramenta CSV para Excel; senão, cada preço continua como texto e não pode ser somado. Confiar na detecção automática de tipos para identificadores. Ela protege zeros à esquerda e tudo o que passa de quinze dígitos, mas um número de pedido ou um CEP sem zero à esquerda ainda vira número; quando nenhuma coluna precisa de contas, “Tipos de célula” em “Tudo como texto” mantém cada valor exatamente como foi escrito. Tentar colocar uma exportação de alguns milhões de linhas em uma única pasta de trabalho. O XLSX vai até 1.048.576 linhas, então um CSV mais longo é recusado com um link para Dividir CSV, em vez de ser cortado sem nenhum aviso.

Na volta, compare três padrões de Excel para CSV com o que vai ler o arquivo em seguida. Em “Codificação de saída”, o padrão é UTF-8 com BOM, a forma de que o Excel precisa; um script ou um carregador de banco de dados geralmente quer UTF-8 simples. Em “Formato de data”, o padrão é ISO 8601, então 14 de março de 2026 vira 2026-03-14 em qualquer computador, com 14.03.2026, 03/14/2026 e o número de série do Excel como alternativas. Em “Quebras de linha”, o padrão é CRLF, para Windows, com LF para ferramentas Unix. Uma quarta configuração é fácil de esquecer: por padrão, só a primeira planilha é exportada, então uma pasta de trabalho com uma segunda aba precisa de “Todas as planilhas”, que devolve um ZIP com um CSV por planilha.