XML a JSON: atributos, nodos de texto y el problema de uno contra muchos

Por qué un <item> se convirtió en un objeto y dos en una matriz: el feed XML cuya forma JSON cambia dependiendo de cuántas entradas tiene

Un feed con `<item>one</item>` produce `"item": "one"`; agregar un segundo hermano cambia esa propiedad a `"item": ["one", "two"]`. El analizador no puede inferir que un elemento era conceptualmente una lista de uno porque ambos significados tienen una sintaxis XML idéntica. Por lo tanto, el código creado únicamente con la primera muestra puede fallar cuando la producción envía la segunda.

ToolAcre no oculta esta inestabilidad detrás de una opción de matriz siempre. Registra un nombre una vez como un valor y hermanos repetidos como una matriz. Ese mapeo directo es fácil de inspeccionar, pero los consumidores que necesitan una forma de colección estable deben utilizar el conocimiento del esquema o normalizar el resultado ellos mismos después de la conversión.

Qué tiene XML y JSON no: atributos, texto mezclado con elementos, hermanos ordenados, espacios de nombres, comentarios e instrucciones de procesamiento

XML separa los atributos de los elementos secundarios, conserva el orden de los hermanos, permite texto entre elementos, lleva prefijos de espacios de nombres y puede contener comentarios e instrucciones de procesamiento. JSON ofrece objetos y matrices, pero no tiene equivalentes integrados para esas categorías de nodos. Cualquier resultado de XML a JSON es, en consecuencia, una proyección elegida, no una traducción universal.

Este lector elimina la declaración, los comentarios y las instrucciones de procesamiento. Los prefijos de espacio de nombres permanecen textualmente en lugar de resolverse: `<ns:item>` se convierte en la clave `ns:item`, mientras que `xmlns:ns` se convierte en `@xmlns:ns`. El texto mixto se une bajo una clave, por lo que su posición original alrededor de los elementos secundarios se pierde y una advertencia dice que la conversión no puede realizar el proceso de ida y vuelta.

Convenciones de atributos: prefijos como @ o $, por qué existen y cómo colisionan un atributo y un elemento secundario con el mismo nombre

Los atributos utilizan un prefijo `@`. `<user id="7"><id>other</id></user>` se convierte en un objeto con `@id` igual a `"7"` y un hijo `id` igual a `"other"`. El prefijo evita que dos construcciones XML diferentes colisionen en una sola propiedad de objeto. También pasa a formar parte del contrato del convertidor cuando JSON se vuelve a escribir en XML.

Otras bibliotecas pueden usar `$`, un objeto de atributos u otra convención. ToolAcre solo admite el mapeo `@` visible. Cambiar ese prefijo en el código de la aplicación sin cambiar el escritor convertiría los atributos en elementos, así que consérvelo cuando use el valor convertido como formulario de inspección intermedio.

Convenciones de nodos de texto: #text o _ para el contenido del elemento, y qué sucede cuando un elemento tiene texto e hijos

Un elemento que contiene solo texto se colapsa en esa cadena. Cuando los atributos o los hijos también están presentes, el texto se encuentra bajo `#text`; CDATA se guarda por separado en `#cdata`. Una etiqueta de cierre automático se convierte en una cadena vacía. Estas claves reservadas permiten al escritor distinguir los nombres de niños comunes de las categorías de contenido que el propio JSON no define.

El contenido mixto sigue teniendo pérdidas. En `<p>before<b>bold</b>after</p>`, la posición de "antes" y "después" en relación con el niño no se puede reconstruir a partir de una propiedad `#text` unida. La herramienta detecta ese patrón estructural y avisa. Utilice una API XML que preserve los nodos cuando el orden de los documentos sea parte del significado.

El problema de uno contra muchos: los elementos repetidos se convierten en matrices solo cuando se repiten y por qué los consumidores deben codificar de manera defensiva

Los hermanos repetidos se convierten en matrices solo después de que se observa la repetición. Un solo `<book>` es un objeto; Dos libros son una serie de objetos. Esto a veces se denomina problema de uno contra muchos, pero no es un defecto del analizador. El documento fuente simplemente no contiene una declaración de lista independiente de sus apariciones.

Los consumidores defensivos pueden normalizar rutas conocidas con conocimiento del esquema: ajuste `catalogue.book` cuando aún no sea una matriz. No aplique esa regla a todas las propiedades, porque un escalar ordinario no debería convertirse en una lista simplemente por simetría. El convertidor evita deliberadamente inventar dicha información de dominio.

Ejemplo resuelto: convertir un pequeño documento de estilo RSS: atributos, un elemento repetido y un espacio de nombres, con el JSON resultante anotado

Convertir `<feed xmlns:m="https://example.invalid/meta"><item id="1"><m:title>One</m:title></item><item id="2"><m:title><![CDATA[Two & More]]></m:title></item></feed>`. La raíz es `feed`; `@xmlns:m` conserva la declaración del espacio de nombres; `item` es una matriz; cada `@id` es texto; y el segundo título contiene `#cdata`.

La inferencia de tipos está desactivada de forma predeterminada, por lo que incluso `id="2"` mantiene la cadena `"2"`. Habilitar la inferencia permite al analizador leer texto numérico y booleano como esos tipos de JavaScript, pero XML no declaró esa intención. La opción es una suposición controlada por el usuario, no una evidencia proporcionada por el documento.

Lo que esto no cubre: conversión basada en esquemas que sabe que un elemento es siempre una lista, lo que requiere un XSD o una asignación manual

No se carga ningún XSD y no hay información de lista basada en esquema disponible. El convertidor no puede saber que un elemento es repetible cuando solo aparece uno, validar los elementos secundarios necesarios, resolver los URI de espacios de nombres en tipos de aplicaciones o generar un cliente escrito. Un análisis exitoso solo establece XML bien formado aceptado por el lector configurado.

Las declaraciones DOCTYPE se rechazan antes del análisis, incluidas las inofensivas. Ese límite evita solicitudes de entidades externas, lecturas de archivos locales y expansión de entidades. Eliminar un DOCTYPE también puede eliminar declaraciones de las que dependía el documento, así que hágalo solo cuando sea propietario de los datos y comprenda las consecuencias.

Conclusión: XML a JSON es una asignación, no una traducción, y cómo el panel de convertidores de sintaxis le permite inspeccionar esa asignación en su navegador

Trate el resultado como el mapeo documentado de ToolAcre: `@` para atributos, `#text` para texto de elementos mixtos, `#cdata` para CDATA, matrices después de hermanos repetidos y prefijos de espacios de nombres literales. Esas reglas hacen que el resultado sea predecible sin pretender que XML y JSON compartan un modelo de datos.

Para inspección, esta proyección es rápida y legible. Para una integración duradera, pruebe una y muchas apariciones, atributos que comparten nombres con niños, elementos vacíos, contenido mixto y espacios de nombres. Si el orden de los elementos o las restricciones del esquema son importantes, analice XML con ese contrato en lugar de depender de una forma convertida genérica.

Mantenga el dispositivo XML sin formato junto a la expectativa normalizada. Ese emparejamiento preserva la evidencia si una actualización de dependencia cambia el manejo de matrices, el recorte de espacios en blanco o la decodificación de entidades. También brinda a los revisores un lugar para ver las distinciones que la vista JSON no puede incluir. Un objeto convertido por sí solo no puede probar si una cadena vacía proviene de un elemento de cierre automático, etiquetas emparejadas u otra convención en la fuente.