Por que seu CSV mostra caracteres estranhos no Excel e como corrigir a codificação (Guia 2026)

Diagnostique em 30 segundos: seus dados não estão danificados, estão apenas mal interpretados

A primeira coisa a estabelecer quando um CSV abre com caracteres estranhos é se os dados estão danificados ou apenas exibidos 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 está 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, ou no Planilhas Google por meio de Arquivo e depois Importar. Se os caracteres parecerem corretos nesses programas, seus dados estão intactos e apenas a exibição no Excel está errada. O arquivo no disco contém os bytes certos, e o Excel está simplesmente decodificando esses bytes com a codificação errada. Esse é o caso comum, e cada correção deste guia parte dele.

A segunda pista é quais caracteres estão errados. Se o texto simples em inglês, os números e a pontuação parecem normais, mas as letras acentuadas, os tremas, as cedilhas, o símbolo do euro e os alfabetos não latinos parecem errados, você está diante de uma incompatibilidade de codificação, não de um problema de delimitador e não de corrupção. Um problema de delimitador coloca linhas inteiras em uma única coluna. A corrupção embaralha tudo ou apaga linhas. Um problema de codificação é cirúrgico: ele quebra exatamente os caracteres que precisam de mais de um byte em UTF-8 e deixa todo o resto intacto. Se o seu arquivo mostra José onde deveria mostrar José, ou München onde deveria mostrar München, esse padrão é a impressão digital de bytes UTF-8 lidos como uma codificação antiga de um único byte, e ele revela tanto a causa quanto a correção.

A terceira verificação decide se o resgate ainda é possível. Se os caracteres embaralhados também aparecem no editor de texto, o próprio arquivo pode ter sido salvo novamente depois da leitura errada, e os caracteres errados podem agora estar gravados no arquivo. Não entre em pânico ainda e, acima de tudo, não salve por cima do original novamente. A seção de resgate mais adiante neste guia trata exatamente desse caso, incluindo a única situação em que os caracteres são realmente irrecuperáveis: quando um caractere foi substituído por um ponto de interrogação ou por um símbolo de substituição durante um salvamento, a informação original desapareceu dessa cópia, e apenas os dados de origem podem gerá-la novamente. Até que você tenha verificado, mantenha o arquivo original intacto, trabalhe em uma cópia e nunca salve um arquivo embaralhado por cima do arquivo bom.

Por que o Excel adivinha errado: um arquivo CSV não traz rótulo de codificação

Para entender por que isso continua acontecendo, você precisa de um fato sobre o formato CSV: um arquivo CSV é texto simples sem nenhum cabeçalho que diga qual codificação ele usa. Um arquivo de planilha traz sua estrutura e sua codificação de texto junto com ele. Um arquivo CSV não traz nenhum dos dois. Ele é apenas bytes, vírgulas e quebras de linha. Quando um programa o abre, o programa precisa decidir como transformar esses bytes em caracteres, e programas diferentes decidem de formas diferentes. Editores de texto modernos e o Planilhas Google detectam UTF-8 automaticamente na maioria dos casos, e por isso o mesmo arquivo parece correto neles. O Excel, quando você clica duas vezes em um arquivo CSV, não detecta. Ele assume a codificação padrão do seu sistema, que em muitos sistemas Windows é uma página de código antiga como Windows-1252, e não verifica se esse palpite estava certo.

Essa suposição é todo o problema. O UTF-8 representa um caractere como é com dois bytes, e um caractere como € com três bytes. Uma codificação antiga de um único byte lê cada byte como um caractere próprio, de modo que um é se torna dois caracteres errados, é, e um € se torna três, €. O arquivo não mudou. O leitor mudou o significado dos bytes. Isso também explica por que o problema segue um padrão por região e por máquina. Um colega em um sistema cuja codificação padrão coincide com a do arquivo vê o arquivo corretamente, enquanto você vê texto embaralhado, e o mesmo arquivo pode parecer normal em um computador e quebrado em outro. Nenhum computador está quebrado, e o arquivo não está corrompido. Os dois leitores simplesmente discordam sobre o que os bytes significam, e o Excel no duplo clique confia no seu próprio padrão sem perguntar.

Isso também explica por que esse problema aparece com tanta frequência em arquivos convertidos a partir de JSON. O JSON é UTF-8 por definição, então uma conversão de JSON para CSV produz naturalmente um CSV em UTF-8, incluindo cada nome acentuado, cidade e símbolo de moeda nos dados de origem. A conversão está correta. A abertura está incompatível. O conversor desta página, por exemplo, baixa UTF-8 simples sem marca de ordem de bytes, o que é a escolha correta para uploads na web, bancos de dados, Planilhas Google e Python, mas significa que um duplo clique no Excel do Windows pode adivinhar a codificação errada. Saber que a incompatibilidade está na etapa de abertura, e não na etapa de conversão, diz onde corrigir: na importação, ou com um BOM, como as próximas seções mostram.

Leia o texto embaralhado: o que os caracteres estranhos revelam

O texto embaralhado não é aleatório, e aprender a lê-lo revela o caractere original e confirma o diagnóstico antes de você tocar em qualquer coisa. O padrão característico é à seguido de outro caractere. Sempre que você vir é, ä, ü ou ç, está olhando para um caractere UTF-8 que foi lido como Windows-1252. O à é o primeiro byte da sequência UTF-8, lido de forma errada como um caractere próprio, e o segundo caractere é o segundo byte, também lido de forma errada. Quando você conhece o padrão, consegue decodificar o texto embaralhado de cabeça: é era é, ü era ü, ç era ç, ão era ão, como em São Paulo aparecendo como São Paulo. O símbolo do euro é o caso mais dramático: € tem três bytes em UTF-8, então aparece como os três caracteres €. Um travessão aparece como â€, e um apóstrofo curvo aparece como ’.

O padrão muda com o alfabeto, e essa mudança também é um diagnóstico. Nomes em alfabeto latino produzem o padrão à descrito acima. O japonês, o coreano e outros alfabetos não latinos produzem texto embaralhado mais longo, porque cada caractere tem três bytes em UTF-8, então um caractere se torna três caracteres errados: Tóquio escrito como 東京 aparece como uma sequência de caracteres como æ±äº¬, e um nome coreano se torna uma sequência parecida. Se você vir esse tipo de texto embaralhado longo, o diagnóstico é o mesmo, UTF-8 lido como uma codificação de um único byte, apenas os caracteres envolvidos são de três bytes. Se, em vez disso, você vir pontos de interrogação ou símbolos de substituição em forma de losango preto onde deveriam estar caracteres, o diagnóstico é diferente: esses símbolos significam que a informação já foi perdida durante um salvamento, e não apenas lida de forma errada durante a exibição, e a seção de resgate trata do que fazer nesse caso.

O bloco de código abaixo mostra as leituras erradas exatas, produzidas ao pegar texto UTF-8 correto e decodificá-lo como Windows-1252, da mesma forma que o Excel faz no duplo clique. Esses não são exemplos inventados. Cada par foi gerado de forma mecânica, então você pode comparar seu próprio arquivo com eles e confirmar o diagnóstico antes de corrigir qualquer coisa. Se o seu arquivo mostra o lado esquerdo de um desses pares onde deveria mostrar o lado direito, você tem uma incompatibilidade de codificação, e a correção por importação na próxima seção vai reparar a exibição sem alterar o arquivo.

Correct text  ->  What Excel shows\nJosé García  ->  José GarcÃ\u00ada\nMünchen      ->  München\nFrançois     ->  François\nSão Paulo    ->  São Paulo\n€50,000      ->  €50,000\ncafé — ok    ->  café — ok\n東京 (Tokyo)  ->  æ\u00b1京\n김민준        ->  김민준

Observe o que a tabela prova: nada está faltando. Cada caractere errado corresponde a um byte real do original, apenas decodificado com a tabela errada. É por isso que a correção por importação funciona de forma tão completa. Quando você diz ao Excel que o arquivo é UTF-8, ele decodifica os mesmos bytes com a tabela certa, e cada caractere volta a ser ele mesmo, sem edição, sem localizar e substituir e sem digitação de dados. Se o seu arquivo segue esse padrão, pule a seção de resgate 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.

Correção 1: importe o arquivo e diga ao Excel que ele é UTF-8

Esta é a correção a tentar primeiro, porque ela não muda nada no seu sistema, nada no arquivo, e funciona em qualquer CSV em UTF-8, qualquer que seja o seu delimitador. Em vez de clicar duas vezes no arquivo, abra o Excel primeiro e depois importe o arquivo pela importação guiada, onde você escolhe a codificação. A pré-visualização na caixa de diálogo de importação mostra imediatamente se você escolheu certo: os caracteres aparecem corretamente na pré-visualização exatamente como aparecerão na planilha. Se a pré-visualização ainda mostrar texto embaralhado, você ainda não mudou nada, e pode tentar outra origem de arquivo antes de carregar.

• ▸No Excel, vá em Dados, depois em De Texto/CSV, e selecione seu arquivo.
• ▸Na caixa de diálogo de pré-visualização, defina a origem do arquivo como 65001: Unicode (UTF-8). Em versões mais antigas do Excel, a mesma opção aparece como Unicode (UTF-8) no Assistente de Importação de Texto.
• ▸Verifique a pré-visualização. Se os caracteres agora aparecem corretamente, continue. Se ainda parecerem errados, o arquivo pode não ser UTF-8, então tente as outras origens da lista uma de cada vez e observe a pré-visualização.
• ▸Defina o delimitador como o caractere que o arquivo usa, vírgula, ponto e vírgula, tabulação ou barra vertical, e verifique se as colunas se dividem corretamente na mesma pré-visualização.
• ▸Clique em Carregar. Para colunas que precisam continuar como texto, como códigos com zeros à esquerda, defina essas colunas como Texto na etapa de importação, antes de carregar.

Faça disso sua forma padrão de abrir arquivos CSV, e não apenas seu recurso de resgate. O duplo clique é um palpite sobre o delimitador e sobre a codificação. A importação é uma escolha sobre os dois, e a escolha leva cerca de dez segundos a mais. A mesma correção funciona no Mac, onde a rota de importação também é a confiável: abra uma pasta de trabalho em branco, vá em Dados, depois em De Texto, escolha o arquivo, selecione Unicode (UTF-8) como origem do arquivo e conclua. O Planilhas Google não precisa de nenhuma correção na maioria dos casos, porque Arquivo e depois Importar detectam UTF-8 automaticamente, e por isso um arquivo que parece quebrado no Excel muitas vezes parece perfeito no Planilhas. Essa diferença é, por si só, um diagnóstico: se o Planilhas mostra certo e o Excel mostra errado, o arquivo está bom e o Excel adivinhou errado.

Correção 2: adicione um BOM para que o duplo clique funcione

Se você abre o mesmo tipo de arquivo todos os dias, importar cada vez se torna cansativo, e a correção duradoura é dar ao Excel a dica de que ele precisa no duplo clique. Essa dica é um BOM, uma marca de ordem de bytes: três bytes invisíveis no início do arquivo que dizem que este arquivo é UTF-8. O Excel verifica se há um BOM antes de adivinhar, então um arquivo UTF-8 com BOM abre corretamente no duplo clique mesmo em um sistema Windows cuja codificação padrão é Windows-1252. O BOM é invisível no Excel e na maioria dos editores, e não muda nenhuma linha de dados. Ele afeta apenas os três primeiros bytes do arquivo.

A forma mais fácil de adicionar um BOM não precisa de código. Abra o arquivo no Bloco de Notas, vá em Arquivo, depois em Salvar Como, e defina o menu de codificação como UTF-8 com BOM, depois salve. O arquivo agora abre corretamente no duplo clique no Excel. Se você produz arquivos a partir de um script, adicione o BOM no momento da gravação em vez de corrigir arquivos depois. Em Python, isso é uma palavra: abra o arquivo com a codificação utf-8-sig em vez de utf-8, e o Python grava o BOM para você. O trecho abaixo mostra isso, e os bytes que ele produz foram verificados: o arquivo começa com os três bytes do BOM, seguidos pelos dados em UTF-8 simples.

with open("customers.csv", "w", encoding="utf-8-sig", newline="") as f:\n    f.write("name,city\n")\n    f.write("José García,München\n")\n# First bytes of the file: EF BB BF, then the UTF-8 data.\n# Excel now opens it correctly on double-click.

Duas precauções antes de adicionar um BOM em todos os lugares. Primeiro, algumas ferramentas tratam um BOM como dado, e não como marcador. Um analisador de CSV rigoroso pode ler o primeiro cabeçalho como BOM mais nome em vez de nome, o que quebra uma busca por cabeçalho. O conversor desta página baixa deliberadamente sem BOM exatamente por esse motivo: UTF-8 simples é correto para uploads na web, bancos de dados e Python, e o BOM é apenas uma conveniência para o duplo clique no Excel. Portanto, adicione um BOM às cópias destinadas ao Excel, e não ao arquivo principal que alimenta outras ferramentas. Segundo, um BOM não repara um arquivo que não é UTF-8. Se o arquivo foi escrito em Windows-1252, adicionar um BOM por cima dele piora as coisas, porque o Excel vai decodificar dados de um único byte como UTF-8 e produzir novo texto embaralhado. Adicione um BOM apenas a um arquivo que você sabe que é UTF-8, o que você pode confirmar com o teste do editor de texto da seção de diagnóstico.

Recupere um arquivo que já parece embaralhado

Até aqui, cada correção assumiu que o arquivo no disco continua correto e apenas a exibição está errada. Mas às vezes a versão embaralhada já foi salva, e a pergunta passa a ser se os caracteres 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 contém os bytes UTF-8 originais, e apenas a exibição no Excel está errada. Esse é o caso que o teste do editor de texto detecta: o editor mostra os caracteres corretamente, então nada foi perdido, e a Correção 1 repara a exibição. No segundo caso, o arquivo no disco agora contém os próprios caracteres errados, porque alguém o abriu no Excel, viu o texto embaralhado e o salvou de volta como CSV, gravando os caracteres lidos de forma errada no arquivo.

O segundo caso muitas vezes ainda é recuperável, e o teste é se o texto embaralhado segue o padrão à da seção do decodificador. Se o arquivo salvo contém literalmente os caracteres é onde é deveria estar, a recuperação é uma recodificação: leia o arquivo como se ele fosse Windows-1252, o que recupera os bytes UTF-8 originais, e depois decodifique esses bytes como UTF-8, o que recupera os caracteres originais. O trecho abaixo faz exatamente isso, e foi verificado em um arquivo real: um nome escrito como José, lido de forma errada como José, voltou a ser José depois da ida e volta, byte por byte. Trabalhe em uma cópia, nunca na única versão, e verifique o resultado em um editor de texto antes de abri-lo novamente no Excel.

with open("mangled.csv", "r", encoding="cp1252") as f:\n    text = f.read()\n# Encode back to the bytes Excel misread, then decode as UTF-8.\nfixed = text.encode("cp1252").decode("utf-8")\nwith open("fixed.csv", "w", encoding="utf-8") as f:\n    f.write(fixed)\n# Verified: José -> José, München -> München.

O truque da recodificação tem um limite rígido, e é importante respeitá-lo. Ele funciona apenas quando os caracteres lidos de forma errada sobreviveram ao salvamento intactos, como é e seus companheiros. Se o salvamento substituiu caracteres por pontos de interrogação, ou pelo símbolo de substituição em forma de losango preto, a informação original desapareceu dessa cópia. Nenhuma decodificação consegue recuperar um caractere que foi substituído por um marcador, porque o marcador não carrega nenhuma informação sobre qual caractere ele substituiu. Nesse caso, pare de reparar a cópia e gere o arquivo novamente a partir de sua origem: exporte-o novamente do banco de dados, da ferramenta ou do JSON de onde ele veio, e desta vez abra-o com a Correção 1 ou dê a ele um BOM com a Correção 2. E, faça o que fizer, mantenha a cópia danificada guardada até que o arquivo gerado novamente seja verificado. Apagar a única cópia antes de verificar o substituto é como um problema recuperável se torna 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 a pena declarar seu comportamento de forma clara. O download é UTF-8 simples sem BOM. Isso foi verificado no código real, e não presumido: o download cria um Blob text/csv com charset=utf-8 e não grava nenhuma marca inicial, e o mecanismo de conversão em si foi executado em uma amostra contendo José García, München, François, Łódź, São Paulo, um valor em euros, Tóquio em japonês e nomes coreanos, e produziu cada caractere de forma idêntica em bytes, sem BOM no início da saída. Portanto, se o seu arquivo convertido mostra caracteres estranhos no Excel, a conversão não danificou nada. O arquivo é UTF-8 correto, e o Excel adivinhou a codificação errada no duplo clique.

Isso oferece duas opções limpas para arquivos convertidos. A primeira é a rota de importação: abra o arquivo baixado com Dados, depois De Texto/CSV, defina a origem do arquivo como 65001: Unicode (UTF-8) e carregue. Os caracteres vão aparecer corretamente, e você não mudou nada no arquivo, então ele continua válido para qualquer outra ferramenta. A segunda é a rota do BOM: abra o arquivo baixado no Bloco de Notas, salve-o como UTF-8 com BOM e guarde essa cópia para o Excel, mantendo o download original para qualquer outra coisa. Não converta os dados novamente para corrigir um problema de exibição de codificação, e não cole a saída convertida em uma planilha e salve-a de volta, porque essa ida e volta pode introduzir exatamente as incompatibilidades de delimitador e codificação que este guia existe para prevenir. Corrija a abertura, e 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 codificação. Um arquivo pode ter o delimitador certo e a exibição de codificação errada ao mesmo tempo, ou a codificação certa e o delimitador errado, ou os dois errados ao mesmo tempo. Se o seu arquivo convertido abre em uma única coluna e os caracteres parecem errados, corrija as duas configurações na mesma importação: escolha o delimitador que você selecionou no momento da conversão e defina a origem do arquivo como 65001. O guia complementar sobre o problema de uma única coluna trata da metade do delimitador em detalhes, e está linkado nos guias relacionados abaixo.

Lista de prevenção: exporte corretamente para ninguém precisar corrigir

Problemas de codificação são uma incompatibilidade entre quem escreve e quem lê, então a prevenção significa fazer com que quem escreve declare o que escreveu, de uma forma que o leitor vá respeitar. Passe por esta lista quando produzir um CSV, e a próxima pessoa que o abrir não vai precisar deste guia. Primeiro, saiba sua codificação no momento da exportação. Se seus dados contêm qualquer coisa além de ASCII simples, exporte como UTF-8 e diga isso no nome do arquivo ou na nota que acompanha o arquivo, porque um arquivo CSV não consegue dizer isso por si só. Segundo, se o público é o Excel no Windows, adicione um BOM à cópia para Excel, ou exporte com o formato CSV UTF-8 do Salvar Como do Excel, que grava um BOM para você. Terceiro, se o arquivo também alimenta outras ferramentas, guarde uma cópia em UTF-8 simples sem BOM para elas, porque alguns analisadores tratam um BOM como parte do primeiro cabeçalho.

Quarto, nunca salve um arquivo resgatado por cima do original até que você tenha verificado o resgate em um editor de texto. Um salvamento a partir do Excel reescreve o delimitador e a codificação com os padrões próprios do Excel, o que pode reintroduzir a incompatibilidade para o próximo leitor, ou transformar um problema de exibição em perda real de dados. Quinto, quando receber um arquivo, abra-o primeiro em um editor de texto se algo parecer estranho, e confirme a codificação antes de deixar qualquer planilha salvar por cima dele. E sexto, guarde os dados de origem. Um CSV é um instantâneo achatado, e não os próprios dados, então se um resgate der errado, a origem permite exportar novamente de forma limpa em vez de reparar uma cópia danificada. A maioria das histórias de terror sobre codificação 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) →
• Como posso converter um arquivo JSON em CSV online? (Guia 2026) →
• Quais São as Formas de Converter JSON para CSV Localmente? 6 Métodos, Comparados (Guia 2026) →
• Por que o Excel apaga os zeros à esquerda dos seus códigos em CSV e como mantê-los (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