Español

Herramientas de desarrollo · Convertidores de sintaxis

JSON a XML: elementos raíz, matrices y nombres de etiquetas no válidos

· Cómo funciona

json xml formatos de datos

Una matriz JSON sin raíz que ingresa un contenedor XML con elementos secundarios repetidos
Conversión de
Ilustración de vector original de ToolAcre

JSON puede ser una matriz simple con claves que comienzan con dígitos o contienen espacios, ninguno de los cuales XML permite. Esta publicación explica las decisiones que debe tomar un convertidor sobre raíces, matrices y nombres, para que pueda predecir el resultado.

La matriz sin nombre: una matriz JSON de nivel superior que tiene que convertirse en un documento XML de raíz única y el elemento contenedor que aparece

JSON puede comenzar con `[1,2]`; XML no puede comenzar con dos elementos de documento del mismo nivel. Por lo tanto, ToolAcre envuelve una matriz raíz en el nombre de la raíz seleccionada y escribe cada miembro como un hijo `<item>` repetido. La advertencia nombra esa convención, porque los nombres del contenedor y del elemento no estaban presentes en la fuente.

Al elegir `numbers` se obtiene un elemento de documento `<numbers>` que contiene dos elementos de elemento. La conversión es determinista, pero no canónica: otro sistema podría requerir `<number>` o una colección con atributos. Establezca la raíz deliberadamente y compare el resultado con el contrato XML requerido por el receptor.

XML necesita exactamente una raíz: por qué cada conversión inventa o solicita un nombre de elemento raíz

Un documento XML debe tener exactamente un elemento raíz. Un objeto JSON con exactamente una clave ordinaria de nivel superior puede usar esa clave directamente. Un objeto de múltiples claves, matriz, escalar o nulo no tiene un nombre único proporcionado, por lo que el escritor lo incluye en `root` a menos que el usuario proporcione otro nombre legal.

La regla contenedora se implementa antes de la serialización y aparece como una advertencia. No lo descubre un esquema y no afirma que `<root>` tenga significado para el servicio heredado. Nombrar la envolvente es parte del diseño de integración, mientras que el convertidor solo garantiza una estructura bien formada bajo su propio mapeo.

Las matrices no tienen equivalente XML: repetir un elemento por elemento y cómo se representan las matrices de escalares y las matrices de matrices.

Las matrices se convierten en elementos repetidos. En la raíz del documento, los miembros usan `<item>` debajo del contenedor. Dentro de un objeto, una matriz almacenada en `line` se convierte en `<line>` hermanos repetidos. Las matrices de objetos crean elementos repetidos con campos secundarios; Las matrices anidadas no tienen nombres de dominio y heredan la estructura genérica producida por el constructor.

Esto pierde la distinción entre un miembro de la matriz y un escalar con el mismo nombre de elemento después de una lectura posterior de XML a JSON. XML proporciona ocurrencias, no un marcador de matriz independiente. Si la cardinalidad estable es importante, un esquema o mapeo de aplicación debe proporcionarla; un serializador genérico no puede probarlo únicamente con los nombres de elementos en forma de JSON.

Claves que no pueden ser nombres de elementos: nombres que comienzan con un dígito, que contienen espacios o puntuación, o que comienzan con 'xml', y cómo los convertidores les cambian el nombre o los escapan

El esquema sugiere que los convertidores pueden cambiar el nombre o escapar de claves ilegales. ToolAcre los rechaza explícitamente. Una clave con un espacio, una que comienza con un dígito o guión, o una que comienza con las letras reservadas `xml` activa `UNSUPPORTED_SHAPE` y nombra la ruta infractora. El cambio de nombre silencioso produciría XML que no coincide con ningún esquema acordado.

Los nombres válidos pueden comenzar con una letra, un guión bajo o un prefijo de estilo de espacio de nombres y pueden contener dígitos, puntos, guiones bajos, dos puntos y guiones después del inicio. Las claves de atributos utilizan `@` solo como convención JSON; el nombre del atributo restante debe pasar la misma verificación. Cambie el nombre de la clave de origen intencionalmente o elija otro formato de destino.

Las claves que no pueden ser nombres de elementos se rechazan, nunca se les cambia el nombre ni se les escapa.

Los números y valores booleanos se serializan como texto de elemento, por lo que su tipo JSON ya no lo declara XML. En consecuencia, el lector inverso predeterminado devuelve cadenas. Null no tiene representación XML aquí: se convierte en un elemento vacío, indistinguible de una cadena vacía, y el escritor informa cuántos valores sufrieron ese cambio.

Esto significa que `{ "a": null, "b": "" }` puede producir dos elementos vacíos que se leen por igual. Decir que ese viaje de ida y vuelta no tiene pérdidas sería falso. Los atributos `#text` y `#cdata` conservan la convención estructural del convertidor, pero no agregan un sistema de tipo XML general.

Los tipos se convierten en XML texto, mientras que null se convierte en una ambigüedad admitida de elemento vacío

Utilice `{"order":{"@id":"A-7","customer":"Ada","line":[{"sku":"P1","qty":2},{"sku":"P2","qty":1}],"note":null}}`. La única clave `order` se convierte en la raíz, `@id` se convierte en un atributo, cada objeto de línea se convierte en un `<line>` repetido y nulo se convierte en un `<note></note>` vacío con una advertencia.

Lee el resultado nuevamente con la inferencia deshabilitada. Los valores de identificación de atributo, cantidad y texto son cadenas y la línea es una matriz porque aparece dos veces. Esto demuestra el inverso exacto admitido al tiempo que expone los tipos numéricos y nulos perdidos. Un esquema de orden de recepción puede exigir otros nombres u órdenes, que este ejemplo no valida.

Lo que esto no cubre: producir XML que coincida con un XSD o espacio de nombres determinado, que necesita una asignación escrita a mano.

El escritor no consume un XSD, no asigna URI de espacio de nombres ni decide el orden de los elementos de un esquema empresarial. Escribe una declaración XML y nunca emite un DOCTYPE. Las claves que contienen prefijos de espacios de nombres se conservan literalmente, pero eso no es una resolución del espacio de nombres ni una prueba de que el prefijo se declara correctamente.

Generar XML aceptado por un servicio específico puede requerir atributos, restricciones de secuencia, grupos de opciones y nombres calificados. Utilice su esquema o documentación actual para crear ese mapeo. Una conversión genérica es adecuada para inspección y documentos simples centrados en datos, no sustituye a la serialización basada en contratos.

Conclusión: predice la forma antes de depender de ella y cómo el panel de convertidores de sintaxis muestra la estructura XML que produce un documento JSON

Predice el sobre, los nombres de los artículos y la pérdida de tipos antes de depender del resultado. ToolAcre envuelve valores que carecen de una raíz, repite matrices, asigna claves `@` a atributos, reemplaza valores nulos con texto vacío y rechaza nombres ilegales en lugar de adivinar reemplazos. Cada cambio no obvio aparece en los resultados o en las advertencias.

Pruebe el objeto más pequeño que incluya una matriz de nivel superior, registros repetidos, texto numérico nulo y una clave incómoda. Una negativa es una prueba útil de que se requiere un mapeo manual. Un archivo exitoso aún necesita la validación por parte del receptor real, porque XML bien formado y XML con esquema válido son afirmaciones diferentes.

Después de que el receptor acepte una muestra, agregue una inspección inversa solo donde se espera que el mapeo sobreviva. Los atributos y los hijos repetidos pueden realizar ida y vuelta según la propia convención de ToolAcre, mientras que los tipos nulos y escalares no pueden. Registrar esa distinción evita que un ejemplo exitoso de camino feliz se generalice a cada documento de pedido que su integración pueda producir.