Convertir XML a NDJSON

El JSON delimitado por saltos de línea necesita algo por lo que partir, y aquí el corte se hace en una lista situada en el nivel exterior de los datos ya analizados. Analizar XML no produce nunca una: el resultado es siempre un objeto con una única clave, el nombre del elemento raíz, que contiene todo lo demás. Un valor entra, una línea sale.

Eso se cumple sea cual sea el tamaño del archivo y por muchos elementos repetidos que contenga. Una exportación de 40 MB con diez mil registros se convierte en una única línea de 40 MB. No se pierde nada y no se parte nada, y si lo que necesitabas eran diez mil líneas, esta conversión no lo ha hecho.

Aquí es donde el comportamiento raro deja de serlo. Si tienes muchos XML pequeños en vez de uno grande —y en el mundo hispanohablante eso describe con precisión un directorio de facturas, porque tanto el formato Facturae español como el CFDI mexicano son un documento XML por comprobante—, entonces una línea por archivo es exactamente la forma que quiere un cargador.

Convierte cada archivo, concatena las salidas y tienes un flujo NDJSON válido con un registro por documento de origen. A partir de ahí, contar comprobantes es contar líneas, filtrar por emisor es un filtro por línea, y una carga fallida se reanuda por número de línea. Sacar eso mismo de una carpeta de XML sin pasar por este formato intermedio requiere escribir un programa.

La vía que funciona son dos pasos. Convierte el archivo a JSON y pásalo por una herramienta de consulta de JSON: selecciona la ruta que contiene el elemento repetido, recórrela y pide salida compacta para que cada objeto caiga en su propia línea. Es una sola orden, se repite en un guion y deja la decisión de qué cuenta como registro donde debe estar, que es contigo.

Ningún conversor puede tomar esa decisión mirando el documento. En un canal RSS el registro es el elemento item; en una respuesta SOAP puede estar tres niveles dentro del cuerpo; en un extracto bancario es lo que el proveedor haya decidido llamar movimiento. Una herramienta que lo adivinara acertaría lo bastante como para que se confíe en ella y fallaría lo bastante como para corromper una carga.

JSON compacto sin sangrado, con las claves en el orden del documento y un salto de línea al final. Los atributos aparecen como claves que empiezan por arroba, y el texto de un elemento que además tiene atributos aparece bajo una clave llamada #text. Un prefijo de espacio de nombres se queda dentro del nombre de la clave, así que soap:Body es una clave con dos puntos en medio, y un documento con declaración XML arrastra además una clave inicial llamada ?xml.

Esas dos últimas conviene quitarlas antes de una carga. Los nombres de campo con dos puntos e interrogaciones son incómodos o directamente inválidos en unos cuantos motores de consulta y esquemas de tabla, y la declaración es información sobre el archivo, no datos del archivo. Es una sustitución de tres líneas en la misma pasada donde partes los registros.

Lo que parece un número se convierte en número, tanto en los atributos como en el texto de los elementos. Para una cantidad o un importe eso es cómodo; para un identificador es destructivo. Una serie de factura escrita 0007 llega como el número 7, y una versión escrita 1.0 llega como 1, con lo que un dato que tenía forma pasa a no tenerla.

En documentos administrativos y contables eso pega justo donde duele, porque están llenos de campos que parecen números y son códigos: números de comprobante con relleno de ceros, códigos de cuenta, referencias de mandato, códigos de sucursal. La regla que resuelve casi todos los casos es preguntarse si sumar dos valores de ese campo significaría algo; si no, era un identificador y quería seguir siendo texto. Devuélvelos a texto en la misma pasada de proceso, antes de la primera carga y no después.

Un elemento repetido se convierte en un array solo cuando de verdad se repite. Un documento con una línea de detalle produce un objeto; el mismo documento con dos produce una lista de objetos. Dentro de una misma exportación, unas líneas tendrán el array y otras no.

Un almacén que deduce el esquema de los primeros registros que ve va a inferir un tipo y luego rechazar o forzar el resto. El arreglo va en la pasada de proceso y no en el cargador: normaliza a array todo campo que pueda repetirse mientras emites cada línea, para que el flujo sea uniforme antes de que nada aguas abajo lo mire. Es más barato hacerlo por costumbre en todos los campos repetibles que descubrir cuál era el que fallaba.

Nada en la conversión ordena. Las claves salen en el orden en que las escribía el documento, y los elementos repetidos en el orden en que aparecían. Convertir dos veces el mismo archivo produce exactamente el mismo resultado.

Eso es más útil de lo que parece en dos situaciones concretas. Al comparar dos exportaciones consecutivas para ver qué cambió, una salida estable produce diferencias legibles en vez de ruido de reordenación. Y al meter el resultado en un control de versiones, cosa que se hace mucho más de lo que se admite, un archivo que no baila hace que la revisión de un cambio sea posible.

Los comentarios del XML se descartan al analizar, y NDJSON no tiene sintaxis de comentario donde recibirlos, así que la documentación que hubiera dentro de la exportación desaparece. Tampoco cruza el esquema: un XML se puede validar contra un XSD antes de que arranque nada, y NDJSON no tiene lenguaje de esquema en su especificación.

Si el XML estaba validándose de verdad en tu proceso, estás quitando una comprobación, y reponerla —con una validación en el momento de la carga— es parte de la migración y no un extra opcional. Y si la carga necesita registrar de dónde salió el dato, eso va en un campo de cada registro o en el nombre del archivo: ponerlo como primera línea invalida el archivo para su propósito.

NDJSON lo leen directamente las herramientas de consulta de JSON, las bibliotecas de análisis de datos con su opción de líneas, y los cargadores de los almacenes habituales. La carga masiva de algunos motores de búsqueda pide además una línea de acción antes de cada documento, que se añade en la misma pasada que parte los registros.

Lo que hay que prever en este par concreto es el largo de la línea. Un lector que procesa línea a línea tiene que sostener esa línea entera en memoria, así que una línea de documento completo es un búfer de documento completo, y cualquier límite de tamaño por registro del destino se aplica al archivo entero en vez de a un registro. Esa es la razón práctica de partir los registros antes de cargar y no después.

Si la exportación es grande, llega periódicamente y tiene que convertirse en un flujo cada vez, la recomendación honesta no es un conversor en el navegador. Un analizador en flujo lee el XML elemento a elemento sin construir el árbol completo en memoria, y emitir una línea JSON por registro dentro de ese bucle es un programa corto en cualquier lenguaje.

Ese camino además sobrevive a archivos mayores que la memoria disponible, cosa que nada de esta página hace: aquí el documento entero se construye como objetos antes de escribir un solo byte. Para un archivo suelto, o para los casos por documento de más arriba, el conversor es más rápido que escribir el programa. Para una canalización recurrente, no lo es.

El analizador de XML y el escritor de líneas JSON son los dos JavaScript corriente, cargado por esta página bajo demanda. Ninguna petición transporta el archivo, lo cual importa cuando la exportación son facturas, nóminas o un listado de clientes con sus identificadores fiscales dentro.

La capa gratuita se detiene en 100 MB por archivo y cien archivos por tanda, que para una carpeta de comprobantes individuales es holgadísimo y para un volcado único puede quedarse corto. Por debajo de esos techos el límite real es la memoria de la pestaña, porque el árbol completo existe antes que la salida.