Uma carta de amor ao formato CSV

• Formatos “superiores” para substituir o CSV são apresentados com frequência, mas a maioria ignora os verdadeiros pontos fortes do CSV com base em comparações tendenciosas
• Este texto não diz que o CSV é perfeito, mas busca destacar vantagens subestimadas
• Em contraste com o clima em que odiar CSV parece algo “cool”, ele relembra o verdadeiro valor do CSV

1. CSV é extremamente simples

• A definição de CSV está no próprio nome: “valores separados por vírgula”
• As linhas são separadas por quebras de linha, e as colunas por vírgulas
• Quando um valor contém vírgula ou quebra de linha, ele é colocado entre aspas, e as próprias aspas são representadas com aspas duplas
• Sem uma especificação complexa, qualquer pessoa pode entender e usar de forma intuitiva
• Ainda assim, para um parsing correto, continua sendo necessário usar um parser de CSV dedicado

2. CSV é uma ideia coletiva

• Não tem proprietário, não foi privatizado
• O RFC 4180 existe, mas a maioria o trata apenas como referência
• É um formato livre, baseado em regras comuns compartilhadas implicitamente por desenvolvedores do mundo todo

3. CSV é texto

• Assim como JSON, YAML e XML, é um formato de texto puro legível por humanos
• Pode ser aberto em qualquer editor de texto, e o conteúdo pode ser verificado sem ferramentas adicionais
• O esquema de codificação também pode ser escolhido livremente

4. CSV é otimizado para streaming

• Como sua estrutura é lida linha por linha, o consumo de memória é muito baixo
• Mesmo com código simples, é possível processar vários gigabytes de dados usando apenas alguns KB de memória
• Formatos colunares como Parquet são difíceis de processar em streaming e exigem buffering complexo
• A desvantagem é que, mesmo quando se quer ver apenas uma coluna específica, é preciso ler a linha inteira

5. CSV é fácil de anexar

• É muito fácil abrir um arquivo em modo append (a+) e adicionar novas linhas ao final
• Já formatos colunares como Parquet tornam a adição de linhas ineficiente e complexa

6. CSV oferece suporte a tipagem dinâmica

• Como não há tipos fixos, é possível interpretar os dados com flexibilidade
• Exemplo: JavaScript não consegue representar corretamente inteiros de 64 bits, mas o CSV pode ser usado sem essa limitação
• Isso traz vantagens em compatibilidade entre linguagens e flexibilidade
• Mas, se for interpretado incorretamente, pode gerar erros → é preciso cuidado ao usar
• Quando é necessário alto desempenho, também é possível processar diretamente em nível binário, sem decodificar o texto

7. CSV é conciso

• Como o cabeçalho existe apenas no início do arquivo, quase não há repetição estrutural
• JSON e XML têm muito overhead por causa da repetição de chaves
• A representação de strings já é concisa, e o overhead do próprio formato (vírgulas, aspas etc.) é muito pequeno

8. Até um CSV invertido continua válido

• Mesmo invertido em nível de bytes, um CSV ainda é um CSV válido
• Isso é possível graças à forma de escape com aspas duplas, que funciona como um esquema de escape palindrômico
• Essa característica permite ler o final de um arquivo CSV com muita eficiência
• Exemplo: ao retomar um processo interrompido, é possível reiniciar lendo apenas as últimas linhas do arquivo

9. O Excel odeia CSV

• Se o Excel considera um formato inconveniente, talvez isso seja até um sinal de que você está no caminho certo

[ng0301]

O simples é o melhor!

[ethanhur]

Pior é melhor!

[GN⁺]

Opiniões no Hacker News

• O motivo de gostar de arquivos CSV e INI é que eles são simples, baseados em texto, não têm tipos codificados no formato e são compostos apenas por strings

  • Há a desvantagem de não existir um padrão oficial, mas eles cumprem bem seu papel
  • Guardei nos favoritos uma crítica ao INI em relação ao TOML
  • Acho que a primeira linha da crítica ao TOML também se aplica ao CSV: é uma federação de vários dialetos

• CSV é elegante, mas tem uma falha fatal: as aspas têm um efeito "não local"

  • Por exemplo, uma única aspa no byte 1 pode mudar o significado de uma vírgula no byte 1000000
  • Isso causa duas consequências incômodas
    • É difícil paralelizar o processamento de CSV
    • A corrupção de dados afeta fortemente a legibilidade do arquivo (a falta ou adição de uma única aspa pode arruinar tudo)
  • Por isso, hoje em dia, para serialização simples de dados tabulares, prefiro escaping simples em vez de CSV

• A melhor coisa do CSV é que qualquer pessoa consegue escrever um parser em 30 minutos

  • Dá para importar facilmente dados do começo dos anos 90 para um serviço web moderno
  • A pior coisa do CSV é que qualquer pessoa consegue escrever um parser em 30 minutos
  • Implementações erradas, dados incorretos e comportamentos estranhos e indefinidos tendem a aparecer com facilidade
  • JSON e YAML também têm problemas parecidos
  • XML é um pouco feio, mas parece ser o mais robusto

• Quem gosta de CSV provavelmente nunca recebeu, em um ambiente corporativo, a tarefa de lidar com prevenção de injeção em CSV

  • Faltam bons recursos na web
  • O melhor recurso é <a href="https://georgemauer.net/2017/10/07/csv-injection.html" rel="nofollow">este aqui</a>

• Existem vários motivos para gostar de CSV

  • Dá para escrever programas em C e fazer a saída de várias coisas diretamente em CSV
  • Dá para escrever um middleware simples que converta facilmente para CSV a partir de praticamente qualquer banco de dados ou "coisa" comum
  • Você pode jogar o CSV no Excel e fazer tudo o que quiser
  • Também gosto de arquivos ini. Dá para editar diretamente no Bloco de Notas
  • Mas eu gostaria que houvesse uma visão geral/estrutura mais comum

• Recentemente estou desenvolvendo uma solução baseada em Raspberry Pi

  • A primeira implementação usava um banco de dados SQLite, mas corrompeu depois de alguns dias de ciclos de energia
  • Dei uma olhada em arquivos Parquet, mas eles não são amigáveis para trabalho append-only
  • Implementei uma abordagem de registrar eventos em um arquivo IPC e periodicamente fazer um "flush" para um arquivo Parquet
  • Funciona e é eficiente, mas não é fácil implementar direito
  • Para o desenvolvedor comum, CSV (ou JSONL) ainda é o melhor

• O lado sem graça do CSV é que parsers e serializadores escritos às pressas repetem erros comuns de lidar mal com aspas

  • Fiquei desconfiado de CSV por muito tempo, mas mudei de ideia ao aprender Python e usar o excelente módulo padrão csv

• Se isto fosse realmente uma carta de amor, teria sido escrita em formato CSV

• A contestação ao JSON não é muito convincente

  • Não é necessário adicionar nomes a todos os campos
  • Comparando CSV e JSON, JSON é um pouco maior, mas os colchetes indicam a capacidade de ser simples ou complexo
  • Como CSV é simples, muitas vezes as pessoas não usam bibliotecas de parsing/encoding
  • Um parser JSON sempre produz os valores esperados, e a linguagem provavelmente usa um parser muito eficiente baseado em SIMD
  • Também existe o problema da padronização. Há questões como: o arquivo CSV usa vírgulas, espaços, ponto e vírgula, pipe etc.; usa CR, LF ou CRLF; permite escapar aspas, e assim por diante
  • JSON não tem esses problemas
  • JSON tem tipos. Ter 6 tipos é melhor do que não ter nenhum
  • JSON não é perfeito, mas em geral é melhor que CSV

• Como alguém que gosta de formatos modernos, quando há dúvida uso CSV ou JSONL

  • Como é principalmente texto puro, dá para procurar facilmente com grep e fazer streaming
  • A maioria dos recursos listados no documento também vale para JSONL
  • Comprime bem com gzip ou zstd
  • A compressão remove parcialmente as vantagens do texto puro, mas o ripgrep também consegue pesquisar arquivos comprimidos
  • Outra vantagem do JSONL é que ele pode ser facilmente dividido em arquivos menores