I due modelli non si allineano: RFC 8259 definisce sei tipi JSON senza attributi, mentre XML1.0 ha attributi, spazi dei nomi e contenuti misti ordinati Andare in questa direzione significa scegliere cosa fare con la differenza.
La prima volta che ho dovuto inviare i dati JSON in un sistema che parlava solo XML, ho fatto la cosa ingenua: ho scritto a mano le parentesi angolari in un editor di testo Era un feed fornitore che si aspettava una busta SOAP-ish, e la mia fonte era un ordinato array JSON che usciva da un API Laravel Venti minuti dopo, avevo disadattato un tag di chiusura da qualche parte intorno al quarantesimo record e il parser ricevente ha lanciato un & quot; junk after document element" errore di cui non mi ha detto nulla cui. Quella sera mi ha insegnato una lezione che ho applicato su ogni integrazione da allora: convertire tra JSON e XML non è un atto creativo È un problema di mappatura con un piccolo numero di regole, e nel momento in cui scrivi quelle regole, il tutto diventa meccanico.
Questa guida è la versione di quella mappatura che vorrei I'd aveva. Costruisco [Toolz.dev](/, e uno degli strumenti è basato su browser Convertitore da JSON a XML ciò si applica esattamente alle convenzioni seguenti. Ma il punto di questo articolo non è il pulsante: è la comprensione di & #39; perché una chiave diventa un elemento, perché un @- la chiave prefissata diventa un attributo e perché un array si trasforma in tag ripetuti anziché in un elenco numerato Una volta che queste tre idee fanno clic, puoi convertire manualmente qualsiasi JSON in XML se necessario e puoi eseguire il debug dell'output quando un sistema downstream lo rifiuta.
tl; dr: Per convertire JSON in XML, mappa ogni tasto oggetto in un elemento, ciascuno
@-chiave prefissata di un attributo sul suo elemento principale e il#textchiave per l'elemento's contenuto di testo Espandi ogni array in elementi fratelli ripetuti che condividono il nome chiave's. Fuga&,<, e>nel testo (più"nei valori degli attributi), e sanificare qualsiasi chiave che sia & #39; t un nome XML legale Fallo nel browser in modo che i payload con token o dati dei clienti non lascino mai la tua macchina.
Perché dovresti convertire JSON in XML in primo luogo?
JSON ha vinto la guerra delle API web anni fa e, se passi le tue giornate in React, Laravel o Node, potresti ragionevolmente chiederti quando tu' non hai mai avuto bisogno di XML. La risposta è: costantemente, ma non nei posti in cui guardi XML è la lingua franca di un'enorme base installata di sistemi che precedono l'era JSON e non vanno da nessuna parte I servizi web SOAP - ancora la spina dorsale delle integrazioni bancarie, assicurative, logistiche e governative - trasportano i loro payload in XML. I feed RSS e Atom sono XML. Le mappe del sito sono XML. I layout Android, .docx e .xlsx interni (Office Open XML), SVG, feed di podcast RSS e innumerevoli scambi in stile EDI B2B sono tutti XML.
Quindi lo scenario del mondo reale ha quasi sempre la stessa forma: hai dei dati per JSON perché quello' è ciò che produce il tuo stack e ne hai bisogno per XML perché quello's quello che l'altro lato richiede Forse tu' stai spingendo i dati del prodotto in un mercato che accetta solo un feed XML Forse tu' stai avvolgendo una risposta API in un corpo SOAP Forse tu' stai generando un feed RSS da un'esportazione di contenuti JSON In ogni caso, tu don' t vuoi reinventare la serializzazione ogni volta - vuoi una regola prevedibile che trasformi qualsiasi struttura JSON in XML valido, in modo da poterlo automatizzare e smettere di pensarci.
There's anche un motivo più tranquillo: leggibilità durante il debug Quando tu're fissando un blob JSON profondamente annidato cercando di comprendere una gerarchia, convertirlo in XML rientrato a volte fa saltare fuori la struttura ad albero, perché XML's tag aperti/chiusi rendono esplicito il nesting in un modo che JSON's braces don't. Mantengo il Convertitore da JSON a XML e il contrario Convertitore da XML a JSON apri nelle schede adiacenti più spesso di quanto I' avrei indovinato.
Come fa JSON a mappare su XML, esattamente?
Ecco il nucleo di esso Ci sono solo quattro regole, e tutto il resto è un dettaglio.
Regola 1: le chiavi oggetto diventano elementi. Un oggetto JSON { "book": { "title": "..." } } diventa <book><title>...</title></book>. La chiave è il nome del tag; il valore è ciò che entra.
Regola 2: @-le chiavi prefissate diventano attributi. Gli elementi XML possono portare attributi e JSON non ne ha un concetto nativo, quindi abbiamo bisogno di una convenzione Quello ampiamente utilizzato - e quello utilizzato dal mio strumento - è un carattere prefisso, @ per impostazione predefinita. COSÌ { "book": { "@id": "bk101", "title": "..." } } diventa <book id="bk101"><title>...</title></book>. Gli attributi possono contenere solo valori primitivi (stringhe, numeri, booleani), strutture mai annidate, che corrispondono al modo in cui funzionano effettivamente gli attributi XML.
Regola 3: Il #text key diventa contenuto di testo. Quando un elemento ha bisogno di ambo attributi e testo - pensa <title lang="en">Hello</title> - puoi' t esprimerlo con un valore di stringa semplice, perché la stringa non lascia spazio all'attributo La convenzione è una chiave riservata, #text: { "title": { "@lang": "en", "#text": "Hello" } }. Se un elemento ha solo testo e nessun attributo, puoi saltare #text e usa semplicemente un valore stringa semplice.
Regola 4: gli array diventano elementi ripetuti. Questa è quella che le persone sbagliano più spesso XML non ha alcun tipo di array Un elenco di cose è espresso come elementi fratelli ripetuti con lo stesso nome del tag Così { "tags": { "tag": ["computer", "web"] } } diventa <tags><tag>computer</tag><tag>web</tag></tags> - no <tag>0</tag> o qualsiasi sciocchezza basata su indici. L'array's chiave fornisce il nome del tag ripetuto.
Mettili insieme su un oggetto realistico e l'output è esattamente ciò che si aspetta un parser XML downstream:
{
"catalog": {
"book": [
{ "@id": "bk101", "author": "Gambardella, Matthew", "price": 44.95 },
{ "@id": "bk102", "author": "Ralls, Kim", "price": 5.95 }
]
}
}
diventa
<?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>
Si noti che l'unica chiave di primo livello, catalog, è diventato l'elemento root di document's That's deliberate: un documento XML ben formato deve avere esattamente una radice Quando il tuo JSON ha già una singola chiave di avvolgimento, quella chiave è la radice. Quando lo fa' t - quando consegni al convertitore un oggetto multichiave o un array nudo - lo strumento avvolge tutto sotto un elemento root configurabile (root per impostazione predefinita) quindi l'output rimane ben formato.
E i nomi in fuga e non validi?
Due cose interrompono silenziosamente più conversioni di qualsiasi bug di nidificazione: personaggi speciali senza escape e nomi di elementi illegali.
Fuggendo. XML riserva una manciata di caratteri All'interno del testo dell'elemento, &, <, e > deve essere scritto come &, <, e >. All'interno di un valore di attributo a doppia virgoletta, devi inoltre sfuggire alla virgoletta doppia come ". Se la tua stringa JSON contiene Tom & Jerry e lo lasci cadere in XML raw, la e commerciale nuda rende il documento malformato e il parser muore Un convertitore corretto fuoriesce automaticamente, quindi "a < b & c" diventa a < b & c nell'output e nei viaggi di andata e ritorno torna al testo originale quando analizzato. Questo non è un lucido opzionale: it' è la differenza tra XML valido e non valido.
Nomi degli elementi. XML ha regole rigide su ciò che un nome di tag può contenere Nomi can' t includono spazi, can' t iniziare con una cifra, un trattino o un punto, ed escludere la maggior parte della punteggiatura Le chiavi JSON non hanno tali restrizioni - "first name", "123", e "total($)" sono tutte chiavi JSON perfettamente legali e tutti i nomi XML illegali Un convertitore che ignora questo produce documenti che nessun parser accetterà La soluzione pragmatica, e ciò che fa il mio strumento, è disinfettare: sostituire i caratteri illegali con caratteri di sottolineatura e anteporre un carattere di sottolineatura quando un nome inizia con una cifra Così "123 bad" diventa <_123_bad>. It' non è affascinante, ma garantisce le analisi di output, che è il punto intero.
Come faccio a utilizzare il convertitore basato su browser?
Il flusso di lavoro su Toolz.dev/tools/json-to-xml rispecchia le regole di cui sopra, con alcune opzioni per i pratici casi limite.
Incolla il tuo JSON nell'input e premi Converti Se il tuo JSON non è valido, ottieni un errore di analisi chiaro anziché una spazzatura silenziosa: mi appoggio al browser' proprio JSON.parse, quindi i messaggi di errore corrispondono a ciò che tu' d vedi nella tua console Scegli 2 o 4 spazi di rientro quando desideri un documento leggibile dall'uomo per la revisione, oppure scegli Minify per comprimere il tutto su una singola riga quando tu' lo spedisci sul filo e ogni conteggio dei byte (in particolare richieste SOAP e payload di feed) Imposta il nome dell'elemento root per il caso in cui il tuo JSON non abbia un singolo tasto di avvolgimento Attiva/disattiva la dichiarazione XML (in particolare richieste SOAP e payload di feed)<?xml version="1.0" encoding="UTF-8"?>) acceso o spento a seconda che il consumatore si aspetti un prologo. E decidere se i nodi vuoti devono chiudersi automaticamente come <tag/> o espandersi a <tag></tag> - alcuni consumatori severi si preoccupano.
Tutto funziona lato client Il convertitore è un serializzatore senza dipendenze scritto in TypeScript, non un wrapper attorno a un'API remota Ciò conta più di quanto sembri: le risposte API e i file di configurazione contengono abitualmente token di accesso, record dei clienti e identificatori interni e un convertitore online & quot; gratuito e quot; che PUBBLICA il tuo payload su qualcuno's server è una perdita di dati in attesa di accadere Poiché questo non effettua mai una chiamata di rete, è possibile convertire i dati sensibili in modo sicuro, e continua a funzionare senza alcuna connessione Se la privacy negli strumenti del browser è qualcosa a cui pensi - e se gestisci altre persone's dati, dovrebbe essere - ne ho scritto di più nei dati Guida agli strumenti per la privacy dei dati.
JSON vs XML: un rapido confronto
Aiuta a mantenere i due formati' compromessi in vista, perché il ragione la mappatura necessita di convenzioni come @ e #text è che XML può esprimere le cose che JSON può' t e viceversa.
| Aspetto | json | XML |
|---|---|---|
| attributi | Nessun concetto nativo | Prima classe (<tag attr="v">) |
| Array /elenchi | Nativo [ ] tipo |
Elementi fratelli ripetuti |
| commentario | Non consentito | <!-- ... --> supportato |
| Spazi dei nomi | nessuno | Supporto completo dello spazio dei nomi |
| Contenuto misto (testo + elementi) | Imbarazzante | Nativo |
| Schema/validazione | Schema JSON (aggiuntivo) | XSD, DTD, RELAX NG (maturo) |
| verbosità | Compatto | Più prolisso (tag di chiusura) |
| Uso tipico oggi | API Web, configurazione | SAPONE, feed, documenti, impresa |
la @ il prefisso esiste per collegare & quot;attributi" riga; la regola del tag ripetuto collega & quot;array" riga; E #text collega la riga & quot; contenuti misti& quot; una volta che vedi la mappatura come un ponte attraverso queste lacune specifiche, smette di sembrare arbitraria.
JSON a XML andata e ritorno in modo pulito?
Per lo più, sì - e quello's by design. Il mio JSON a XML e XML a JSON gli strumenti condividono lo stesso @ prefisso dell'attributo e #text la chiave del contenuto, quindi la conversione di XML → JSON e viceversa generalmente riproduce il documento originale. Se tu' stai costruendo una pipeline che deve spostare i dati in entrambe le direzioni, vale la pena fare affidamento su quella simmetria.
Dove il giro di andata e ritorno diventa fuzzy è lo stesso posto in cui ogni mappatura JSON/XML diventa fuzzy: ordine e contenuto misto Gli oggetti JSON sono ufficialmente non ordinati, quindi un convertitore potrebbe non preservare l'esatto ordine fratello degli elementi con nomi XML che interlacciano testo ed elementi figlio ("child elements")<p>Hello <b>world</b>!</p>) does't ha una rappresentazione JSON pulita e ritorna come approssimazione. E un elemento che a volte appare una volta e talvolta appare più volte è ambiguo: è un singolo valore o un array di uno? Questi bug aren't in qualsiasi strumento particolare; loro' sono inerenti al fatto che i due modelli di dati don't si sovrappongono perfettamente Sapere dove sono le cuciture ti consente di progettare il tuo JSON in modo che la conversione rimanga senza perdite: sii coerente sul fatto che una cosa sia sempre un array ed evita contenuti misti dove puoi.
Se lavori molto con JSON, vale la pena costruire fluidità in tutta la famiglia di conversioni: ho raccolto quelle che raggiungo di più nel Guida definitiva agli strumenti JSON, e il più ampio Guida agli strumenti di codifica copre i casi in cui i convertitori di formato si inseriscono in un flusso di lavoro quotidiano Per la direzione inversa e i formati adiacenti, il Convertitore JSON a YAML e una pianura Formattatore JSON arrotonda il set.
Errori comuni durante la conversione di JSON in XML
Alcune trappole I' ho colpito o visto altri colpire:
Trattare gli indici degli array come nomi di tag. Se vedi <item0>, <item1> in qualcuno's output, hanno costruito il convertitore in modo sbagliato Gli array diventano ripetuto tag con il stesso nome, tratto dalla chiave array's.
Dimenticare ci può essere una sola radice. Consegnare un oggetto multi-chiave direttamente a un serializzatore senza avvolgerlo produce più elementi di primo livello, che non è un documento ben formato Avvolgilo.
Saltare escape & quot; perché i dati sembrano puliti.& quot; Sembra pulito finché una descrizione del prodotto non contiene una e commerciale o un <. Fuggire sempre; non dare mai per scontato.
Mettere i dati strutturati negli attributi. Gli attributi tengono le primitive Se si tenta di spingere un oggetto annidato in un @-chiave prefissata, un convertitore corretto lo (e dovrebbe) eliminare o ignorarlo, perché non esiste un XML valido per questo. Modellalo invece come elemento figlio.
Avanzato: scelta del rientro e della dichiarazione per il consumatore
Un'abitudine che mi ha salvato ripetuti avanti e indietro con i partner di integrazione: abbinare l'output proprio così a ciò che il consumatore si aspetta, quindi fermati Alcuni endpoint SOAP rifiutano un documento che include un segno di ordine byte o un prologo inaspettato; altri richiedono il <?xml ... ?> dichiarazione e 415 te senza di essa Alcuni validatori di feed vogliono un XML piuttosto stampato e dentellato per il proprio debug; la maggior parte dei trasporti di produzione lo vogliono minified Piuttosto che discutere, io genero qualunque variante le specifiche chiedono That's perché il convertitore espone indentazione (inclusa un'opzione minify), la dichiarazione toggle, e il comportamento di auto-chiusura come controlli di prima classe - loro' non sono decorazione, loro' sono le manopole che determinano se un consumatore esigente accetta il tuo documento al primo tentativo.
FAQ
Come faccio a convertire JSON in XML?
Incolla il tuo JSON nell'editor e premi Converti I tasti oggetto diventano elementi XML, gli array diventano tag ripetuti e il risultato appare pronto per copiare o scaricare Non c'è caricamento - la conversione avviene nel tuo browser.
Come sono rappresentati gli attributi JSON in XML?
Per convenzione, qualsiasi chiave dell'oggetto che inizia con il prefisso & quot;@" è scritto come attributo sul suo elemento principale anziché come elemento figlio. Ad esempio, {"book": {"@id": "bk101", "title": "..."}} diventa
In che modo il convertitore gestisce gli array JSON?
Ogni elemento di un array viene emesso come elemento fratello ripetuto che condivide il nome della chiave's. Quindi {& quot;tags": {& quot;tag": [& quot;a", & quot;b"]}} produce
A cosa serve la chiave di #testo?
Quando un elemento necessita sia di attributi che di contenuto testuale, il testo viene memorizzato sotto la chiave & quot;#text" {"title": {"@lang": "en", "#text": "Hello"}} diventa
Posso ottenere XML minimizzato invece di un output rientrato?
si. Impostare il rientro su 0 (Minify) e il convertitore emette l'intero documento su una singola riga senza spazi bianchi tra i tag. Questo è utile per le richieste o i feed in cui le dimensioni del carico utile sono importanti; torna a 2 o 4 spazi quando hai bisogno di un documento leggibile.
Cosa succede alle chiavi che non sono nomi di elementi XML validi?
I nomi degli elementi XML non possono contenere spazi, non possono iniziare con una cifra, un trattino o un punto ed escludono la maggior parte della punteggiatura Le chiavi che violano queste regole vengono disinfettate - i caratteri non validi diventano trattini bassi e viene aggiunto un carattere di sottolineatura principale quando necessario - quindi l'output viene sempre analizzato, anche se le chiavi JSON non erano compatibili con XML.
JSON a XML round trip con lo strumento XML to JSON?
Per le strutture comuni che fa Questo strumento e lo strumento XML to JSON condividono lo stesso & quot; @" attribute prefix e & quot; #text" content key, quindi convertire XML in JSON e viceversa generalmente riproduce lo stesso documento I dettagli indipendenti dall'ordine e il contenuto misto sono le solite fonti di piccole differenze, come lo sono con qualsiasi mappatura XML/JSON.
È sicuro convertire JSON sensibile qui?
Sì. Il convertitore è semplice JavaScript che viene eseguito interamente nel browser: nulla di ciò che incolli viene trasmesso a un server, registrato o archiviato. Ciò lo rende sicuro per le risposte API, i file di configurazione e i record contenenti token o dati personali e continua a funzionare senza connessione di rete.
