Por que o Excel apaga os zeros à esquerda dos seus códigos em CSV e como mantê-los (Guia 2026)

Diagnostique em 30 segundos: o arquivo está certo, o Excel adivinhou errado

A primeira coisa a esclarecer quando seus códigos perdem os zeros é se os dados estão danificados ou apenas foram lidos de forma errada, porque os dois casos têm correções muito diferentes, e a correção errada pode transformar um problema de exibição em perda real de dados. Aqui vai o teste de 30 segundos. Abra o mesmo arquivo em um editor de texto simples, o Bloco de Notas no Windows ou o TextEdit em modo de texto simples no Mac. Se os códigos aparecerem com todos os zeros ali, 00123, 02138, 07477, seus dados estão intactos e apenas a exibição do Excel está errada. O arquivo no disco contém os caracteres certos, e o Excel mudou o significado deles quando abriu o arquivo. Esse é o caso mais comum, e todas as correções deste guia partem dele.

A segunda pista é quais valores mudaram. Se palavras comuns, números curtos e pontuação parecem normais, mas códigos com zeros à esquerda perderam esses zeros, IDs longos perderam os últimos dígitos, e números grandes aparecem em notação científica, você está diante de adivinhação de tipo, e não de um problema de delimitador nem de corrupção. Um problema de delimitador joga linhas inteiras em uma única coluna. Corrupção embaralha tudo ou apaga linhas. A adivinhação de tipo é cirúrgica: ela altera exatamente os valores que parecem números, e deixa todo o resto intocado. Se 00123 virou 123, 02138 virou 2138, e um ID de 16 dígitos termina em um zero que ele não tinha antes, o Excel tratou texto como número, e isso revela tanto a causa quanto a correção.

A terceira verificação decide se ainda é possível resgatar os dados. Se o editor de texto também mostrar os valores sem os zeros, o arquivo em si já foi salvo novamente depois da conversão, e os zeros podem ter sumido daquela cópia. Não entre em pânico ainda, e acima de tudo não salve por cima do original outra vez. A seção de resgate mais adiante neste guia cobre exatamente esse caso, incluindo a única situação em que os dígitos são realmente irrecuperáveis: quando um ID longo foi truncado para 15 dígitos, os dígitos perdidos sumiram daquela cópia, e apenas os dados de origem podem gerá-los de novo. Até você ter verificado, mantenha o arquivo original intocado, trabalhe em uma cópia, e nunca salve um arquivo convertido por cima do arquivo bom.

Por que o Excel adivinha: um arquivo CSV não carrega tipos

Para entender por que isso continua acontecendo, você precisa de um fato sobre o formato CSV: um arquivo CSV é texto simples, sem um cabeçalho que diga quais valores são números, quais são texto, e quais são datas. Um arquivo de planilha carrega os tipos das células junto com ele. Um arquivo CSV não carrega nem tipos nem formatação. São apenas caracteres, vírgulas e quebras de linha. Quando um programa o abre, o programa precisa decidir o que cada valor significa, e programas diferentes decidem de formas diferentes. O Google Planilhas e o Python mantêm os valores de CSV como texto, a menos que recebam outra ordem, e por isso o mesmo arquivo parece correto neles. O Excel, quando você clica duas vezes em um arquivo CSV, adivinha: qualquer coisa que pareça número vira número, qualquer coisa que pareça data vira data, e ele não verifica se essa adivinhação estava certa.

Essa adivinhação é todo o problema. Um número, por definição, não tem zeros à esquerda: o número 123 e o código 00123 são o mesmo número, mas não são o mesmo código. Um CEP, um SKU, um ID de funcionário ou um prefixo de telefone não é uma quantidade. É um rótulo feito de dígitos, e seus zeros à esquerda fazem parte do rótulo, exatamente como as letras de uma palavra. O Excel não sabe disso. Ele vê dígitos, aplica sua regra de número, e descarta os zeros, porque para um número de verdade os zeros não carregam informação. A mesma lógica explica a segunda vítima: os números do Excel mantêm apenas 15 dígitos significativos, então um ID de 16 dígitos ou mais tem seus dígitos extras substituídos por zeros. O arquivo não mudou. O leitor mudou o significado dos caracteres.

Isso também explica por que esse problema aparece com tanta frequência em arquivos convertidos a partir de JSON. O JSON distingue tipos: a string "00123" e o número 123 são valores diferentes, e uma conversão de JSON para CSV escreve a string com os caracteres 00123. A conversão está correta. A abertura está desencontrada. O conversor desta página, por exemplo, foi executado em uma amostra com os códigos 00123 e 00456, os CEPs 02138 e 07477, e um ID de pedido de 18 dígitos, e produziu cada valor byte a byte idêntico no CSV, sem truques de aspas e sem dígitos descartados. Saber que o desencontro está na etapa de abertura, e não na etapa de conversão, mostra onde corrigir: na importação, antes de o Excel adivinhar, como as próximas seções mostram.

Três formas de a adivinhação destruir dados, e como distingui-las

A adivinhação de tipo destrói dados de três formas distintas, e distingui-las importa porque apenas algumas delas são reparáveis. A primeira é zeros à esquerda descartados: 00123 vira 123, 02138 vira 2138. Os dígitos que restam estão corretos, mas o código agora está errado: um CEP que perdeu o zero aponta para outro lugar, um SKU que perdeu os zeros não vai bater com o sistema do armazém, e um leitor de código de barras pode rejeitar o código encurtado. A segunda é truncamento de precisão: qualquer ID com mais de 15 dígitos perde a parte final. Um ID de conta de 16 dígitos como 1234567890123456 vira 1234567890123450, exibido como 1.23457E+15. Os últimos dígitos não estão escondidos, eles foram substituídos por zeros, e o ID agora aponta para outro registro ou para registro nenhum.

A terceira forma é mais sutil, e pega quem acha que já corrigiu o problema. A exibição em notação científica parece perda de dados, mas ainda não é, em alguns casos. Um valor exibido como 1.23E+15 pode ainda guardar todos os seus dígitos por baixo, se estiver dentro do limite de 15 dígitos, e alargar a coluna ou mudar o formato mostra esses dígitos de novo. Mas se o valor passa de 15 dígitos, a exibição é honesta: os dígitos realmente sumiram. O teste é a barra de fórmulas. Clique na célula e leia a barra de fórmulas, não a exibição da célula. Se a barra de fórmulas mostrar o valor completo, apenas a exibição precisa de correção. Se a barra de fórmulas mostrar o valor truncado, os dados em si mudaram, e apenas a seção de resgate pode ajudar. Nunca confie apenas na exibição da célula para códigos e IDs.

O bloco de código abaixo mostra os resultados exatos, produzidos ao executar o conversor real desta página em uma amostra de três linhas. A saída em CSV é byte a byte idêntica à entrada em JSON para cada código, o que prova que o conversor não é o culpado. A coluna da direita mostra o que o Excel faz com esses mesmos valores ao clicar duas vezes, e é esse comportamento que este guia corrige. Repare no padrão: o conversor preserva, o Excel adivinha, e é na adivinhação que cada dígito se perde.

CSV file (from this page converter, verified):\nsku,zip,name,orderId\n00123,02138,Widget A,\n00456,07477,Widget B,\n00078,,Widget C,123456789012345678\n\nWhat Excel shows on double-click:\nsku -> 123, 456, 78 (leading zeros dropped)\nzip -> 2138, 7477 (leading zeros dropped)\norderId -> 1.23457E+17, stored as 123456789012345000 (last 3 digits replaced with zeros)

Repare no que a tabela prova: nada falta no arquivo, e tudo falta na visão do Excel. Por isso a correção por importação funciona de forma tão completa. Quando você diz ao Excel que uma coluna é Texto antes de carregar, ele armazena os mesmos caracteres sem nenhuma conversão, e cada código volta a ser ele mesmo, sem edição, sem localizar e substituir, e sem digitação. Se o seu arquivo segue esse padrão, pule a seção que desmonta os mitos e vá direto para a correção por importação. Você não tem um arquivo danificado. Você tem um arquivo lido de forma errada.

Quatro correções que não funcionam, e por que as pessoas insistem nelas

Antes das correções que funcionam, vale afastar as quatro correções que não funcionam, porque cada uma delas desperdiça tempo e uma delas piora as coisas. A primeira é colocar os valores entre aspas no CSV. Muitos guias afirmam que escrever "00123" com aspas protege os zeros. Não protege, no Excel. O Excel remove as aspas durante a importação e depois aplica a mesma adivinhação de número ao valor dentro delas, então "00123" vira 123 exatamente como 00123 sem aspas. As aspas controlam como vírgulas dentro de um valor são tratadas, e não como o Excel tipifica o valor. Se alguém vendeu a você um conversor que coloca códigos entre aspas para protegê-los, as aspas protegem as vírgulas, não os zeros.

A segunda é formatar a coluna como Texto depois de abrir o arquivo. Isso muda como entradas futuras são tratadas, mas não restaura dígitos que já foram descartados quando o Excel leu o arquivo. Os zeros foram descartados no momento da leitura, e a formatação não consegue inventar caracteres que já não estão ali. A terceira é o formato personalizado 00000, que preenche a exibição até cinco dígitos. Ele funciona apenas como exibição, para códigos de tamanho fixo, e apenas quando os dígitos sobreviveram: 123 aparece como 00123, mas o valor armazenado continua sendo 123, então qualquer exportação escreve 123, e qualquer busca pelo código real falha. Pior, ele falha em silêncio em códigos de tamanho variável, porque um código de seis dígitos preenchido até cinco dígitos não muda, e um código de quatro dígitos preenchido até cinco ganha um zero que ele nunca teve.

A quarta é o truque do apóstrofo, digitar um apóstrofo antes do código, como em uma célula digitada como 00123 com um apóstrofo na frente. Isso funciona para valores que você digita à mão, porque o apóstrofo diz ao Excel para armazenar a entrada como texto. Não funciona para uma importação de CSV, porque o apóstrofo passa a fazer parte do conteúdo do arquivo: uma célula de CSV com um apóstrofo seguido de dígitos é importada como um valor de texto que literalmente começa com um apóstrofo, o que quebra buscas e exportações. Guarde o apóstrofo para entradas digitadas à mão, e use a correção por importação para arquivos. Saber quais correções falham poupa você da armadilha mais comum de todas: acreditar que o problema está resolvido porque a exibição parece certa, enquanto os valores armazenados continuam errados.

Correção 1: importe o arquivo e defina as colunas de códigos como Texto

Esta é a correção a tentar primeiro, porque ela não muda nada no seu sistema, nada no arquivo, e funciona em qualquer CSV, qualquer que seja seu delimitador ou sua codificação. Em vez de clicar duas vezes no arquivo, abra o Excel primeiro, e depois importe o arquivo pela importação guiada, onde você escolhe o tipo de cada coluna. A prévia na janela de importação mostra na hora se você escolheu certo: os códigos aparecem com seus zeros na prévia exatamente como vão aparecer na planilha. Se a prévia ainda mostrar códigos sem os zeros, você ainda não mudou nada, e pode ajustar os tipos das colunas antes de carregar.

• ▸Abra uma pasta de trabalho em branco no Excel. Não clique duas vezes no arquivo CSV.
• ▸Vá em Dados, depois em De Texto/CSV, e selecione seu arquivo.
• ▸Na janela de prévia, confira o delimitador e a origem do arquivo, e depois clique em Transformar Dados em vez de Carregar, para abrir o editor do Power Query.
• ▸No editor do Power Query, encontre a etapa automática Tipo Alterado e remova-a, porque é nessa etapa que acontece a adivinhação de número.
• ▸Selecione cada coluna de código, CEPs, SKUs, IDs, prefixos de telefone, e defina o tipo de dados como Texto.
• ▸Clique em Fechar e Carregar. Os códigos chegam como texto, com cada zero à esquerda e cada dígito intactos.

Faça disso seu jeito padrão de abrir arquivos CSV, e não apenas seu movimento de resgate. Clicar duas vezes é uma adivinhação sobre o delimitador, a codificação, e o tipo de cada coluna. Importar é uma escolha sobre os três, e a escolha leva cerca de um minuto a mais. No Mac, o mesmo caminho funciona por Dados, depois De Texto, com os tipos das colunas definidos na etapa de importação. Ferramentas que leem CSV como texto simples, como o módulo csv do Python, nunca adivinham nada, e por isso um arquivo que parece quebrado no Excel é lido corretamente em um script. Essa diferença já é, por si só, um diagnóstico: se um script mostra os zeros e o Excel não, o arquivo está certo e o Excel adivinhou errado.

Correção 2: desative a conversão automática de dados do Excel (Microsoft 365 e Excel 2024)

Se você abre arquivos CSV todos os dias, importar cada vez cansa, e a correção duradoura é mudar o que o Excel adivinha por padrão. Versões recentes do Excel, Microsoft 365, Excel 2024, e seus equivalentes para Mac, trazem uma configuração chamada conversão automática de dados, em Arquivo, depois Opções, depois Dados. Ela lista as conversões que o Excel aplica por conta própria, incluindo remover zeros à esquerda de texto numérico, truncar números para 15 dígitos, e converter strings de letras e números que parecem datas ou notação científica. Desmarque as conversões que você não quer, e o Excel vai deixar esses valores como texto em aberturas futuras, incluindo aberturas por clique duplo.

Duas cautelas antes de você confiar nessa configuração. Primeiro, ela muda apenas o comportamento futuro. Ela não repara células que já foram convertidas, e não restaura dígitos que já foram descartados. Um arquivo que você abriu na semana passada ainda guarda os valores convertidos na pasta de trabalho, e apenas uma importação nova a partir do arquivo original vai trazer os códigos de volta. Segundo, a configuração vive na sua máquina, não no arquivo. Um colega que abrir o mesmo arquivo em uma máquina com a configuração padrão ainda vai ver códigos sem os zeros, e um arquivo que você enviar não carrega nenhuma proteção junto. Trate a configuração como uma comodidade para a sua própria máquina, e trate a correção por importação como o método confiável para arquivos que você compartilha. Os guias companheiros sobre o problema de uma única coluna e o problema de codificação cobrem as outras duas adivinhações que o Excel faz ao abrir, delimitador e codificação, e eles estão ligados nos guias relacionados abaixo.

Correção 3: para arquivos que você produz, mantenha os códigos como texto na origem

Se você produz o CSV, a correção mais forte é deixar os dados de origem sem ambiguidade antes de eles chegarem ao Excel. Em JSON, isso significa manter os códigos como strings, e não como números: a string "00123" vira os caracteres 00123 na conversão, enquanto o número 123 vira 123, sem zeros para preservar. Esta é uma decisão sobre os dados de origem, e não uma configuração do conversor, porque nenhum conversor consegue inventar zeros que o número de origem nunca teve. Se o seu sistema de origem já armazena um CEP como número, os zeros já sumiram antes da conversão, e apenas o sistema de origem pode restaurá-los, por exemplo ao reexportar o código como uma string de largura fixa.

Para valores que já perderam os zeros, mas têm tamanho fixo, existe uma reconstrução legítima: a função TEXTO. Se cada código de uma coluna tem cinco dígitos, =TEXTO(A2;"00000") reconstrói a exibição e o valor de texto a partir do número sem os zeros, porque os dígitos que faltam são todos zeros e sua quantidade é conhecida. Copie os resultados e cole-os como valores para fixá-los. Mas isso só funciona quando o tamanho é fixo e o único dano foi zeros à esquerda descartados. Não dá para reconstruir um ID longo truncado, porque os dígitos perdidos não eram zeros, eram dígitos desconhecidos substituídos por zeros, e nenhuma fórmula consegue adivinhá-los. Se seus IDs variam de tamanho ou passam de 15 dígitos, não preencha com zeros, gere de novo a partir da origem.

Resgate um arquivo que já foi salvo com os códigos sem os zeros

Até aqui, cada correção partiu do pressuposto de que o arquivo no disco ainda está correto e apenas a visão do Excel está errada. Mas às vezes a versão sem os zeros já foi salva, e a pergunta passa a ser se os códigos originais ainda podem ser recuperados a partir da cópia salva. A resposta depende exatamente do que o salvamento fez, e há dois casos a distinguir. No primeiro caso, o arquivo no disco ainda guarda os caracteres originais, e apenas a exibição da pasta de trabalho está errada. É o caso que o teste do editor de texto detecta: o editor mostra os zeros, então nada se perdeu, e a Correção 1 repara a visão. No segundo caso, o arquivo no disco agora contém os próprios valores sem os zeros, porque alguém o abriu no Excel, viu os códigos encurtados, e o salvou de volta como CSV, escrevendo os valores convertidos dentro do arquivo.

O segundo caso só é recuperável em circunstâncias restritas. Se cada código tem tamanho fixo e o único dano foi zeros à esquerda descartados, a função TEXTO da Correção 3 os reconstrói, porque os caracteres que faltam são sabidamente zeros. Trabalhe em uma cópia, nunca na única versão, e confira o resultado em um editor de texto antes de abri-lo no Excel de novo. Se o dano for truncamento de precisão, um ID com mais de 15 dígitos cuja parte final foi substituída por zeros, os dígitos originais sumiram daquela cópia. Nenhuma decodificação, formatação ou fórmula consegue recuperar dígitos que foram substituídos por marcadores, porque os marcadores não carregam informação sobre quais dígitos substituíram. Nesse caso, pare de reparar a cópia e gere o arquivo de novo a partir de sua origem: reexporte-o do banco de dados, da ferramenta, ou do JSON de onde ele veio, e desta vez abra-o com a Correção 1. E faça o que fizer, guarde a cópia danificada de lado até o arquivo gerado de novo ser conferido. Apagar a única cópia antes de verificar a substituição é como um problema recuperável vira um conjunto de dados perdido.

O que isso significa para arquivos do conversor desta página

O conversor desta página produz exatamente o tipo de arquivo de que este guia trata, então vale declarar seu comportamento com clareza. O download preserva os códigos exatamente como o JSON os guarda. Isso foi verificado no código real, e não presumido: o motor de conversão foi executado em uma amostra de três linhas com os códigos 00123, 00456, e 00078, os CEPs 02138 e 07477, e o ID de pedido de 18 dígitos 123456789012345678, e produziu cada valor byte a byte idêntico no CSV, com os códigos sem aspas porque não contêm delimitador, e o ID longo intocado. Então, se o seu arquivo convertido mostra códigos sem os zeros no Excel, a conversão não danificou nada. O arquivo está correto, e o Excel adivinhou os tipos ao clicar duas vezes.

Isso dá a você duas opções limpas para arquivos convertidos. A primeira é a rota da importação: abra o arquivo baixado com Dados, depois De Texto/CSV, clique em Transformar Dados, defina cada coluna de código como Texto, e carregue. Os códigos vão ser lidos corretamente, e você não mudou nada no arquivo, então ele continua válido para qualquer outra ferramenta. A segunda é a configuração de conversão automática da Correção 2, para a sua própria máquina. Não converta os dados de novo para corrigir um problema de exibição por adivinhação de tipo, e não passe a saída convertida por uma planilha e a salve de volta, porque essa ida e volta pode introduzir exatamente os desencontros de delimitador, codificação, e tipo que este guia e seus companheiros existem para prevenir. Corrija a abertura, não os dados.

Mais um detalhe do conversor importa aqui. O conversor permite escolher o delimitador antes de baixar, e essa escolha é independente da adivinhação de tipo. Um arquivo pode ter o delimitador certo e códigos sem os zeros ao mesmo tempo, ou os códigos certos e o delimitador errado, ou os dois errados de uma vez. Se o seu arquivo convertido abre em uma única coluna e os códigos parecem errados, corrija as duas configurações na mesma importação: escolha o delimitador que você escolheu no momento da conversão, e defina as colunas de códigos como Texto. O guia companheiro sobre o problema de uma única coluna cobre a metade do delimitador em detalhe, e o guia de codificação cobre a metade dos caracteres, e os dois estão ligados nos guias relacionados abaixo.

Checklist de prevenção: exporte códigos para que ninguém precise corrigi-los

A adivinhação de tipo é um desencontro entre quem escreve e quem lê, então prevenir significa fazer quem escreve declarar o que os valores são, de um jeito que o leitor vai respeitar. Passe por este checklist quando você produzir um CSV, e a próxima pessoa que o abrir não vai precisar deste guia. Primeiro, mantenha os códigos como strings na origem. Se seus dados guardam CEPs, SKUs, ou IDs, armazene-os como texto no sistema de origem, porque um tipo número descarta os zeros antes de qualquer exportação acontecer. Segundo, se o público usa Excel, diga a ele como abrir o arquivo: uma nota de uma linha dizendo para importar com as colunas de códigos definidas como Texto previne o problema inteiro, e não custa nada incluir junto com o arquivo.

Terceiro, nunca salve um arquivo resgatado por cima do original até você ter verificado o resgate em um editor de texto. Um salvamento a partir do Excel reescreve tipos, delimitadores, e codificação com os padrões do próprio Excel, o que pode reintroduzir o desencontro para o próximo leitor, ou transformar um problema de exibição em perda real de dados. Quarto, quando você receber um arquivo, abra-o primeiro em um editor de texto se algo parecer estranho, e confirme os códigos antes de deixar qualquer planilha salvar por cima dele. E quinto, guarde os dados de origem. Um CSV é um retrato achatado, não os dados em si, então se um resgate der errado, a origem permite exportar de novo de forma limpa, em vez de reparar uma cópia danificada. A maioria das histórias de terror com códigos termina com alguém descobrindo tarde demais que o CSV danificado era a única cópia. Não deixe que esse seja o seu arquivo.

Guias relacionados

• CSV abre em uma única coluna no Excel: por que acontece e como corrigir (Guia 2026) →
• Por que seu CSV mostra caracteres estranhos no Excel e como corrigir a codificação (Guia 2026) →
• Como converter JSON em CSV: 3 métodos confiáveis (guia 2026) →
• Por que o Excel altera as datas do seu CSV e como mantê-las (Guia 2026) →
• Por que salvar seu CSV no Excel muda o arquivo e como manter o original seguro (Guia 2026) →
• CSV muito grande para o Excel: por que ele não abre e o que fazer (Guia 2026) →

Perguntas frequentes