Convertir CSV a NDJSON

El motivo habitual para pedir esta conversión no es la elegancia. Es que tienes once volcados mensuales, en abril el sistema añadió un campo, y no hay forma de juntar un archivo de catorce columnas con otro de quince. Al concatenar los CSV queda una fila de cabecera en mitad de los datos, y aunque la borres los campos ya no cuadran.

NDJSON no tiene ese problema. Registros con conjuntos de claves distintos conviven en el mismo archivo con toda legitimidad, y cualquier consumidor razonable —un motor de consultas, un trabajo de carga, un script— trata una clave ausente como ausente y no como fila rota. Convierte cada exportación por separado, une los resultados, y la diferencia de esquema pasa de ser un fallo estructural a ser un dato de cada registro.

Un CSV nombra sus columnas una sola vez y a partir de ahí todo es posicional: el tercer campo es la ciudad porque el tercer encabezado lo dijo. NDJSON hace lo contrario. Cada línea es un objeto completo que lleva sus propias claves, así que el registro setenta mil se entiende exactamente igual que el primero.

Ese es el intercambio y no sale gratis. Repetir los nombres en cada línea agranda el archivo, a veces bastante cuando los valores son cortos y los encabezados largos. Lo que compras es que ninguna línea dependa de otra, y de ahí salen todas las demás propiedades de esta página.

El lector deduce los tipos, porque un CSV no tiene ninguno: lo que parece un número se convierte en número. Con cantidades, precios y medidas eso es exactamente lo que quieres. Con un código postal español es un desastre silencioso, porque las provincias 01 a 09 —Álava, Albacete, Alicante, Almería, Ávila, Badajoz, Baleares, Barcelona y Burgos— escriben todas un cero delante.

Así, 08001 llega al NDJSON como 8001 y 01001 como 1001. No es un caso raro en una tabla de clientes española: es del orden de una quinta parte de las filas. Lo mismo le pasa a cualquier referencia con relleno de ceros, a un número de pedido largo que se va a coma flotante y pierde la última cifra, y a una columna con valores como VERDADERO o NO que acaba en booleanos cuando era texto.

Hay una regla sencilla que resuelve casi todos los casos: pregúntate si sumar dos valores de esa columna significaría algo. La suma de dos importes tiene sentido; la de dos códigos postales, dos NIF o dos números de factura no. Lo segundo es un identificador y quería seguir siendo texto.

La defensa más barata es en el origen, antes de que ninguna conversión lo vea: exportar esa columna como texto desde el sistema que la genera, o darle un prefijo que la haga inequívoca. Una vez que en el JSON hay un número, no queda nada de donde recuperar el cero perdido, porque el cero no está representado en ningún sitio.

Es una decisión real y conviene conocerla, porque las dos cosas no son iguales para nada de lo que consuma el archivo. Un esquema JSON que declara una cadena rechaza un null, y una carga en base de datos escribirá un valor nulo donde tú esperabas la cadena vacía que veías en la hoja de cálculo.

Lo que la conversión no puede hacer es adivinar cuál de las dos quería decir la exportación. Un CSV tiene una única manera de escribir «aquí no hay nada», y se usa tanto para «este campo está en blanco» como para «este campo no aplica». Si la distinción importa aguas abajo, hay que codificarla explícitamente en el origen: un valor centinela, o una segunda columna.

Como un registro termina donde termina la línea, el archivo se puede partir por cualquier salto de línea y las dos mitades siguen siendo válidas. Se generan trozos cargables con una orden de división; se saca una muestra con las mil primeras líneas para probarla contra un esquema; y una carga fallida se reanuda desde un número de línea en vez de empezar de nuevo.

Añadir funciona por la misma razón: los registros nuevos van al final y nada de lo anterior hay que reescribirlo. Hacer el equivalente sobre un CSV obliga a comprobar si la cabecera está o no, si el orden de columnas coincide y si la última línea terminaba en un salto, y equivocarse en cualquiera de las tres corrompe el archivo en silencio en lugar de en voz alta.

La salida no está formateada con saltos internos ni con espacios de indentación, y no podría estarlo. Un JSON indentado rompería a todos los consumidores del formato, que asumen que un salto de línea marca el final de un registro y el principio del siguiente.

Si lo que buscabas era un archivo legible de un vistazo, lo que quieres es un JSON normal con su array y su sangrado, y ese es otro destino de este mismo sitio. NDJSON está pensado para leerse con herramientas, no con los ojos, y su virtud es exactamente esa uniformidad tediosa.

Nada en la conversión ordena. Las filas salen en el orden en que estaban en el CSV, y dentro de cada objeto las claves aparecen en el orden en que las declaraba la cabecera. Eso significa que un archivo ordenado por fecha sigue ordenado por fecha, y que un diff entre dos conversiones del mismo origen no se llena de ruido por reordenaciones.

Es una propiedad pequeña que se agradece en dos sitios concretos: al revisar un cambio en un control de versiones, donde una salida estable produce diferencias legibles; y al comparar dos exportaciones consecutivas para ver qué se movió, que es la operación por la que muchos llegan a este formato en primer lugar.

El formato está hecho para procesadores de JSON que leen valor a valor sin cargar el archivo entero en memoria: extraer una columna, contar registros, filtrar y producir otro NDJSON que sigue siendo entrada válida para todo lo demás.

Lo mismo vale para cualquier utilidad que trabaje por líneas. Buscar un texto sobre el archivo en bruto es honesto, porque un registro no puede abarcar dos líneas ni partirse en mitad de una coincidencia. Y contar líneas da el número exacto de registros, algo que sobre un CSV no es cierto en cuanto una dirección entrecomillada contenga un salto de línea.

Cuenta con que crezca. Cada línea repite los nombres de las claves, cada cadena va entrecomillada y a los valores se les añade la puntuación de un objeto. En una tabla de códigos cortos con encabezados descriptivos el archivo puede duplicarse; en una de campos largos de texto libre la diferencia es pequeña, porque mandan los valores.

La compresión cierra casi toda la brecha, porque las claves repetidas son justo lo que mejor comprime un compresor, y un NDJSON comprimido queda cerca de un CSV comprimido con los mismos datos. Si lo que de verdad importa es el tamaño en reposo y no la forma de flujo, esa es la señal para mirar hacia Parquet, donde los nombres de columna se guardan una vez en el pie del archivo.

NDJSON es una forma de envoltorio, no un contrato. El destino que ingiere líneas JSON seguirá teniendo opinión sobre los nombres de campo, sobre el formato de las fechas y sobre si un nulo está permitido en tal posición, y ninguna de esas cosas la decide esta conversión.

Las dos que más disgustos dan son las fechas y los identificadores. Una fecha en un CSV es texto y sigue siendo texto, así que llega la cadena que escribió el sistema de origen: si esa cadena es 03/04/2024, la ambigüedad entre día y mes viaja con ella. Los identificadores, como ya se ha dicho, pueden haberse vuelto números. Las dos se corrigen barato en una pasada sobre el archivo convertido y caro después de la carga.

Leer el CSV y escribir las líneas JSON son ambas JavaScript corriente, cargado por esta página bajo demanda. Ninguna petición transporta el archivo, así que un volcado nocturno de clientes o un extracto de facturación se convierte sin convertirse además en la copia de otro.

La capa gratuita se detiene en 100 MB por archivo y cien archivos por lote; por debajo de eso el techo es la memoria. La tabla entera se construye antes de escribir nada, lo cual deja decenas de megabytes cómodamente dentro y pone el último tramo hasta los 100 MB donde una pestaña empieza a sufrir. Para una exportación mayor, lo correcto es un lector en flujo dentro de un script, y dado que el destino es un flujo, escribir ese script suele ser el final razonable de la historia.