Convertir XLSX a JSON

El patrón se repite en cualquier organización: la versión buena de algo —la tarifa, el catálogo, las traducciones, los horarios, la tabla que relaciona códigos con nombres— vive en una hoja que mantiene alguien de administración, de compras o de atención al cliente, y tiene que llegar a un programa que espera datos.

No es un mal arreglo. La hoja de cálculo es una interfaz de edición excelente, esa persona ya sabe usarla, y montar un panel a medida para sustituirla casi nunca compensa. Lo que hace falta es una conversión fiable en la frontera entre las dos cosas, y eso es todo lo que hace esta página.

Una lista de objetos: la primera fila se toma como cabecera y da los nombres de clave, cada fila posterior se convierte en un objeto y cada celda en un valor de ese objeto. Es la forma que casi cualquier consumidor espera, y es la traducción directa de cómo está dispuesta la información en la hoja.

Las celdas vacías se escriben como `null` en lugar de desaparecer, de modo que todos los objetos llevan el mismo juego de claves y un programa que espera una estructura fija la encuentra. La alternativa —omitir la clave— produce registros irregulares que hay que comprobar uno a uno antes de tocarlos.

Ésta es la frase que conviene leer entera antes de convertir nada. Se lee la primera hoja del libro y nada más. Las fórmulas llegan como el resultado que tenían guardado, y no viajan el formato numérico, ni las celdas combinadas, ni los gráficos, ni las imágenes, ni los anchos de columna, ni los estilos, ni la validación de datos, ni los comentarios, ni los nombres definidos, ni las tablas dinámicas.

Para alimentar un programa eso suele ser el objetivo y no una pérdida: lo que cruza son los datos. Se convierte en pérdida en un caso concreto, cuando el libro que conviertes es también el original con el que alguien trabaja. Conserva el XLSX y trata el JSON como el artefacto generado que es.

Es la sorpresa más específicamente española de esta conversión. En la hoja ves `1.234,56` porque así lo muestra tu configuración regional; el JSON que sale escribe `1234.56`, con punto decimal y sin separador de millares, porque es la única forma en que un número puede aparecer en JSON.

Eso es lo correcto y casi siempre lo que quieres: un número en JSON es un número, y quien lo lea podrá sumarlo sin analizar texto. El problema aparece al revés, cuando alguien mira el archivo, no reconoce el formato al que está acostumbrado y concluye que la conversión ha estropeado las cifras. No las ha tocado; ha dejado de disfrazarlas.

Un código postal de Vitoria es 01001 y uno del centro de Barcelona es 08001. Si esa columna se escribió en una celda con formato de número, el cero se perdió al teclearla o al importarla, mucho antes de que ninguna conversión entrase en juego: en el archivo hay 1001 y 8001.

Lo mismo vale para un DNI con ceros por delante, para una referencia de artículo y para cualquier identificador de más de quince dígitos, que además pierde las últimas cifras en la propia hoja. Ningún conversor devuelve lo que el archivo no contiene. La solución está aguas arriba: esas columnas tienen que tener formato de texto en la hoja, y merece la pena decírselo una vez a quien la mantiene en lugar de reparar la salida todos los meses.

Una hoja de cálculo no guarda las fechas como fechas: guarda un número y le pone un formato encima para que se lea como una fecha. Esa distinción es la que hace que la columna de fechas sea la primera que hay que mirar en el resultado, sea cual sea el aspecto que tenga allí.

La forma de no depender de ello es sencilla y se hace una sola vez: da formato de texto a la columna en la hoja y escribe las fechas en ISO, `2026-03-15`. El archivo pasa a describirse a sí mismo, ordena bien como texto, cruza cualquier conversión sin ambigüedad y elimina la clase entera de problemas en lugar de resolver el de este mes.

Vale la pena pensarla a propósito, porque esas celdas serán nombres de clave en un programa. `Precio unitario (€, sin IVA)` produce algo que nadie quiere escribir dos veces; `precio_sin_iva` produce algo con lo que se trabaja a gusto.

Las tildes y las eñes son perfectamente válidas en una clave JSON y no rompen nada, pero obligan a escribir `fila["año"]` en lugar de `fila.anio` en varios lenguajes, y una cabecera con acento sobrevive mal a un viaje por una herramienta que no habla UTF-8. Cortas, en minúsculas, sin espacios y sin puntuación es la regla que ahorra más discusiones.

Es el detalle que más desconcierta cuando aparece. Una cabecera combinada que abarca tres columnas es un recurso de presentación, y al convertir deja un objeto con una clave con contenido y dos vacías: un registro extrañísimo salido de una hoja que se veía perfectamente sensata.

La respuesta no es tocar el conversor sino la hoja: una celda por columna en la fila de cabecera, y las combinaciones reservadas para pestañas de presentación que nadie convierte. Una hoja pensada para ser leída por una máquina es aburrida a la vista, y ahí lo aburrido es exactamente la virtud.

La disposición habitual es dejar la hoja como fuente editable, convertir a JSON como un paso más y guardar el JSON junto al código. Entonces los datos se revisan en una petición de cambios, quedan versionados y están disponibles al compilar, sin que nada dependa en tiempo de ejecución de un archivo que alguien puede mover de carpeta.

Dos costumbres hacen que eso aguante en el tiempo. Convertir siempre igual, para que una diferencia entre dos versiones muestre cambios reales y no reordenaciones. Y validar el resultado contra un esquema antes de guardarlo, para que una columna renombrada por un compañero con buena intención rompa una comprobación en vez de producir en silencio objetos a los que les falta un campo.

Merece la pena decirlo porque en este mismo conversor hay un destino donde sí aparece: al escribir SQL, el nombre del archivo de origen se convierte en el nombre de la tabla. Al escribir JSON no entra en ninguna parte, así que el resultado no lleva ni el nombre del libro, ni la hoja, ni la fecha de la exportación.

La consecuencia práctica es que dos conversiones de dos libros distintos producen archivos indistinguibles por su contenido. Si vas a acumular varios, pon esa información en el nombre del archivo o en un campo que añadas después; el conversor no puede inventarla porque, sencillamente, no la mira.

Si el destino es una importación a una base de datos, una herramienta de análisis o una canalización de datos, el CSV suele ser mejor intermedio: se lee en flujo, lo entiende todo y no impone una estructura anidada a unos datos que no la tienen.

JSON se gana el sitio cuando los datos van a parar a código de aplicación —una interfaz, un archivo de configuración, un dato de prueba para una API—, donde una lista de objetos es lo que el lenguaje quiere y leerla es una línea. Elige por lo que va a abrir el archivo, no por cuál de los dos formatos suena más actual.

La conversión ocurre en la pestaña, sobre tu procesador, así que el archivo no se sube y ningún servidor guarda una copia. No hay cuenta, ni cola, ni cupo diario; el tope es de 100 MB por archivo y cien archivos por lote, igual para todo el mundo.

Aquí eso no es un adorno. Las hojas que se convierten por este motivo llevan tarifas, márgenes, listados de clientes, datos de personal o un catálogo que aún no está publicado. No mandarlas a ninguna parte es la forma más sencilla de no tener que fiarse de nadie con ellas.