JSON y XML como árboles intercambiables
JSON y XML representan ambos datos jerárquicos, pero surgieron de tradiciones distintas. JSON es un modelo ligero de objetos/arrays usado por la mayoría de las APIs web. XML es un modelo de documento etiquetado con elementos, atributos, espacios de nombres y contenido mixto, aún central en mensajería empresarial, publicación y muchos formatos de configuración.
Convertir entre ambos es un mapeo estructural, no un simple cambio de sintaxis. Los nombres, el anidamiento y las pistas de tipo deben elegirse con cuidado porque los dos modelos no son isomorfos. Este hub explica esa familia de mapeo. Para una ruta de conversión directa, abra De JSON a XML.
Subherramientas de esta familia
- De JSON a XML — toma un valor JSON y emite un documento XML que refleja objetos como elementos y arrays como hijos repetidos (según las reglas del convertidor).
- De XML a JSON — analiza XML y produce una representación JSON de elementos, texto y atributos.
- Formatear JSON — pretty-print o minificar JSON cuando necesita control de diseño en el mismo flujo que la conversión.
Use los convertidores cuando los sistemas a ambos lados de una integración discrepan en la codificación. Use format-json cuando la carga ya es JSON y solo necesita forma legible o compacta antes o después de una transformación.
Dónde divergen los modelos
Objetos vs. elementos. Los objetos JSON son mapas no ordenados de claves string a valores. Los elementos XML están ordenados en el documento y pueden repetirse con el mismo nombre. Un array JSON de objetos suele convertirse en elementos hermanos repetidos; un objeto JSON, en un conjunto de elementos hijo con nombres únicos — hasta que una clave sea ilegal como nombre XML.
Atributos vs. propiedades. Los atributos XML son solo string, no ordenados en el elemento y no pueden anidarse. JSON no tiene un canal de atributos aparte; los convertidores suelen mapear atributos a claves con un prefijo convencional (por ejemplo @id) o anidarlos bajo un objeto reservado. Los ida y vuelta deben acordar esa convención o atributos y elementos hijo intercambiarán significado.
Tipos. JSON distingue números, booleanos, null, strings, arrays y objetos. El texto XML es siempre texto hasta que un esquema (XSD) o una convención lo reinterpretan. Sin metadatos de tipo, true, 1 y "true" pueden sobrevivir como strings — o un convertidor puede aplicar heurísticas que sorprendan.
Espacios de nombres. Los espacios de nombres XML (xmlns) desambiguan vocabularios. JSON no tiene nodo nativo de espacio de nombres; los prefijos pueden aplanarse en claves o descartarse. Perder información de espacio de nombres es un fallo silencioso habitual cuando XML→JSON→XML se usa como tubería de «limpieza».
Contenido mixto. XML permite texto y elementos intercalados (<p>Hola <em>mundo</em></p>). Los árboles JSON suelen guardar o un string o hijos, no ambos, salvo que el convertidor use un array de contenido explícito. El XML centrado en documentos suele necesitar un mapeo más rico que el XML centrado en datos.
JSON → XML (pipeline conceptual)
- Analizar JSON; rechazar sintaxis inválida antes de construir XML.
- Elegir un nombre de elemento raíz (JSON no exige una sola raíz para un array de nivel superior; los convertidores inventan un envoltorio).
- Mapear cada clave de objeto a un elemento hijo o atributo según reglas de nombres.
- Mapear arrays a elementos repetidos con la misma etiqueta.
- Escapar caracteres especiales (
&,<,>, comillas) en texto y atributos. - Serializar con o sin declaración XML e indentación.
Los nombres XML ilegales (claves que empiezan por dígitos, contienen espacios o colisionan con prefijos reservados xml) deben sanitizarse o rechazarse. Prefiera fallar de forma visible en tuberías de datos antes que emitir marcado mal formado.
XML → JSON (pipeline conceptual)
- Analizar como XML bien formado (y opcionalmente validar contra un esquema en otro lugar).
- Representar cada elemento como objeto JSON o como valor cuando solo tiene texto.
- Decidir cómo codificar atributos, hijos repetidos y elementos vacíos (
""vsnullvs{}). - Colapsar o preservar nodos de texto según la política de contenido mixto.
- Emitir texto JSON; opcionalmente pretty-print para inspección vía Formatear JSON.
Los elementos hermanos con el mismo nombre suelen convertirse en un array JSON. Un único hijo con ese nombre puede ser un objeto desnudo — otro riesgo de ida y vuelta si el código asume arrays siempre.
Formatear JSON en un flujo de conversión
Los errores de conversión se diagnostican mejor en JSON indentado. El JSON minificado conviene más para incrustar en logs o transporte tras terminar de editar. Format-json en esta familia es el hermano de diseño: no mueve datos a XML; prepara JSON para consumo humano o máquina alrededor de los convertidores.
Sin pérdida y cuándo dejar de dar vueltas
Los ida y vuelta son pérdidas por defecto salvo que ambas direcciones compartan un conjunto de convenciones documentado (prefijos de atributo, envoltorio de arrays, coerción de tipos, manejo de espacios de nombres). Patrones seguros:
- Convertir una vez en el límite del sistema y mantener un único sistema de registro.
- Guardar el XML original cuando importe la fidelidad legal/archivística; tratar JSON como proyección de trabajo.
- Preferir herramientas conscientes del esquema (XSD + data binding) para mensajes empresariales frente a recorridos ad hoc del árbol.
Patrones inseguros: usar JSON como editor XML (XML→JSON, editar a mano, JSON→XML) para documentos firmados, espacios de nombres o contenido mixto sin golden tests.
Caracteres, codificación y tamaño
Los documentos XML suelen declarar la codificación en el prólogo; el texto JSON en APIs es casi siempre UTF-8. Al convertir, asegúrese de que la cadena Unicode en memoria sea correcta antes de serializar. Los caracteres de control ilegales en XML 1.0 deben eliminarse o escaparse según política — pueden aparecer en strings JSON y romper escritores XML ingenuos.
Documentos muy grandes tensionan la memoria del navegador. Para exportaciones de varios megabytes, prefiera convertidores streaming en el ecosistema estándar de su lenguaje; las herramientas del navegador son ideales para muestras, fixtures y trozos de depuración.
Ejemplos prácticos de integración
- Servicio SOAP/XML legado, cliente JSON moderno: mapear XML de respuesta a JSON para la UI; mantener plantillas de petición en XML cuando el contrato remoto lo exija.
- Puente de configuración: mantener la config interna como JSON; emitir XML para herramientas que solo leen XML.
- Construcción de fixtures: autoría de datos como JSON, conversión a XML para un harness de parser — mantener pares golden de entrada/salida bajo las mismas reglas de mapeo que producción.
Limitaciones
Estas herramientas no validan contra XSD o JSON Schema, no ejecutan XSLT ni implementan XML Canonicalization (C14N) para firmas. Se centran en la proyección práctica de árboles. Para XML firmado digitalmente, use bibliotecas de firma dedicadas.
Herramientas relacionadas
Comprobaciones de sintaxis: Valida JSON, Valida XML. Diseño JSON puro: Pretty-print JSON. Convierta cuando el modelo deba cambiar; formatee o valide cuando permanezca igual.