Convertir XLSX a NDJSON

Un array JSON es un único valor. Para leer el último objeto hay que haber analizado todo lo anterior, lo que obliga a sostener el documento entero en memoria o a recurrir a un analizador en flujo que entienda estructuras a medias. Para un archivo de configuración eso da igual. Para cuatro millones de filas es la diferencia entre una importación que termina y un proceso que el sistema operativo mata.

El JSON delimitado por saltos de línea elimina el problema quitando el envoltorio. Cada línea es un valor JSON completo e independiente, así que quien lo consume lee una, hace algo con ella, la descarta y sigue con un consumo de memoria constante. Y una carga que falla en el registro ochocientos mil se reanuda desde esa línea, mientras que un documento que no se analiza no da nada y ni siquiera dice qué registro tenía la culpa.

Es la diferencia que más se agradece si vienes de pelearte con un CSV. Un CSV no declara en qué codificación está escrito, y de ahí sale el clásico apellido con tilde convertido en símbolos, la eñe rota y la marca de orden de bytes que arregla Excel y estropea el importador.

JSON no tiene esa conversación pendiente: la especificación fija la codificación y el texto viaja como texto Unicode, sin marca al principio y sin nada que adivinar. Un `Núñez`, un `Muñoz` o una dirección con `Alcalá` llegan al destino escritos como estaban, y si el cargador los muestra mal, el problema está en el cargador y no en un byte ambiguo del archivo.

La garantía sólo se sostiene si nada en los datos puede producir un salto de línea propio. Una celda con un salto dentro —una dirección en dos líneas, un comentario que alguien escribió con Alt+Intro— se escribe con ese salto escapado dentro de la cadena JSON, así que el registro se queda en su línea. Un tabulador dentro de una celda se trata igual.

Ésa es la ventaja concreta sobre un archivo delimitado. Una exportación separada por tabuladores tiene que envolver la celda incómoda entre comillas y confiar en que quien la lea implemente el convenio; aquí no hay convenio que implementar. Trocear el archivo en pedazos de diez mil líneas es seguro, contar líneas te da el número de registros, y ninguna fila puede corromperse por culpa de la anterior.

Un archivo delimitado tiene un solo tipo: texto. Lo que lo lea tiene que adivinar, y adivinar es donde un identificador se convierte en entero y un número de versión en decimal. JSON expresa la distinción, así que una cantidad se escribe como `12`, un indicador como `true`, una celda vacía como `null` y un código de artículo que era texto en la hoja se mantiene entrecomillado con sus ceros delante.

Para una carga en un destino con tipos eso ahorra tiempo real. El esquema que declaras y los valores que aportas coinciden sin una capa de conversión en medio, y un trabajo de ingesta que rechaza una fila te dice qué campo no encajaba en lugar de un error de análisis en un número de línea. Además los tipos vienen del libro y no de una inferencia sobre texto, que es la parte importante.

Una celda que en pantalla dice `1.234,56` se escribe en el archivo como `1234.56`. No es una conversión de idioma: es que en JSON un número sólo se puede escribir de una manera, con punto decimal y sin separador de millares, y el valor que sale es el mismo que había.

Eso resuelve de golpe un problema clásico de las cargas hechas desde España o desde Argentina, donde un CSV con comas decimales y punto y coma como separador obliga a configurar el destino columna por columna. Aquí no hay nada que configurar, porque no hay ambigüedad que resolver. Quien mire el archivo con ojos de hoja de cálculo dirá que las cifras están cambiadas; están, simplemente, sin disfraz.

Un flujo de registros no tiene manera de decir «y ahora empieza otra tabla», así que se lee la primera hoja del libro y ninguna otra. Con ella se quedan atrás las fórmulas —de las que llega el resultado guardado—, el formato, los anchos de columna y todo lo que no sea el valor de una celda.

Si la hoja que necesitas no es la primera, muévela al principio y vuelve a convertir. Si necesitas varias, conviértelas por separado y cárgalas como flujos distintos, que además es lo que el destino va a querer: fusionar dos tablas dentro de un mismo archivo de líneas produce registros que hay que distinguir después por un campo que nadie ha puesto.

Una celda en blanco se escribe explícitamente como `null` en lugar de omitir la clave, de modo que todos los objetos llevan el mismo juego de campos y un consumidor que espera una forma fija la encuentra en todas las líneas.

Es una decisión con consecuencias en las dos direcciones. Un cargador con esquema lo agradece, porque no tiene que tratar como caso especial la fila a la que le falta la columna de la que nadie rellenó nada. Uno que distinga «vacío» de «no informado» necesitará una pasada previa, porque en la hoja esas dos cosas eran la misma celda en blanco.

Una hoja no guarda las fechas como fechas: guarda un número al que le pone un formato encima para que se lea así. Por eso, en una carga automática, la columna de fechas es siempre la primera que hay que abrir en el resultado antes de dejar correr el proceso completo.

La forma de dejar de depender de ello se hace una sola vez y aguas arriba: da formato de texto a esa columna en el libro y escribe las fechas en ISO, `2026-03-15`. El archivo pasa a describirse a sí mismo, cruza cualquier conversión sin ambigüedad y evita el peor final posible, que es un cargador con una columna numérica aceptando sin rechistar un valor que nadie ha comprobado.

Cada línea repite todos los nombres de campo. Cincuenta mil filas de seis columnas son cincuenta mil copias de esos seis nombres, y el archivo resultante es sensiblemente mayor que la misma información separada por tabuladores.

Ese intercambio suele compensar en este destino, porque el archivo lo va a leer una máquina una vez y no un humano muchas. Y en tránsito casi ni se paga: las claves repetidas son lo más comprimible que hay dentro, así que un `gzip` camino del almacén se lleva por delante casi todo el sobrecoste que describe este párrafo. Si los mismos registros van a consultarse una y otra vez, el formato correcto no es éste sino uno columnar.

Las herramientas salen solas de la forma del archivo. `wc -l` da el número exacto de filas, porque hay un registro por línea y un salto al final. `head -1` enseña los nombres de campo tal y como se escribieron y no como los recuerdas. `split -l 10000` produce trozos que son válidos cada uno por su cuenta.

Para algo más, `jq` lee una sucesión de valores en lugar de un documento, así que `jq -c "select(.importe > 100)"` filtra un archivo más grande que la memoria y emite el mismo formato que consumió. Es además la manera más barata de inspeccionar una hoja que te acaban de mandar: una orden te da los campos, otra el número de filas y otra los valores distintos de una columna, sin abrir el libro ni fiarte de lo que parezca su primera pantalla.

No toda API que dice «JSON delimitado por líneas» quiere sólo eso. Las peticiones masivas de Elasticsearch y OpenSearch intercalan una línea de instrucción antes de cada documento, de modo que el cuerpo tiene el doble de líneas que registros y esta salida es la materia prima y no la carga útil. Generar esas líneas de instrucción son unas pocas líneas de script sobre el archivo.

Los cargadores que aceptan el formato tal cual existen y son el caso frecuente: un trabajo de carga de almacén apuntado a JSON por líneas, un productor de cola que lee un mensaje por línea, la rutina de importación de una aplicación. La pregunta que distingue los dos casos es si la documentación menciona una línea de acción o de metadatos. Si la menciona, te están pidiendo un protocolo; si sólo describe los registros, este archivo entra tal cual.

Todo pasa en tu navegador. El libro se analiza y las líneas se escriben en local, sin subida y sin cola, lo que en una exportación de clientes, de pedidos o de personal es la diferencia entre una herramienta que puedes usar en el trabajo y una que no.

El techo es de 100 MB por libro y cien archivos por tanda, igual para todo el mundo y sin un plan de pago detrás. Mucho antes de esa cifra lo que se nota es la memoria, porque la hoja se lee entera antes de escribirse: decenas de megabytes no llaman la atención y un libro cercano al tope es donde una pestaña empieza a sufrir. A partir de ahí el instrumento correcto es un lector en flujo dentro de un script, y decirlo es más útil que fallar a tres cuartos de un archivo muy grande.