Convertir JSON a XML

Empezamos por aquí porque es lo que más sorprende a quien escribe en español. Los nombres de elemento se depuran contra una lista blanca estrictamente ASCII: sobreviven las letras de la A a la Z, las cifras, el guion bajo, el punto y el guion, y todo lo demás se sustituye por un guion bajo. Una clave llamada «año» sale como «a_o», «señor» como «se_or» y «código» como «c_digo».

Lo incómodo es que XML 1.0 sí admite esos nombres. La norma acepta letras acentuadas, la eñe, el griego, el cirílico y los ideogramas en un nombre de elemento; quien los descarta es este escritor, no el formato. El documento sale bien formado y con los valores intactos, pero los nombres ya no son los que declara tu esquema. Si tu carga útil está codificada en español, renombra esas claves en el JSON antes de convertir o reestructura para que la parte variable sea un valor y no una clave.

Un documento XML tiene un único elemento más externo. Un JSON puede ser un objeto con quince claves, una lista o un número suelto, y ninguno de esos trae un nombre para el envoltorio. La regla que se aplica es concreta: si el objeto tiene exactamente una clave y esa clave no contiene una lista, la clave se convierte en la raíz; en cualquier otro caso se envuelve todo en un elemento llamado «root».

La excepción atrapa una de las formas más comunes que existen. Con algo como {"lineas": [1, 2]}, usar la clave como raíz escribiría la etiqueta dos veces y produciría un documento sin elemento raíz, así que se envuelve el par en «root». La consecuencia útil es que, si controlas el JSON, envolverlo en una sola clave con el nombre que espera el destinatario —factura, pedido, expediente— hace que el XML salga ya con el nombre correcto.

XML nunca ha tenido un tipo lista y nunca lo ha necesitado: una enumeración es la misma etiqueta escrita varias veces dentro del mismo padre. Así que un objeto con tres etiquetas produce tres elementos seguidos, que es exactamente la forma que cualquier consumidor de XML ya sabe leer.

Es el único punto en el que XML encaja con JSON mejor que los formatos tabulares. Convertir esa misma lista a CSV obliga a decidir entre columnas adicionales, una cadena unida por comas o filas adicionales, y cada una de las tres es equivocada para algún caso. Aquí la repetición es nativa, de modo que un pedido con cinco líneas se convierte sin que nadie tenga que tomar una decisión en tu nombre. Una lista en el nivel superior se convierte en elementos «item» repetidos dentro de «root».

XML tiene dos maneras de colgar un valor de un elemento —un atributo dentro de la etiqueta o un elemento hijo— y a los esquemas les importa mucho cuál de las dos. JSON solo tiene una. El convenio que salva esa distancia es la arroba: una clave que empieza por «@» se escribe como atributo, y una clave llamada «#text» aporta el texto propio del elemento junto a sus hijos.

No es un convenio arbitrario, sino el mismo que produce el lector de XML de este sitio en la dirección contraria. Un documento convertido a JSON, editado y devuelto a XML recupera los atributos como atributos en vez de ascenderlos a elementos, y eso es lo que hace del viaje de ida y vuelta una forma practicable de editar una carga útil XML. Si el destinatario espera el identificador como atributo y tu JSON lo tiene como clave normal, renombrar esa clave a «@id» es toda la corrección necesaria.

Un «null» de JSON se convierte en un elemento presente y sin nada entre la etiqueta de apertura y la de cierre. Es una decisión y no la única disponible: XML tiene además el atributo «xsi:nil» pensado exactamente para esto, y algunos esquemas lo exigen.

Si el tuyo es de esos, los elementos vacíos se arreglan con una sustitución, pero es mejor saber cuál de las dos convenciones espera tu destinatario antes del primer envío que después. La diferencia importa cuando el receptor distingue entre «este campo no tiene valor» y «este campo tiene la cadena vacía», que es justo la distinción que un importador bancario o tributario suele tomarse en serio.

Se escapan cuatro: el ampersand, los dos ángulos y la comilla doble. Eso es lo que impide que la descripción de un producto que contenga «Tomás & Jerry <especial>» termine el documento antes de tiempo o abra una etiqueta que nadie quería.

Todo lo demás pasa sin tocar y en UTF-8, incluidos el apóstrofo y cualquier carácter no ASCII. Es importante entender la asimetría con la sección de arriba: dentro de un valor, la eñe, los acentos y los signos de apertura de interrogación y exclamación viajan perfectamente; el problema estaba solo en los nombres de elemento. Un texto en español conserva su ortografía completa.

La salida empieza directamente por el elemento raíz. No se escribe la línea con la versión y la codificación al principio del archivo. La norma XML 1.0 la hace opcional y define UTF-8 como codificación por defecto, así que el documento está bien formado sin ella.

Unos cuantos sistemas de recepción con muchos años encima opinan lo contrario y algunos fallan con un mensaje que no explica nada. Añadirla es una línea escrita a mano al principio del archivo. Vale la pena saberlo antes del primer envío, porque un «documento no válido» devuelto por una cola de mensajería rara vez indica cuál de las veinte cosas posibles ha ocurrido.

La conversión conoce el JSON y no conoce nada del esquema al que va dirigido. El orden de los elementos, los espacios de nombres y los envoltorios obligatorios son los que el JSON dejaba implícitos, y ninguno de los tres se puede deducir de un archivo que no los expresa.

La consecuencia práctica es que el resultado es un documento bien formado y no necesariamente válido. Haz dos comprobaciones y en este orden: primero que el documento se analiza, cosa que cualquier navegador o editor te dice en un segundo y que aquí debería pasar siempre; después la validación contra el XSD, que casi seguro fallará la primera vez. Los errores que devuelva son informativos —falta un espacio de nombres, un elemento está en la posición equivocada, sobra o falta un envoltorio— y cada uno es una corrección pequeña que solo hace falta hacer una vez.

Nada en la conversión ordena las claves. Salen en el orden en que estaban en el JSON, que es lo que quieres cuando el esquema de destino es sensible a la secuencia y lo que evita que dos cargas útiles parecidas produzcan diferencias ilegibles al compararlas.

Lo que no hay es ningún canal para comentarios. Ni el JSON de partida los admite ni el escritor de XML emite ninguno, así que las anotaciones que tuvieras en un YAML o un TOML convertido previamente ya se habían perdido antes de llegar aquí. Si un comentario contenía información necesaria, tiene que convertirse en un valor con su propia clave.

Cada valor va envuelto en una etiqueta de apertura y otra de cierre, de modo que los nombres de campo aparecen dos veces por registro en vez de una. Con valores cortos y nombres de campo largos, el documento puede acabar midiendo el doble o el triple, y la sangría de dos espacios con un elemento por línea suma lo suyo.

Es un coste real en una cola con límite de tamaño de mensaje y ninguno en una transferencia de archivos, que es donde acaban la mayoría de estas entregas. Cuando importa, la respuesta es comprimir y no reestructurar: el XML es texto muy repetitivo y se comprime extraordinariamente bien, y casi todos los sistemas que limitan el tamaño del mensaje aceptan una carga comprimida.

En español este par se busca casi siempre por el mismo motivo: hay una integración que se diseñó antes de que existiera JSON. Facturae en la administración española, los mensajes ISO 20022 de la banca, un servicio SOAP interno, una transformación XSLT en mitad de una cadena, un importador de un ERP que solo aprendió un dialecto.

Todos esos destinos tienen algo en común: publican un esquema y esperan que tu documento se ajuste a él. Convertir el JSON es el primer paso y no el último, y el trabajo real empieza cuando validas. Lo que ganas es tener un documento concreto sobre el que discutir en vez de una discusión teórica sobre cómo debería mapearse tu estructura.

La conversión es JavaScript ejecutándose aquí: el navegador analiza el JSON, un escritor pequeño produce el XML y ninguna petición lleva el documento a ningún sitio. No hay registro, ni cola, ni cupo diario, y el límite gratuito es de 100 MB por archivo con hasta cien archivos por tanda.

Para este público suele ser el factor decisivo y no un adorno. Las cargas útiles que tienen que convertirse en XML son pagos, reclamaciones, declaraciones y datos de clientes o pacientes: precisamente las categorías en las que pegar un archivo en un servicio web desconocido es un incidente que hay que notificar. Aquí no se envía nada, así que no hay nada que notificar.