JSON vs CSV

Forma: una tabla frente a un árbol

Un archivo CSV es una secuencia de registros, cada uno del mismo ancho: nombre, correo, importe, repetido en cada fila. Una fila de encabezados —convencional, no garantizada— nombra las columnas una vez para todo el archivo. Los registros JSON, en cambio, llevan sus claves consigo, así que cada objeto se describe a sí mismo, y un objeto puede contener un array de objetos que contienen arrays. Esa asimetría decide la elección de formato más que cualquier lista de características.

Tipos y entrecomillado: declarados frente a inferidos

En JSON, el tipo de un valor es visible: comillas significan cadena, dígitos desnudos significan número, y true, false y null son tokens exactos. En CSV, el archivo no afirma nada —007 y 7 son ambos texto de celda a secas, y cada consumidor re-infiere los tipos con sus propias reglas—. RFC 4180 sí especifica el entrecomillado con precisión: los campos que contienen comas, comillas dobles o saltos de línea se envuelven en comillas dobles, y las comillas incrustadas se duplican. Los archivos que se saltan esto producen los clásicos bugs de fila rota que toda persona dedicada a la ingeniería de datos ha depurado.

El paso de re-inferencia es donde los datos se corrompen en silencio. Un código postal 02134 se convierte en el número 2134; 1.20 se convierte en 1.2; un número de cuenta largo se convierte en 4.2E+12. JSON tiene la regla espejo —los números no pueden llevar ceros a la izquierda en absoluto, así que un código postal también debe ser una cadena ahí—, pero al menos la declaración es explícita en lugar de ser una adivinanza hecha por la hoja de cálculo de otro.

Excel, datos a granel y dónde gana cada formato

El comportamiento de Excel merece párrafo propio porque quema tantos flujos. Excel abre CSV de forma nativa pero re-tipea cada celda según la configuración regional de la máquina: los ceros a la izquierda desaparecen, las marcas de tiempo ISO acaban destrozadas en fechas locales y en buena parte de Europa manda el dialecto del punto y coma porque la coma es el separador decimal. Al guardar, el archivo se reescribe con esas inferencias horneadas para siempre. JSON nunca pasa por Excel, lo cual ya es una razón para que las integraciones lo prefieran.

A escala, la planitud de CSV es una virtud: las filas se procesan una a una con memoria constante, que es por lo que las exportaciones de varios gigabytes y las herramientas columnares siguen hablando CSV primero. JSON gana donde el consumidor es un programa y la estructura es real: cargas de API, configuración, documentos anidados. Elegir por el consumidor y no por la moda resuelve la mayoría de las discusiones en una frase.

Cuándo elegir cuál — y cómo se comporta la conversión

Elige CSV cuando el destino es tabular: hojas de cálculo, cargas masivas a bases de datos, herramientas de BI y de ciencia de datos. Elige JSON cuando la estructura se anida o el consumidor es código. La recomendación se invierte constantemente en flujos reales: una API devuelve JSON, una persona analista quiere CSV, un proveedor envía CSV que un servicio debe ingerir —la conversión es mantenimiento rutinario, no un proyecto de migración—.

La conversión tiene límites honestos. De JSON a CSV hay que aplanar: un array de objetos se vuelve filas, la unión de sus claves se vuelve columnas, y cualquier array u objeto anidado tiene que convertirse a cadena, unirse o descartarse. De CSV a JSON hay que inferir: las celdas vacías se vuelven null o cadenas vacías, y las celdas con pinta numérica se vuelven números. Los convertidores de este sitio documentan esas reglas exactas en lugar de adivinar en silencio.