XML ↔ JSON

Funciones

• Las dos direcciones, XML → JSON y JSON → XML, o se fija una a mano
• ⚠️ Informa de lo que la conversión perdió: el número de comentarios, instrucciones de procesamiento y DOCTYPE
• ⚠️ Detecta el contenido mixto (texto intercalado con elementos) y avisa de que esa estructura ya se perdió
• ⚠️ Cierra con una nota sobre por qué la conversión pierde información y para qué sirve y para qué no
• Los atributos pasan a `@nombre`; el texto va a `#text` cuando hay algo más en el elemento
• Los elementos hermanos repetidos se vuelven un array; uno solo se queda como escalar
• El CDATA se funde con el texto (JSON no los distingue)
• ⚠️ Los nombres de etiqueta y atributo distinguen mayúsculas: así es XML, a diferencia de HTML
• ⚠️ Los prefijos de espacio de nombres se conservan tal cual y no se resuelven, con el motivo explicado
• ⚠️ En el sentido inverso, los nombres de clave ilegales se omiten y se listan, nunca se reescriben en silencio
• ⚠️ XML es más estricto que HTML: las etiquetas deben cerrarse, los valores de atributo deben ir entre comillas y una entidad que XML no define es un error, cada uno con su posición
• Todo ocurre en tu navegador

Cómo se usa

1. Pega XML o JSON; la dirección se detecta (lo que empieza por `<` se trata como XML)
2. Marca «Mostrar también la convención de conversión» si quieres verla
3. Mira primero el resultado y después la sección de «lo que esta conversión perdió»

Preguntas frecuentes

¿Por qué no desplegar el elemento raíz?

Porque entonces la dirección inversa no funciona. Desplegado, `<a><b>1</b></a>` pasa a `{"b":"1"}` y el nombre de la raíz, `a`, desaparece. ¿Cómo se llamaría el elemento raíz al volver? Habría que inventar un `<root>`, y ese nombre no está en tus datos. Esta herramienta va en los dos sentidos, así que ambos comparten una única convención y la raíz se queda envuelta. La prueba de ida y vuelta fija justamente esto: XML a JSON y de vuelta debe ser semánticamente idéntico.

¿Qué es el «contenido mixto» y por qué se pierde forzosamente?

Significa texto y elementos hijos intercalados dentro de un elemento: `<p>antes<b>negrita</b>después</p>`. Eso es XML perfectamente legal y el orden tiene significado: «después» tiene que ir detrás de ese `<b>`. Un objeto JSON es un conjunto sin orden de claves y no puede expresar «texto entre el primer y el segundo hijo». Así que el texto se concatena y su posición se pierde. Conservarlo implica no convertir, o usar un formato que exprese orden. Al menos aquí se cuenta cuántos elementos están afectados, para que sepas dónde está el daño.

¿Por qué `&nbsp;` da error?

Porque XML solo predefine cinco entidades: `lt`, `gt`, `amp`, `quot` y `apos`. `&nbsp;` es de HTML y no está entre ellas: un documento que la use no está bien formado. Descodificarla con manga ancha haría que un documento roto pareciera del todo normal, y quien tiene un resultado que «funciona» no va a investigar por qué otras herramientas lo rechazan. Escribe `&#160;` si quieres ese carácter.

¿De verdad es tan distinto analizar XML y HTML?

Mucho. HTML está diseñado para ser tolerante: etiquetas sin cerrar, valores de atributo sin comillas, mayúsculas y minúsculas mezcladas; el navegador hace lo que puede. XML está diseñado para ser estricto: las etiquetas deben emparejarse, los valores de atributo deben ir entre comillas, las mayúsculas importan (`<Element>` y `<element>` son dos cosas distintas) y una entidad que XML no define es un error. Por eso el analizador de HTML del navegador no sirve para leer XML: repara en silencio justo los problemas de tu documento que necesitas conocer.

¿Cuándo conviene usarlo y cuándo no?

Úsalo para mover datos entre servicios: una API que solo emite XML mientras tu código prefiere JSON, o una configuración que hay que dar a un sistema antiguo que solo lee XML. No lo uses para editar documentos XML. Si el documento tiene contenido mixto, comentarios o espacios de nombres, tras una ida y vuelta ya no será el mismo, y nada te avisará. Para editar XML, usa una herramienta que conserve el original.