Mappatura da XML a JSON: attributi, nodi di testo e il problema uno contro molti

Perché un <item> è diventato un oggetto e due sono diventati un array: il feed XML la cui forma JSON cambia a seconda del numero di voci che contiene

Un feed con `<item>one</item>` produce `"item": "one"`; l'aggiunta di un secondo fratello modifica la proprietà in `"item": ["one", "two"]`. Il parser non può dedurre che un elemento fosse concettualmente un elenco di uno perché entrambi i significati hanno la sintassi XML identica. Il codice creato solo rispetto al primo campione può quindi fallire quando la produzione invia il secondo.

ToolAcre non nasconde questa instabilità dietro un'opzione sempre-array. Registra un nome una volta come un valore e i fratelli ripetuti come un array. Questa mappatura diretta è facile da verificare, ma i consumatori che necessitano di una forma di raccolta stabile devono utilizzare la conoscenza dello schema o normalizzare il risultato da soli dopo la conversione.

Ciò che XML ha che JSON non ha: attributi, testo misto con elementi, fratelli ordinati, spazi dei nomi, commenti e istruzioni di elaborazione

XML separa gli attributi dagli elementi figlio, preserva l'ordine dei fratelli, consente il testo tra gli elementi, trasporta prefissi dello spazio dei nomi e può contenere commenti e istruzioni di elaborazione. JSON offre oggetti e array ma non ha equivalenti incorporati per quelle categorie di nodi. Qualsiasi risultato XML-to-JSON è di conseguenza una proiezione scelta, non una traduzione universale.

Questo lettore rilascia la dichiarazione, i commenti e le istruzioni di elaborazione. I prefissi dello spazio dei nomi rimangono letterali anziché essere risolti: `<ns:item>` diventa la chiave `ns:item`, mentre `xmlns:ns` diventa `@xmlns:ns`. Il testo misto viene unito sotto un'unica chiave, quindi la sua posizione originale attorno agli elementi secondari viene persa e un avviso indica che la conversione non può andare avanti e indietro.

Convenzioni sugli attributi: prefissi come @ o $, perché esistono e come un attributo e un elemento figlio con lo stesso nome entrano in collisione

Gli attributi utilizzano un prefisso `@`. `<user id="7"><id>other</id></user>` diventa un oggetto con `@id` uguale a `"7"` e figlio `id` uguale a `"other"`. Il prefisso impedisce a due diversi costrutti XML di entrare in collisione in una singola proprietà dell'oggetto. Diventa inoltre parte del contratto del convertitore quando JSON viene riscritto su XML.

Altre librerie possono utilizzare `$`, un oggetto attributi o un'altra convenzione. ToolAcre supporta solo la mappatura visibile `@`. La modifica di quel prefisso nel codice dell'applicazione senza modificare lo scrittore trasformerebbe gli attributi in elementi, quindi preservalo quando utilizzi il valore convertito come modulo di ispezione intermedia.

Convenzioni sui nodi di testo: #testo o _ per il contenuto dell'elemento e cosa succede quando un elemento ha sia testo che elementi secondari

Un elemento contenente solo testo si riduce a quella stringa. Quando sono presenti anche attributi o figli, il testo risiede sotto `#text`; CDATA è conservato separatamente in `#cdata`. Un tag a chiusura automatica diventa una stringa vuota. Queste chiavi riservate consentono allo scrittore di distinguere i nomi secondari ordinari dalle categorie di contenuti che JSON stesso non definisce.

Il contenuto misto rimane in perdita. In `<p>before<b>bold</b>after</p>`, la posizione di “prima” e “dopo” relativa al bambino non può essere ricostruita da una proprietà `#text` unita. Lo strumento rileva tale modello strutturale e avverte. Utilizzare un XML API che preserva il nodo quando l'ordine del documento è parte del significato.

Il problema uno contro molti: gli elementi ripetuti diventano array solo quando ripetuti e perché i consumatori devono codificare in modo difensivo

I fratelli ripetuti si trasformano in array solo dopo aver osservato la ripetizione. Un singolo `<book>` è un oggetto; due libri sono una serie di oggetti. Questo è talvolta chiamato il problema uno contro molti, ma non è un difetto del parser. Il documento sorgente semplicemente non contiene una dichiarazione di lista indipendente dalle sue occorrenze.

I consumatori difensivi possono normalizzare i percorsi noti con la conoscenza dello schema: wrap `catalogue.book` quando non è già un array. Non applicare questa regola a ogni proprietà, perché uno scalare ordinario non dovrebbe diventare una lista solo per simmetria. Il convertitore evita deliberatamente di inventare tali informazioni sul dominio.

Esempio realizzato: conversione di un piccolo documento in stile RSS: attributi, un elemento ripetuto e uno spazio dei nomi, con il risultato JSON annotato

Converti `<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 radice è `feed`; `@xmlns:m` mantiene la dichiarazione dello spazio dei nomi; `item` è un array; ogni `@id` è testo; e il secondo titolo contiene `#cdata`.

L'inferenza del tipo è disattivata per impostazione predefinita, quindi anche `id="2"` rimane la stringa `"2"`. L'abilitazione dell'inferenza consente al parser di leggere testo numerico e booleano come i tipi JavaScript, ma XML non ha dichiarato tale intenzione. L'opzione è un'ipotesi controllata dall'utente, non una prova fornita dal documento.

Cosa non copre: conversione guidata da schema che riconosce che un elemento è sempre un elenco, che richiede un XSD o una mappatura manuale

Non è caricato XSD e non sono disponibili informazioni sull'elenco basato su schema. Il convertitore non può sapere che un elemento è ripetibile quando ne appare solo uno, convalidare i figli richiesti, risolvere gli URI dello spazio dei nomi in tipi di applicazione o generare un client tipizzato. Un'analisi riuscita stabilisce solo XML ben formato accettato dal lettore configurato.

Le dichiarazioni DOCTYPE vengono rifiutate prima dell'analisi, comprese quelle innocue. Questo limite impedisce richieste di entità esterne, letture di file locali ed espansione di entità. La rimozione di DOCTYPE può anche rimuovere le dichiarazioni da cui dipendeva il documento, quindi fallo solo quando possiedi i dati e comprendi le conseguenze.

Conclusione: da XML a JSON è una mappatura, non una traduzione e in che modo il pannello dei convertitori di sintassi ti consente di controllare tale mappatura nel tuo browser

Considera il risultato come la mappatura documentata di ToolAcre: `@` per gli attributi, `#text` per il testo di elementi misti, `#cdata` per CDATA, matrici dopo fratelli ripetuti e prefissi dello spazio dei nomi letterali. Queste regole rendono l'output prevedibile senza fingere che XML e JSON condividano un modello di dati.

Per l'ispezione, questa proiezione è veloce e leggibile. Per un'integrazione duratura, testa una o più occorrenze, attributi che condividono nomi con elementi secondari, elementi vuoti, contenuti misti e spazi dei nomi. Se l'ordine degli elementi o i vincoli dello schema sono importanti, analizza XML rispetto a tale contratto anziché dipendere da una forma convertita generica.

Mantieni il dispositivo XML grezzo accanto all'aspettativa normalizzata. Tale abbinamento preserva la prova se un aggiornamento della dipendenza modifica la gestione dell'array, la rifinitura degli spazi bianchi o la decodifica delle entità. Fornisce inoltre ai revisori un posto dove vedere le distinzioni che la vista JSON non può supportare. Un oggetto convertito da solo non può dimostrare se una stringa vuota provenga da un elemento a chiusura automatica, da tag accoppiati o da un'altra convenzione nell'origine.