Los dos modelos no se alinean: RFC 8259 define seis tipos JSON sin atributos, mientras XML 1.0 tiene atributos, espacios de nombres y contenido mixto ordenado. Ir en esta dirección significa elegir qué hacer con la diferencia.
La primera vez que tuve que enviar datos JSON a un sistema que solo hablaba XML, hice lo ingenuo: escribí a mano los corchetes angulares en un editor de texto. Era un feed de proveedor que esperaba un sobre tipo SOAP, y mi fuente era una matriz JSON ordenada que salía de una API de Laravel. Veinte minutos después, no coincidía con una etiqueta de cierre en algún lugar alrededor del cuadragésimo registro y el analizador receptor arrojó un " basura después del elemento del documento" error que no me dijo nada al respecto donde. Esa noche me enseñó una lección que he aplicado en cada integración desde entonces: la conversión entre JSON y XML no es un acto creativo. Es un problema de mapeo con una pequeña cantidad de reglas, y en el momento en que escribes esas reglas, todo se vuelve mecánico.
Esta guía es la versión de ese mapeo que desearía que tuviera I'd. Construyo [Toolz.dev](/, y una de las herramientas allí es un navegador Convertidor JSON a XML eso aplica exactamente las convenciones siguientes. Pero el objetivo de este artículo no es el botón - it's comprensión porque una clave se convierte en un elemento, por qué @-la clave con prefijo se convierte en un atributo y por qué una matriz se convierte en etiquetas repetidas en lugar de una lista numerada. Una vez que esas tres ideas hagan clic, puede convertir cualquier JSON a XML a mano si es necesario, y puede depurar la salida cuando un sistema descendente la rechaza.
TL;Dr: Para convertir JSON a XML, asigne cada clave de objeto a un elemento, cada uno
@-clave con prefijo para un atributo en su elemento principal, y el#textclave del elemento 's contenido de texto. Expanda cada matriz en elementos hermanos repetidos que compartan la clave 's nombre. Escapar&,<y>en texto (más"en valores de atributos), y desinfecte cualquier clave que sea 't un nombre XML legal. Hágalo en el navegador para que las cargas útiles con tokens o datos de clientes nunca salgan de su máquina.
¿por qué convertirías JSON a XML en primer lugar?
JSON ganó la guerra de API web hace años, y si pasa sus días en React, Laravel o Node, es posible que pregunte razonablemente cuándo necesita XML. La respuesta es: constantemente, pero no en los lugares donde busca. XML es la lengua franca de una enorme base instalada de sistemas anteriores a la era JSON y que no van a ninguna parte. Los servicios web SOAP, que siguen siendo la columna vertebral de las integraciones bancarias, de seguros, logísticas y gubernamentales, transportan sus cargas útiles en XML. Los feeds RSS y Atom son XML. Los mapas de sitio son XML. Diseños de Android, .docx y .xlsx los componentes internos (Office Open XML), SVG, canales de podcasts RSS e innumerables intercambios estilo EDI B2B son todos XML.
Entonces, el escenario del mundo real casi siempre tiene la misma forma: tienes datos red JSON porque eso' es lo que produce tu pila y lo necesitas red XML porque eso' es lo que exige el otro lado. Tal vez tú'estás enviando datos de productos a un mercado que solo acepta una fuente XML. Tal vez tú'estás envolviendo una respuesta API en un cuerpo SOAP. Tal vez tú'estás generando una fuente RSS a partir de una exportación de contenido JSON. En todos los casos, no quieres reinventar la serialización cada vez; quieres una regla predecible que convierta cualquier estructura JSON en XML válido, para que puedas automatizarla y dejar de pensar en ello.
There's también es una razón más silenciosa: legibilidad durante la depuración. Cuando usted'Estamos mirando una masa JSON profundamente anidada tratando de comprender una jerarquía, convertirla a XML con sangría a veces hace que la estructura del árbol salte, porque XML's las etiquetas abiertas/cerradas hacen que el anidamiento sea explícito de una manera que JSON's frena don't. Yo mantengo el Convertidor JSON a XML y lo contrario Convertidor XML a JSON abrir en pestañas adyacentes con más frecuencia de lo que I'd ha adivinado.
¿cómo se asigna JSON a XML exactamente?
Aquí está el núcleo. Sólo hay cuatro reglas y todo lo demás es un detalle.
Regla 1: Las claves de objeto se convierten en elementos. Un objeto JSON { "book": { "title": "..." } } se convierte en <book><title>...</title></book>. La clave es el nombre de la etiqueta; el valor es lo que entra.
Regula 2: @-las claves prefijadas se convierten en atributos. Los elementos XML pueden contener atributos y JSON no tiene un concepto nativo de ellos, por lo que necesitamos una convención. El más utilizado, y el que utiliza mi herramienta, es un carácter de prefijo @ por defecto. Entonces { "book": { "@id": "bk101", "title": "..." } } se convierte en <book id="bk101"><title>...</title></book>. Los atributos sólo pueden contener valores primitivos (cadenas, números, booleanos), estructuras nunca anidadas, lo que coincide con cómo funcionan realmente los atributos XML.
Regla 3: La #text la clave se convierte en contenido de texto. Cuando un elemento necesita a la vez atributos y texto - pensar <title lang="en">Hello</title> - puedes 't expresar eso con un valor de cadena simple, porque la cadena no deja espacio para el atributo. La convención es una clave reservada #text: { "title": { "@lang": "en", "#text": "Hello" } }. Si un elemento solo tiene texto y no tiene atributos, puedes omitirlo #text y simplemente use un valor de cadena simple.
Regla 4: Las matrices se convierten en elementos repetidos. Éste es el que la gente se equivoca con más frecuencia. XML no tiene tipo de matriz. Una lista de cosas se expresa como elementos hermanos repetidos con el mismo nombre de etiqueta. Entonces { "tags": { "tag": ["computer", "web"] } } se convierte en <tags><tag>computer</tag><tag>web</tag></tags> - nu <tag>0</tag> o cualquier tontería basada en índices. La matriz's clave proporciona el nombre de etiqueta repetido.
Júntelos en un objeto realista y la salida es exactamente lo que espera un analizador XML descendente:
{
"catalog": {
"book": [
{ "@id": "bk101", "author": "Gambardella, Matthew", "price": 44.95 },
{ "@id": "bk102", "author": "Ralls, Kim", "price": 5.95 }
]
}
}
se convierte en
<?xml version="1.0" encoding="UTF-8"?>
<catalog>
<book id="bk101">
<author>Gambardella, Matthew</author>
<price>44.95</price>
</book>
<book id="bk102">
<author>Ralls, Kim</author>
<price>5.95</price>
</book>
</catalog>
Observe que la clave única de nivel superior, catalog, se convirtió en el documento's elemento raíz. Eso's deliberado: un documento XML bien formado debe tener exactamente una raíz. Cuando su JSON ya tiene una única clave de ajuste, esa clave es la raíz. Cuando no es así 't - cuando le entrega al convertidor un objeto de varias claves o una matriz simple - la herramienta envuelve todo bajo un elemento raíz configurable (root de forma predeterminada), por lo que la salida permanece bien formada.
¿Qué pasa con los nombres no válidos y que se escapan?
Dos cosas rompen silenciosamente más conversiones que cualquier insecto anidante: caracteres especiales sin escape y nombres de elementos ilegales.
Escapando. XML reserva un puñado de caracteres. Texto del elemento interior, &, <y > debe escribirse como &, <y >. Dentro de un valor de atributo de comillas dobles, también debe escapar de la comilla doble como ". Si su cadena JSON contiene Tom & Jerry y lo pones en XML sin formato, el signo comercial hace que el documento tenga un formato incorrecto y el analizador se agota. Un convertidor correcto se escapa automáticamente, entonces "a < b & c" se convierte en a < b & c en la salida y viajes de ida y vuelta al texto original cuando se analiza. Esto no es un pulido opcional - it's la diferencia entre XML válido e inválido.
Nombres de elementos. XML tiene reglas estrictas sobre lo que puede contener el nombre de una etiqueta. Nombres can't incluyen espacios, can't comienzan con un dígito, un guión o un punto, y excluyen la mayoría de la puntuación. Las teclas JSON no tienen tales restricciones - "first name", "123"y "total($)" todas son claves JSON perfectamente legales y todos los nombres XML ilegales. Un convertidor que ignora esto produce documentos que ningún analizador aceptará. La solución pragmática, y lo que hace mi herramienta, es desinfectar: reemplazar caracteres ilegales con guiones bajos y anteponer un guión bajo cuando un nombre comienza con un dígito. Entonces "123 bad" se convierte en <_123_bad>. It' No es glamoroso, pero garantiza los análisis de salida, que es el punto completo.
¿cómo uso el convertidor basado en navegador?
El flujo de trabajo en Toolz.dev/tools/json-to-xml refleja las reglas anteriores, con algunas opciones para los casos prácticos de borde.
Pegue su JSON en la entrada y presione Convertir. Si su JSON tiene un formato incorrecto, obtendrá un error de análisis claro en lugar de basura silenciosa. Me apoyo en el navegador 's propio JSON.parse, entonces los mensajes de error coinciden con lo que usted 'd ve en su consola. Elija 2 o 4 espacios de sangría cuando desee revisar un documento legible por humanos, o elija Minify para colapsar todo en una sola línea cuando ' lo envíe a través del cable y cada byte cuente (solicitudes SOAP y cargas útiles de alimentación especialmente). Establezca el nombre del elemento raíz para el caso en el que su JSON no tenga una única clave de ajuste. Alternar la declaración XML (<?xml version="1.0" encoding="UTF-8"?>) activado o desactivado dependiendo de si el consumidor espera un prólogo. Y decide si los nodos vacíos deben cerrarse automáticamente <tag/> o expandirse a <tag></tag> - a algunos consumidores estrictos les importa.
Todo se ejecuta en el lado del cliente. El convertidor es un serializador libre de dependencias escrito en TypeScript, no un contenedor alrededor de una API remota. Eso importa más de lo que parece: las respuestas de la API y los archivos de configuración contienen habitualmente tokens de acceso, registros de clientes e identificadores internos, y un servidor "convertidor en línea gratuito" que PUBLICA su carga útil a alguien 's es una fuga de datos esperando a suceder. Debido a que este nunca realiza una llamada a la red, puede convertir datos confidenciales de forma segura y sigue funcionando sin conexión alguna. Si la privacidad en las herramientas del navegador es algo en lo que piensas, y si manejas datos de otras personas 's, debería serlo, escribí más sobre ello en el Guía de herramientas de privacidad de datos.
JSON vs XML: una comparación rápida
Ayuda a mantener los dos formatos ' compensaciones a la vista, porque el razón el mapeo necesita convenciones como @ y #text es que XML puede expresar cosas que JSON puede 't, y viceversa.
| Aspecto | JISON | xml |
|---|---|---|
| atributos | Sin concepto nativo | Prima clasa (<tag attr="v">) |
| Matrices/listas | Nativo [ ] escribir a máquina |
Elementos hermanos repetidos |
| comentarios | No permitido | <!-- ... --> apoyado |
| Espacios de nombres | nadie | Soporte completo para el espacio de nombres |
| Contenido mixto (texto + elementos) | Torpe | Nativo |
| Esquema/validación | Esquema JSON (complemento) | XSD, DTD, RELAX NG (maduro) |
| verbosidad | Compacto | Más detallado (cerrar etiquetas) |
| Uso típico hoy | Api web, configuración | SOAP, feeds, documentos, empresa |
los @ el prefijo existe para unir "attributes" fila; la regla de etiquetas repetidas une "arrays" fila; y #text une el "contenido mixto" fila. Una vez que ve el mapeo como un puente a través de estos espacios específicos, deja de parecer arbitrario.
¿json a XML da la vuelta limpiamente?
En su mayoría, sí, y eso's por diseño. Mi JSON a XML y XML a JSON las herramientas comparten lo mismo @ prefijo de atributo y #text clave de contenido, por lo que convertir XML → JSON y viceversa generalmente reproduce el documento original. Si usted 'Estamos construyendo una canalización que tiene que mover datos en ambas direcciones, vale la pena confiar en esa simetría.
Donde el viaje de ida y vuelta se vuelve difuso es el mismo lugar donde cada mapeo JSON/XML se vuelve difuso: orden y contenido mixto. Los objetos JSON están oficialmente desordenados, por lo que es posible que un convertidor no conserve el orden exacto de los hermanos de elementos con nombres diferentes. XML que entrelaza texto y elementos secundarios (<p>Hello <b>world</b>!</p>) no 'Tienen una representación JSON limpia y regresa como una aproximación. Y un elemento que a veces aparece una vez y otras veces aparece varias veces es ambiguo: ¿es un valor único o una matriz de uno? Estos son 't errores en cualquier herramienta en particular; ellos ' son inherentes al hecho de que los dos modelos de datos no se superponen perfectamente. Saber dónde están las costuras le permite diseñar su JSON para que la conversión se mantenga sin pérdidas: sea consistente sobre si una cosa es siempre una matriz y evite contenido mixto donde pueda.
Si trabaja mucho con JSON, vale la pena desarrollar fluidez en toda la familia de conversiones. Recopilé las que más busco en el Guía definitiva de las herramientas JSON, y el más amplio Guía de herramientas de codificación cubre dónde encajan los convertidores de formato en un flujo de trabajo diario. Para la dirección inversa y formatos adyacentes, el Convertidor JSON a YAML y una llanura Formateador JSON completa el conjunto.
Errores comunes al convertir JSON a XML
Algunas trampas I' He golpeado o visto a otros golpear:
Tratar índices de matriz como nombres de etiquetas. Si ves <item0>, <item1> en la salida de alguien 's, construyeron mal el convertidor. Las matrices se convierten repetido etiquetas con el igual nombre, tomado de la clave array's.
Olvidar que sólo puede haber una raíz. Al entregar un objeto de varias teclas directamente a un serializador sin envolverlo, se producen múltiples elementos de nivel superior, lo que no es un documento bien formado. Envuélvelo.
Saltar escapar "porque los datos parecen limpios." Parece limpio hasta que la descripción del producto contiene un signo comercial o un <. Escapar siempre; nunca asumas.
Poner datos estructurados en atributos. Los atributos contienen primitivas. Si intentas empujar un objeto anidado hacia un @-clave con prefijo, un convertidor correcto (y debería) soltarlo o ignorarlo, porque no hay ningún XML válido para él. En su lugar, modelelo como un elemento secundario.
Avanzado: elección de sangría y declaración para el consumidor
Un hábito que me ha salvado repetido de ida y vuelta con los socios de integración: igualar el resultado a rajata a lo que el consumidor espera, entonces deténgase. Algunos puntos finales SOAP rechazan un documento que incluye una marca de orden de bytes o un prólogo inesperado; otros requieren el <?xml ... ?> declaración y 415 usted sin ella. Algunos validadores de feeds quieren XML con sangría y bastante impreso para su propia depuración; la mayoría de los transportes de producción quieren que se minifique. En lugar de discutir, genero cualquier variante que solicite la especificación. Eso ' es por qué el convertidor expone sangría (incluida una opción de minify), el cambio de declaración y el comportamiento de cierre automático como controles de primera clase: ellos ' no son decoración, ellos ' son las perillas que determinan si un consumidor exigente acepta su documento en el primer intento.
preguntasrán el
¿Cómo convierto json a xml?
Pegue su JSON en el editor y presione Convertir. Las teclas de objeto se convierten en elementos XML, las matrices se convierten en etiquetas repetidas y el resultado parece listo para copiar o descargar. No hay carga: la conversión se realiza en su navegador.
¿Cómo se representan los atributos JSON en XML?
Por convención, cualquier clave de objeto que comience con "@" el prefijo se escribe como un atributo en su elemento principal en lugar de como un elemento secundario. Por ejemplo, {"book": {"@id": "bk101", "title": "..."}} se convierte
¿Cómo maneja el convertidor las matrices JSON?
Cada elemento de una matriz se emite como un elemento hermano repetido que comparte la clave 's nombre. Entonces {"tags": {"tag": ["a", "b"]}} produce
¿Para qué sirve la clave de #texto?
Cuando un elemento necesita atributos y contenido de texto, el texto se almacena en "#texto" clave. {"title": {"@lang": "en", "#text": "Hola"}} se convierte
¿Puedo obtener un XML minimizado en lugar de una salida sangrada?
Sí. Establezca la sangría en 0 (Minify) y el convertidor emite todo el documento en una sola línea sin espacios en blanco entre etiquetas. Esto es útil para solicitudes SOAP o alimentaciones donde el tamaño de la carga útil es importante; vuelva a 2 o 4 espacios cuando necesite un documento legible.
¿Qué sucede con las claves que no son nombres de elementos XML válidos?
Los nombres de elementos XML no pueden contener espacios, no pueden comenzar con un dígito, guión o punto y excluir la mayoría de la puntuación. Las claves que violan estas reglas se desinfectan: los caracteres no válidos se convierten en guiones bajos y se agrega un guión bajo inicial cuando es necesario, por lo que la salida siempre se analiza, incluso si sus claves JSON no eran compatibles con XML.
¿JSON a XML de ida y vuelta con la herramienta XML a JSON?
Para las estructuras comunes lo hace. Esta herramienta y la herramienta XML a JSON comparten el mismo "@" prefijo de atributo y "#texto" clave de contenido, por lo que convertir XML a JSON y viceversa generalmente reproduce el mismo documento. Los detalles independientes del orden y el contenido mixto son las fuentes habituales de pequeñas diferencias, como lo son con cualquier mapeo XML/JSON.
¿Es seguro convertir JSON sensibles aquí?
Sí. El conversor es JavaScript simple que se ejecuta completamente en su navegador; nada de lo que pega se transmite a un servidor, se registra o se almacena. Eso lo hace seguro para respuestas API, archivos de configuración y registros que contienen tokens o datos personales, y sigue funcionando sin conexión de red.
