Porque é que o seu CSV parte os acentos e as datas no Excel

Três avarias, uma só queixa

A frase que as pessoas escrevem é sempre a mesma: o CSV está partido. O que querem dizer é uma de três coisas diferentes, e essas três não têm nada em comum a não ser a extensão do ficheiro. Os acentos estão errados: é um problema de codificação. Está tudo na primeira coluna: é um problema de separador. Os valores estão certos mas com a forma errada — 03/04 tornou-se uma data, um código postal perdeu o zero, uma referência longa transformou-se em algo com um E lá dentro — e isso não é nem uma coisa nem outra: acontece depois de o ficheiro ter sido lido corretamente.

Distingui-las exige um só gesto: abrir o CSV num editor de texto simples em vez de numa folha de cálculo. Bloco de notas, TextEdit, gedit, qualquer coisa que mostre os bytes como texto sem tentar ser prestável. Nessa janela não há colunas, nem células, nem tipos — apenas linhas com caracteres entre os campos. Se os acentos aí estiverem certos, o ficheiro está bom e a culpa é toda da forma como o Excel o lê. Se aí também estiverem errados, a culpa é a montante, em quem escreveu o ficheiro, e nenhuma definição de importação a repara.

Os acentos: três bytes em falta no início do ficheiro

Em UTF-8, uma letra sem acento ocupa um byte e uma acentuada ocupa dois. É todo o mecanismo. Quando um programa lê um ficheiro UTF-8 julgando-o escrito numa página de códigos herdada de um byte, mostra cada um desses dois bytes como um caráter próprio, e a barafunda que daí resulta é completamente determinista. Um é sozinho vira é. São Paulo vira São Paulo, informação vira informação e avô vira avô. Cada letra acentuada cresce exatamente um caráter, e o primeiro do par é quase sempre um Ã, daí o aspeto tão reconhecível do estrago.

O remédio em que toda a indústria convergiu cabe em três bytes mesmo no início do ficheiro: EF BB BF, a marca de ordem de bytes do UTF-8. Não codifica caráter nenhum e não imprime nada; existe apenas para que um leitor saiba o que está a ver. A página da Microsoft sobre o assunto di-lo numa linha — um CSV em UTF-8 abre normalmente se tiver sido guardado com marca de ordem de bytes — e oferece um caminho de importação para os que não a têm. Essa única frase explica por que quase todos os botões de exportar em que já carregou produzem um ficheiro que começa por três bytes invisíveis.

O conversor deste site não a acrescenta. O CSV que lhe entrega é UTF-8 sem marca de ordem de bytes, e o primeiro byte do ficheiro é o primeiro caráter do seu primeiro cabeçalho de coluna. É o correto do ponto de vista da norma — o RFC 4180 define o formato e nunca menciona uma marca — e o errado para fazer duplo clique numa máquina Windows europeia. O resto deste artigo trata em boa parte do que fazer com esse facto, e a versão curta é: importe o ficheiro em vez de o abrir.

O separador: decide o seu sistema operativo, não o ficheiro

O nome valores separados por vírgulas sugere que a vírgula faz parte do formato, e o RFC 4180 define-o assim. O Excel não lê o formato: lê uma definição. A página de resolução de problemas da Microsoft di-lo sem rodeios: alterar o separador de listas nas definições regionais do Windows afeta o delimitador usado ao abrir ou ao guardar um ficheiro de valores separados por vírgulas, porque o Excel usa o caráter separador de listas do Windows como delimitador dos ficheiros .csv. Acrescenta que a vírgula é o separador de listas por omissão da configuração regional inglesa americana.

Que a definição não seja uma vírgula em todo o lado é questão de aritmética, não de gosto. Onde a vírgula é o separador decimal, não pode além disso separar campos sem ambiguidade: uma linha com um preço de mil duzentos e trinta e quatro vírgula cinco seria indistinguível de dois campos. O Windows entrega por isso um ponto e vírgula como separador de listas nas configurações francesa, alemã, espanhola, italiana e portuguesa, e uma vírgula nas inglesas. É toda a linha divisória, e é por isso que uma exportação escrita por um serviço americano e aberta em Lyon, Leipzig, León, Livorno ou Lisboa chega como uma só coluna muito larga.

Daí decorrem duas coisas que as pessoas entendem mal. A primeira: mudar o separador de listas do Windows para reparar um ficheiro é uma alteração global que afeta todas as aplicações da máquina, e a própria documentação da Microsoft avisa disso; não é um remédio ficheiro a ficheiro e vai esquecer-se de que o fez. A segunda: o delimitador é uma propriedade do ficheiro e a definição é uma propriedade do leitor, por isso um ficheiro nunca está certo ou errado em abstrato — está certo para um leitor a quem disse a verdade. A caixa de diálogo de importação existe precisamente para lha poder dizer.

Os tipos: o Excel adivinha, e adivinha enquanto abre

Um CSV não tem tipos. Todo o campo é texto, e o RFC 4180 atribui às aspas uma única tarefa: proteger um campo que contenha uma vírgula, umas aspas ou uma quebra de linha. Em nenhum ponto do formato se pode dizer isto é uma cadeia de caracteres, não lhe toque. Por isso uma folha de cálculo que abra um tem de adivinhar, campo a campo, e os palpites são feitos para o caso comum, não para o seu. Um campo que diz 03/04 parece uma data e passa a sê-lo. Um campo que diz 01234 parece um número e perde o zero. Um campo de dezasseis algarismos parece um número muito grande, e a página da Microsoft enuncia o limite sem o suavizar: o Excel tem uma precisão máxima de 15 algarismos significativos, pelo que para qualquer número de 16 algarismos ou mais, tudo o que passa do décimo quinto é arredondado a zero e o valor é mostrado em notação científica.

O caso das datas merece um parágrafo próprio pela forma como falha. Um campo que diz 02/03/2026 é 2 de março em Lisboa e 3 de fevereiro em Chicago, e ambas as leituras são legítimas — nada no ficheiro diz qual se pretendia. Mas um campo que diz 13/03/2026 não tem décimo terceiro mês, por isso um leitor que espere o mês primeiro não o consegue interpretar como data e deixa-o como texto. Passe um ano inteiro de datas e quase duas em cada cinco são ambíguas: 144 dos 365 dias caem no dia doze do mês ou antes. A coluna que sai é em parte datas silenciosamente trocadas e em parte texto alinhado à esquerda, sem uma única mensagem de erro. É a avaria silenciosa mais cara do trabalho de escritório.

Parte do estrago acontece antes mesmo de o Excel intervir, e este conversor não é inocente disso. Uma célula de folha de cálculo é um valor bruto mais um formato de apresentação, e o CSV só pode levar um dos dois: o que fica escrito é o texto formatado. Passe o mesmo 2 de março de 2026 com um formato de dia primeiro e o ficheiro recebe 02/03/2026; passe o valor idêntico com um formato de mês primeiro e o ficheiro recebe 3/2/26. Pior, um identificador de dezasseis algarismos numa coluna de formato geral sai do livro já escrito como 1.23457E+15, porque era assim que o livro o mostrava. O identificador foi destruído pelo formato, não pelo leitor. Nada a jusante o consegue recuperar.

O que resolve realmente cada caso

Importar em vez de abrir. Essa única mudança resolve de imediato os dois primeiros problemas e dá-lhe a ferramenta para atacar o terceiro. Dados, depois De Texto/CSV, abre uma pré-visualização com a origem do ficheiro e o delimitador ambos visíveis e alteráveis, e a pré-visualização redesenha-se a cada alteração: vê os acentos a assentar e as colunas a separar-se antes de assumir. Escolher Transformar Dados em vez de Carregar permite depois fixar o tipo de uma coluna em Texto — a própria orientação da Microsoft sobre conservar zeros iniciais aponta exatamente para este caminho — e uma coluna com tipo Texto guarda os zeros, guarda os dezasseis algarismos e não se torna uma data.

Existe uma alavanca mais recente e mais duradoura que muito poucos conhecem. No Microsoft 365 e no Excel 2024, tanto em Windows como em Mac, Ficheiro, Opções, Dados contém uma secção chamada Conversão Automática de Dados com quatro caixas: remover zeros iniciais e converter em número; manter os primeiros 15 algarismos dos números longos e mostrá-los em notação científica se necessário; converter os algarismos em torno da letra E em notação científica; e converter em data as combinações de letras e algarismos com ar de data. Desmarcar as duas primeiras é o melhor uso de dez segundos para quem lida com dados de referência, porque trava a destruição na origem em vez de lhe exigir um ritual de importação de cada vez.

O que não funciona também merece uma lista, porque são as sugestões que lhe vão dar. Envolver um campo em aspas não trava a conversão: as aspas são estruturais, dizem onde o campo acaba, e o Excel retira-as antes de começar a adivinhar. Mudar o nome do ficheiro para deixar de ser um .csv altera o caminho de código que o abre, efeito real mas frágil para nele confiar. Formatar a coluna como Texto depois de o ficheiro estar aberto não faz nada, porque os algarismos se perderam durante o carregamento e a Microsoft di-lo — um formato de texto só afeta o que introduzir a seguir. E pôr um sinal de igual à frente de um valor entre aspas força de facto texto, mas transforma o campo numa fórmula em vez de num valor, aparece como caracteres literais em qualquer outro programa que leia o ficheiro, e um sinal de igual inicial é o vetor clássico da injeção de fórmulas em folhas de cálculo. Não envie isso a ninguém.

O que este conversor põe no ficheiro

Lido no código-fonte em vez do argumentário: a ferramenta Excel para CSV lê o seu livro no navegador, deixa-o escolher uma folha e escreve essa folha com uma vírgula entre campos, codificação UTF-8 e sem marca de ordem de bytes. Os campos só levam aspas quando é preciso — quando contêm uma vírgula, aspas duplas ou uma quebra de linha — que é exatamente o que o RFC 4180 exige e nada mais. Um campo que contenha umas aspas vê-as duplicadas, pela mesma regra. Nada é enviado: o livro é analisado na sua máquina e o CSV nunca a deixa.

Duas dessas escolhas vão morder o leitor europeu que faça duplo clique no resultado, e convém saber quais. A vírgula porá tudo na coluna A numa máquina cujo separador de listas seja o ponto e vírgula. A ausência de marca de ordem de bytes estragará os acentos numa máquina que recorra a uma página de códigos herdada. Ambas se curam com o mesmo procedimento de importação e nenhuma se cura queixando-se do ficheiro, que está conforme à norma. Se enviar o CSV a uma pessoa e não a um programa, diga que separador e que codificação usou: uma linha no e-mail poupa uma tarde.

Um hábito vale mais do que todas as definições deste artigo: corrija o livro antes de o exportar, e não o CSV depois. Ponha as colunas de identificadores em Texto dentro da folha de cálculo, para que os códigos postais e os números de conta já sejam cadeias de caracteres quando a conversão acontecer. Ponha as colunas de datas num formato inequívoco — o ano primeiro, com quatro algarismos, depois o mês, depois o dia — para que o texto exportado não possa ser lido de duas maneiras em nenhuma configuração regional do mundo. Faça-o uma vez, e cada exportação desse livro será limpa para todos os leitores, para sempre, sejam quais forem as definições regionais deles.

Perguntas frequentes

Abri o ficheiro e cada linha está na coluna A. O CSV está partido?

Quase de certeza que não. O que está a ver é o Excel a dividir por um caráter que o seu ficheiro não usa. A Microsoft documenta que o Excel tira o delimitador dos ficheiros .csv do separador de listas do Windows, por isso um ficheiro separado por vírgulas numa máquina configurada com ponto e vírgula não encontra nenhum e conclui que cada linha é um campo enorme. Abra o ficheiro num editor de texto e olhe para a primeira linha: o caráter que está entre os cabeçalhos é o delimitador real. Feche-o, vá a Dados e a De Texto/CSV, e escolha esse caráter na pré-visualização. Duas coisas a não fazer: não divida a coluna à mão, porque vai voltar a fazê-lo no mês que vem; e pense duas vezes antes de mudar o separador de listas do Windows, já que a própria documentação da Microsoft avisa que é uma alteração global que afeta todas as aplicações da máquina.

Porque é que pôr aspas à volta de um campo não impede o Excel de o transformar numa data?

Porque as aspas num CSV são pontuação, não anotação. O RFC 4180 dá-lhes uma única tarefa: marcar onde um campo começa e acaba quando o próprio campo contém uma vírgula, aspas duplas ou uma quebra de linha. Não levam informação sobre o que o campo significa, e o formato não oferece mais nenhum sítio onde pôr essa informação — um CSV não tem mesmo nenhum conceito de tipo. Por isso o leitor retira as aspas como parte da análise, exatamente como deve, e só então começa a adivinhar o que tem em mãos. É por isso que todos os remédios publicados pela Microsoft estão do lado da leitura e não da escrita: importar a coluna como Texto, ou desligar as conversões automáticas. Nada do que escrever no ficheiro limitará o palpite.

Basta pôr sep=; na primeira linha para que o Excel perceba?

Funciona no Excel e é uma armadilha em todo o resto. Essa primeira linha é uma extensão específica do Excel: o RFC 4180, que define o formato CSV, não a menciona e nenhum analisador conforme é obrigado a entendê-la. Assim o ficheiro fica mais fácil para um programa e mais difícil para todos os outros — um script, uma importação para base de dados, um programa de contabilidade ou um colega num Mac lerão essa linha como uma linha de dados com um campo chamado sep=; e falharão ou importarão em silêncio um registo lixo no topo da sua tabela. Se o ficheiro vai para uma pessoa que o abrirá no Excel e em mais lado nenhum, é uma comodidade razoável. Se vai para uma cadeia de processamento, ou para alguém cujas ferramentas desconhece, não o ponha: mande o ficheiro limpo e diga numa frase que separador e que codificação usou.

A minha referência de 16 algarismos acaba agora em zeros. Para onde foram os algarismos?

Foram arredondados, e não são recuperáveis a partir desse ficheiro. A Microsoft enuncia a regra diretamente: o Excel tem uma precisão máxima de 15 algarismos significativos, e para qualquer número de 16 algarismos ou mais tudo o que passa do décimo quinto é arredondado a zero. O valor é depois mostrado em notação científica porque já não cabe utilmente na coluna. O importante é que isto não é um problema de apresentação: alargar a coluna ou mudar o formato de número não traz os algarismos de volta, porque desapareceram do valor guardado. Volte à fonte original, importe a coluna como Texto, e nunca deixe um número de referência, um número de conta, um número de cartão ou um código de produto longo existir como número em qualquer ponto da cadeia. No Microsoft 365 e no Excel 2024 também pode desligar a conversão de vez: Ficheiro, Opções, Dados, e desmarque a opção sobre manter os primeiros 15 algarismos dos números longos.

Vírgula ou ponto e vírgula — qual é realmente o correto?

Segundo a norma, a vírgula. O RFC 4180 define o formato com vírgulas entre campos, um retorno de carro e uma mudança de linha no fim de cada registo, e aspas duplas à volta de qualquer campo que contenha um desses caracteres. Todas as linguagens de programação, bases de dados e ferramentas de dados o seguem, por isso a vírgula é o que se deve usar para tudo o que uma máquina vá ler. Na prática, porém, o ponto e vírgula é o que uma folha de cálculo espera na maior parte da Europa continental, pela razão aritmética de que ali a vírgula já é o separador decimal. A regra praticável é decidir por destino e não por princípio: vírgula para máquinas e para tudo o que atravesse uma fronteira, ponto e vírgula quando o ficheiro vai direto para o Excel de um colega cujas definições regionais conhece. E escolha o que escolher, diga-o: uma linha a indicar o separador e a codificação previne toda a classe de problemas de que trata este artigo.