Convertir JSON a XML

Qué implica convertir JSON a XML

JSON y XML pueden describir los mismos datos, pero no tienen las mismas articulaciones. JSON tiene objetos y arrays; XML tiene elementos que pueden repetirse, atributos que cuelgan de una etiqueta y texto que puede convivir dentro de un elemento junto a sus hijos. Pasar de JSON a XML consiste, por tanto, en decidir qué clave se convierte en etiqueta, cuál en atributo y qué hacer con un array; nada de lo cual marca el propio JSON.

Para esa decisión no hay ningún estándar. El W3C nunca definió una codificación JSON de XML, así que cada herramienta adopta una convención y las convenciones no coinciden. Este conversor usa la más extendida, la misma que Json.NET de Newtonsoft, xml2js y Spark: una clave que empieza por @ pasa a atributo, una clave llamada #text pasa a ser el texto propio del elemento y cualquier otra clave pasa a elemento hijo. BadgerFish usa $ para el texto y la convención Parker descarta los atributos por completo.

Como el mapeo es una elección y no una regla, esta página dice qué convención usa y te avisa, para tu documento concreto, de todo lo que no volverá igual si conviertes en el sentido contrario.

Cómo convertir JSON a XML

1. Pega tu JSON en el panel de la izquierda. El XML aparece a la derecha mientras escribes, sin ningún botón que pulsar. «Cargar un ejemplo» rellena el panel con un pequeño catálogo que muestra atributos, un elemento repetido y un array.
2. Ajusta el formato de salida. Elige una sola línea o una sangría de dos o cuatro espacios, y decide si quieres incluir la declaración XML al principio. Ambas opciones solo afectan al texto que obtienes, nunca a la estructura.
3. Lee los avisos y copia. Debajo de los paneles, la herramienta enumera todo lo que la forma de tus datos no permite recuperar y cuántas veces aparece. Si dice que no se ha perdido nada, tu documento está dentro de la convención. «Copiar resultado» lleva el XML al portapapeles.

Qué necesita la convención de tu JSON

XML admite exactamente un elemento raíz, así que el JSON tiene que ser un objeto con una única clave que le dé nombre. Un array en el nivel superior, o un objeto con dos claves, no tiene una forma fiel de escribirse como documento, y la herramienta lo dice en vez de inventarse una etiqueta envolvente que tú no has pedido.

Por debajo de la raíz, las claves que empiezan por @ pasan a atributos y una clave #text pasa a ser el texto propio del elemento. Eso es lo que permite que un elemento lleve a la vez un atributo y contenido: un objeto con @id y #text produce una etiqueta con atributo id envolviendo un fragmento de texto, que es exactamente lo que habrías escrito a mano.

Un array pasa a ser la misma etiqueta repetida una vez por elemento, porque así expresa XML una lista: no hay corchetes. Esa regla se lee con naturalidad en el resultado y es también el origen de la limitación principal que viene abajo, porque XML no tiene forma de marcar que una repetición pretendía ser una lista.

Qué no sobrevivirá al viaje de vuelta, con franqueza

Se midió la conversión de JSON a XML y de vuelta sobre unos 1.700 documentos generados: un 72,8% volvió idéntico byte a byte. Todos los fallos, sin excepción, se debían a exactamente dos causas, y descontadas esas el residuo sin explicar fue cero, así que los límites de abajo son precisamente esos y ningún otro.

El primero es un array de un solo elemento. Se escribe como una etiqueta única, y una etiqueta única se relee como un valor suelto, porque nada en el XML dice que se pretendía una lista. Un array de dos elementos o más vuelve perfectamente; el agujero es específicamente el array de uno. La herramienta lo señala cuando lo detecta.

El segundo es un array anidado dentro de otro array. Repetir una etiqueta puede expresar un nivel de lista y no más, así que los arrays interiores se aplanan dentro del exterior. También queda señalado.

Hay dos detalles sobre los nombres que conviene conocer. Una clave JSON puede ser cualquier cadena, pero un nombre de etiqueta XML no: una clave con un espacio, o que empiece por un dígito, no es una etiqueta válida. En lugar de emitir XML mal formado, el conversor renombra esas claves —«first name» pasa a «first_name»— y avisa de que lo ha hecho, porque la clave en sí ha cambiado. Aparte, una clave que contenga dos puntos se escribe como nombre cualificado por espacio de nombres. Eso es XML bien formado, pero solo es válido según la especificación de espacios de nombres si la declaración xmlns correspondiente también está en tu JSON, algo que conviene comprobar si escribes prefijos a mano en lugar de dar la vuelta a un documento que ya los traía.

¿Por qué es gratis?

La conversión es un análisis y una reescritura, y ambas ocurren en tu navegador mientras escribes. No se sube nada, así que no hay coste de servidor que recuperar ni motivo para pedirte una cuenta antes de dejarte convertir tus propios datos.

Eso también significa que no hay marca de agua en el resultado, ni un límite de tamaño puesto ahí para empujarte a pagar, ni un tope de documentos que puedas procesar.