Una carta de amor al formato CSV

• Aunque con frecuencia se presentan formatos "superiores" para reemplazar a CSV, la mayoría pasa por alto las verdaderas fortalezas de CSV al basarse en comparaciones sesgadas
• Este texto no dice que CSV sea perfecto, sino que busca destacar sus ventajas subestimadas
• Frente al ambiente en el que odiar a CSV parece verse cool, recuerda su verdadero valor

1. CSV es extremadamente simple

• La definición de CSV es literalmente la de su nombre: "valores separados por comas"
• Las filas se separan por saltos de línea y las columnas por comas
• Si un valor contiene comas o saltos de línea, se encierra entre comillas, y las comillas en sí se representan con comillas dobles
• Cualquiera puede entenderlo y usarlo de forma intuitiva, sin especificaciones complejas
• Aun así, sigue siendo necesario usar un parser de CSV dedicado para un parseo correcto

2. CSV es una idea colectiva

• No tiene propietario ni está privatizado
• Existe el RFC 4180, pero la mayoría lo considera solo una referencia
• Es un formato libre basado en reglas comunes que los desarrolladores de todo el mundo comparten de manera implícita

3. CSV es texto

• Es un formato de texto plano legible por personas, como JSON, YAML o XML
• Puede abrirse con cualquier editor de texto y revisar su contenido sin herramientas adicionales
• También permite elegir libremente la codificación

4. CSV está optimizado para streaming

• Como se lee línea por línea, el consumo de memoria es muy bajo
• Incluso con código simple, es posible procesar varios gigabytes de datos usando solo unos pocos KB de memoria
• Los formatos orientados a columnas, como Parquet, dificultan el procesamiento por streaming y requieren buffering complejo
• Su desventaja es que, aunque solo quieras ver una columna específica, igual tienes que leer toda la fila

5. CSV es fácil de anexar

• Es muy fácil abrir un archivo en modo append(a+) y agregar nuevas filas al final
• En cambio, en formatos orientados a columnas como Parquet, agregar filas es ineficiente y complejo

6. CSV admite tipado dinámico

• Como no tiene tipos fijos, permite interpretar los datos con flexibilidad
• Ejemplo: JavaScript no puede representar correctamente enteros de 64 bits, pero CSV puede usarse sin esa limitación
• Tiene ventajas en compatibilidad y flexibilidad entre lenguajes
• Pero una interpretación incorrecta puede causar errores → hay que usarlo con cuidado
• Si se requiere alto rendimiento, también es posible procesarlo directamente a nivel binario sin decodificar el texto

7. CSV es conciso

• Como el encabezado existe solo al principio del archivo, casi no hay repetición del formato
• JSON y XML tienen mucho overhead por la repetición de claves
• La representación de cadenas ya es compacta, y el overhead del formato en sí (comas, comillas, etc.) es muy bajo

8. Incluso un CSV invertido sigue siendo válido

• CSV sigue siendo un CSV válido incluso si se invierte a nivel de bytes
• Esto se debe al método de escape con comillas dobles, ya que es una forma de escape palindrómica
• Gracias a esta característica, es posible leer de manera muy eficiente la parte final de un archivo CSV
• Ejemplo: al reanudar un proceso interrumpido, basta con leer las últimas líneas del archivo para reiniciarlo

9. A Excel no le gusta CSV

• Si Excel considera incómodo un formato, quizá eso sea una señal de que vas por el camino correcto

[ng0301]

¡Lo simple es lo mejor!

[ethanhur]

¡Peor es mejor!

[GN⁺]

Opinión de Hacker News

• A algunas personas les gustan los archivos CSV e INI porque son simples, basados en texto, no tienen tipos codificados en el formato y están compuestos solo de cadenas

  • Tienen la desventaja de no contar con un estándar oficial, pero cumplen bien su función
  • Alguien guardó como marcador una crítica a INI hecha desde la perspectiva de TOML
  • Cree que la primera línea de esa crítica a TOML también aplica a CSV: es una federación de varios dialectos

• CSV es elegante, pero tiene un defecto fatal: las comillas tienen un efecto "no local"

  • Por ejemplo, una sola comilla en el byte 1 puede cambiar el significado de una coma en el byte 1000000
  • Esto provoca dos consecuencias incómodas
    • Es difícil paralelizar el procesamiento de CSV
    • La corrupción de datos afecta mucho la legibilidad del archivo (una comilla faltante o extra puede arruinar todo)
  • Por eso, hoy en día algunos prefieren un escape simple en lugar de CSV para serializar datos tabulares sencillos

• Lo mejor de CSV es que cualquiera puede escribir un parser en 30 minutos

  • Se pueden importar fácilmente datos de principios de los 90 a un servicio web moderno
  • Lo peor de CSV es que cualquiera puede escribir un parser en 30 minutos
  • Es fácil terminar con implementaciones incorrectas, datos incorrectos y comportamientos extraños no definidos
  • JSON y YAML tienen problemas parecidos
  • XML es algo feo, pero parece ser el más robusto

• Quienes aman CSV probablemente nunca han tenido que encargarse de prevenir inyecciones en CSV en un entorno corporativo

  • Faltan buenos recursos en la web
  • El mejor recurso está <a href="https://georgemauer.net/2017/10/07/csv-injection.html" rel="nofollow">aquí</a>

• Hay muchas razones para que guste CSV

  • Se puede escribir un programa en C que imprima directamente muchas cosas como CSV
  • Se puede escribir un middleware simple que convierta fácilmente a CSV desde casi cualquier base de datos o "cosa" común
  • Puedes meter CSV en Excel y hacer todo lo que quieras
  • También gustan los archivos ini. Se pueden editar directamente en el Bloc de notas
  • Pero sería bueno tener un esquema/estructura general

• Alguien ha estado desarrollando recientemente una solución basada en Raspberry Pi

  • La primera implementación usó una base de datos SQLite, pero se corrompió tras unos días de ciclos de energía
  • Revisó archivos Parquet, pero no son amigables para trabajos append-only
  • Implementó un método para registrar eventos en un archivo IPC y periódicamente hacer un "flush" a archivos Parquet
  • Funciona y es eficiente, pero no es fácil hacerlo bien
  • Para un desarrollador común, CSV (o JSONL) sigue siendo lo mejor

• Lo poco divertido de CSV es que los parsers y serializadores escritos rápido repiten errores comunes al manejar las comillas

  • Durante mucho tiempo alguien desconfió de CSV, pero eso cambió al aprender Python y usar el excelente módulo estándar csv

• Si esto de verdad fuera una carta de amor, habría estado escrita en formato CSV

• La réplica en favor de JSON no resulta muy convincente

  • No hace falta agregar nombres a todos los campos
  • Comparado con CSV, JSON es un poco más grande, pero los corchetes indican la capacidad de ser simple o complejo
  • Como CSV es simple, muchas veces no se usan bibliotecas de parsing/codificación
  • Un parser de JSON siempre produce los valores esperados y el lenguaje probablemente use un parser muy eficiente basado en SIMD
  • También está el problema de la estandarización. Un archivo CSV puede usar comas, espacios, punto y coma, barras verticales, etc.; puede usar CR, LF o CRLF; puede o no permitir escapar comillas, etc.
  • JSON no tiene esos problemas
  • JSON tiene tipos. Tener 6 tipos es mejor que no tener ninguno
  • JSON no es perfecto, pero en general es mejor que CSV

• Como alguien a quien le gustan los formatos modernos, cuando hay dudas usa CSV o JSONL

  • Como en esencia son texto plano, se pueden buscar fácilmente con grep y permiten streaming
  • La mayoría de las funciones enumeradas en el artículo también las comparte JSONL
  • Se comprimen bien con gzip o zstd
  • La compresión elimina parte de las ventajas del texto plano, pero ripgrep también puede buscar en archivos comprimidos
  • Otra ventaja de JSONL es que se puede dividir fácilmente en archivos más pequeños