XML to JSON Converter

The attribute forces the element to become a JSON object rather than a plain string, since a plain string value has nowhere to hang the attribute. The text content moves to a #text key alongside the attribute key: {"price": {"@currency": "USD", "#text": "19.99"}}. If the element had no attributes, the same tag would have simplified to a plain string value instead.

Per the XML 1.0 spec, a self-closing tag and an explicitly-closed empty tag are equivalent — there's no way to distinguish them once parsed, so both convert identically. With no attributes and no text or child content, there's nothing to populate the JSON value with, so this typically comes through as an empty string or null rather than an empty object, since there are no attribute or child keys to place inside one.

No. JSON's grammar (RFC 8259 / ECMA-404) has no comment syntax and no node type analogous to a processing instruction (<?xml-stylesheet type="text/xsl" href="style.xsl"?>), so both are stripped during conversion. Only element structure, attributes, and character data survive the conversion; anything that isn't data in the XML infoset sense is discarded.

Two separate spec gaps compound here. First, XML often contains whitespace-only text nodes between elements purely for pretty-printing indentation, which can surface as stray #text entries unless explicitly stripped. Second, the JSON grammar (ECMA-404) never mandates that object members preserve insertion order — most parsers do in practice, but it isn't a spec guarantee — so attribute order captured as @keys isn't reliably round-trippable either.

Esta es una ambigüedad inherente, no un fallo de ninguna herramienta en particular. XML no tiene un tipo numérico o booleano nativo — según la especificación XML 1.0, el contenido de todo elemento es siempre character data — así que una conversión de XML a JSON siempre tiene que tomar una decisión sobre cuándo un texto debe convertirse en un número/booleano JSON y cuándo debe permanecer como cadena. Esa decisión es realmente peligrosa para valores como "007" (un código postal o de producto, no el número 7) o "1.50" (un precio, donde convertirlo a número elimina silenciosamente el cero final y lo deja en 1.5). El comportamiento por defecto más seguro, y el que favorecen la mayoría de las conversiones, es dejar todos los valores de elementos y atributos como cadenas JSON y dejar que el código consumidor decida cuándo y cómo convertirlos — así no se destruye ninguna información de forma silenciosa.

Los navegadores y Node.js no tienen ningún equivalente integrado a JSON.parse para XML — necesitarías usar DOMParser (solo en el navegador) o una librería XML (en Node), y luego escribir a mano el código de recorrido para extraer valores del árbol DOM mediante getElementsByTagName o XPath. JSON.parse, en cambio, es una única llamada integrada que te entrega objetos y arrays planos que puedes desestructurar de inmediato. Esa diferencia explica exactamente por qué las APIs SOAP heredadas, los feeds RSS/Atom y los archivos sitemap.xml se convierten tan a menudo a JSON en el borde de una base de código JavaScript: no es que JSON sea más potente, es que el tooling de JS para consumirlo ya está ahí.

XML es aproximadamente una década anterior a JSON: XML 1.0 se convirtió en Recomendación del W3C en febrero de 1998, derivado de SGML y diseñado como lenguaje de marcado de documentos (de ahí los atributos, el contenido mixto y los namespaces). JSON se extrajo de la sintaxis de literales de objeto de JavaScript, obra de Douglas Crockford, a principios de los años 2000, se especificó formalmente por primera vez como RFC 4627 en 2006, y luego se volvió a especificar como ECMA-404 (2013) y en su forma actual, RFC 8259 (2017). El minimalismo de JSON — cuatro tipos de datos, sin atributos, sin contenido mixto — refleja su origen como formato de transporte para pasar estructuras de datos hacia y desde un programa en ejecución, no para marcar documentos.

No — y la convención del prefijo @ que usa esta herramienta para los atributos es en sí misma una prueba de esa diferencia. Esa convención (@clave para atributos, #text para contenido mixto) no forma parte de la especificación de JSON; es una convención ampliamente usada pero informal, y distintas herramientas de conversión de XML a JSON tratan la misma entrada de forma diferente — algunas aplanan los atributos como claves normales, otras envuelven el contenido del elemento en una clave $ o _text, otras usan las convenciones BadgerFish o Parker. JSON no tiene ningún concepto integrado de atributo, así que cualquier herramienta de conversión de XML a JSON está superponiendo su propia convención sobre objetos JSON planos, y la salida JSON de un conversor no tiene por qué coincidir con la de otro para la misma entrada XML.

Como este conversor conserva los prefijos de namespace de forma literal como parte del nombre de la clave en lugar de resolverlos a su URI de namespace completa, "a:id" y "b:id" se convierten en dos claves JSON distintas y no colisionan — pero solo mientras los prefijos en sí sean diferentes. Si dos partes distintas de un documento usan el mismo prefijo para URIs de namespace diferentes (algo legal en XML, ya que los enlaces de prefijo tienen alcance limitado al elemento en el que se declaran), o si una herramienta posterior vuelve a parsear el JSON sin contexto de namespace, esa clave basada en el prefijo deja de identificar de forma fiable a qué namespace pertenecía realmente el elemento. Para documentos donde las URIs de namespace importan más que los prefijos, es más seguro normalizar los prefijos antes de la conversión.