Convertitore XML in JSON gratuito
Converti XML in JSON istantaneamente. Gestisce attributi, elementi nidificati e nodi di testo. Funziona interamente nel tuo browser.
Cos’è XML?
XML (Extensible Markup Language) è un formato per archiviare e trasportare dati. Utilizza tag personalizzati per descrivere la struttura dei dati, rendendolo leggibile dall’uomo e ampiamente supportato. A differenza di JSON, XML può includere attributi sugli elementi.
Perché convertire XML in JSON?
- Dimensioni del file ridotte · JSON è più compatto di XML.
- API web · La maggior parte dei servizi web moderni usa JSON invece di XML.
- Parsing più semplice · JSON si mappa direttamente sugli oggetti JavaScript.
- Integrazione di sistemi legacy · Converti vecchi dati XML nel formato JSON moderno.
Domande frequenti
Come vengono gestiti gli attributi XML?
Gli attributi XML vengono convertiti in proprietà JSON con prefisso «@». Ad esempio,
E i namespace?
I prefissi dei namespace XML vengono mantenuti nei nomi delle chiavi JSON. Le dichiarazioni di namespace (xmlns) appariranno come attributi regolari che iniziano con «@xmlns» nell’output.
Posso convertire JSON di nuovo in XML?
Questo strumento converte solo XML in JSON. Per la conversione inversa, prova il nostro convertitore JSON in XML che inverte il processo utilizzando la stessa convenzione per attributi e nodi di testo.
Due formati, tre decenni di distanza
XML 1.0 è diventato una W3C Recommendation il 10 febbraio 1998. I redattori originali erano Tim Bray (Textuality / Netscape), Jean Paoli (Microsoft) e C. M. Sperberg-McQueen (University of Illinois at Chicago); il Working Group era presieduto da Jon Bosak di Sun Microsystems. La discendenza di XML risale a SGML (ISO 8879:1986), lo standard di markup dei documenti cresciuto a partire da GML di IBM negli anni '70. SGML era potente ma impegnativo; l'obiettivo di progettazione di XML era «progettare una versione 'lite' di SGML», eliminando le funzionalità opzionali a favore di un profilo implementabile in poche migliaia di righe di codice, preservando al contempo Unicode, i namespace e i documenti ricchi di attributi.
JSON (JavaScript Object Notation) è stato scoperto, non progettato. Douglas Crockford e Chip Morningstar hanno inviato il primo messaggio JSON nell'aprile 2001 a State Software, derivando il formato dalla sintassi degli oggetti letterali di JavaScript. Crockford ha registrato json.org nel 2002 e ha pubblicato una specifica di una pagina. Il formato è stato formalizzato per la prima volta come RFC 4627 nel luglio 2006, ripubblicato come RFC 7159 nel 2014 e stabilizzato come RFC 8259 / STD 90 nel dicembre 2017, lo stesso anno in cui ECMA-International ha pubblicato ECMA-404. L'intento progettuale di JSON (dalla retrospettiva di Crockford): minimale, indipendente dal linguaggio, facile da generare e analizzare, nessun numero di versione («non esiste un numero di versione»), e deliberatamente privo di commenti («ho rimosso i commenti perché vedevo che le persone li usavano come direttive di parsing»).
JSON ha dominato le API web alla fine degli anni 2000, man mano che REST sostituiva SOAP e XMLHttpRequest cedeva il passo a JSON-over-fetch. Entro il 2015 JSON era il formato di risposta predefinito di quasi ogni API pubblica; XML è sopravvissuto nell'enterprise SOA a coda lunga, nei formati documento (Office Open XML, OpenDocument) e nelle nicchie vincolate agli standard.
Dove XML e JSON differiscono
| XML | JSON | |
|---|---|---|
| Attributi | Nativi (<item id="5"/>) | Nessun attributo, tutto è una coppia chiave/valore |
| Namespaces | Nativi (xmlns:prefix="uri") | Nomi piatti; le collisioni di prefisso sono un problema dell'applicazione |
| Commenti | <!-- … --> | Nessuno per specifica |
| Contenuto misto | Nativo (<p>text <b>and</b> markup</p>) | Goffo, richiede array o stringificazione |
| Schema | DTD, XSD 1.0 (2001) / 1.1 (2012), RELAX NG, Schematron | JSON Schema (specifica della comunità, bozza 2020-12) |
| Ordine | L'ordine degli elementi è significativo per specifica | Ordine delle chiavi dell'oggetto non garantito (la maggior parte dei parser preserva l'ordine di inserimento in pratica); gli array sono ordinati |
| Numeri | Stringhe finché tipizzate dallo schema | Double IEEE 754; nessuna distinzione intero/float a livello di specifica |
| Verbosità | Alta (ogni valore racchiuso in tag | Bassa) solo punteggiatura |
Perché XML→JSON è fondamentalmente con perdite
Non esiste una mappatura canonica approvata dal W3C da XML a JSON. Ogni convertitore deve inventare risposte alle domande che XML consente di esprimere ma per le quali JSON non ha vocabolario nativo. Le decisioni ricorrenti:
- Attributi vs elementi figlio: XML consente di esprimere gli stessi dati in entrambi i modi. JSON ha un solo concetto (chiavi su un oggetto), quindi il convertitore deve inventare un marcatore. Le convenzioni comuni: BadgerFish usa
@per gli attributi e$per il testo; Parker elimina completamente gli attributi (con perdite ma semplice); JsonML rappresenta gli elementi come array con tag di tipo (preserva ordine e struttura); GData / Newtonsoft / xml2js usano un sotto-oggetto@attributespiù una chiave#textquando necessario. Questo convertitore segue la convenzione GData-style: attributi sotto@attributes, testo a contenuto misto sotto#text, i figli ripetuti diventano array. - Elementi figlio ripetuti: se il convertitore crea ingenuamente una chiave per ogni figlio, il secondo figlio sovrascrive il primo. Soluzione standard: rilevare la ripetizione ed emettere un array. Ma questo significa che la forma JSON dipende dai dati: un singolo
<book>produce una stringa, due producono un array di stringhe. Alcuni consumatori vogliono la forma array anche per un solo elemento; alcuni convertitori espongono un interruttore «always-array» per nomi di elementi specifici. - Contenuto misto:
<p>Hello <b>world</b>!</p>mescola testo ed elementi con ordine significativo. JSON non può esprimere nativamente quell'interleaving senza un array di tipi misti o una chiave sentinel#text. Molti convertitori eliminano il testo in prosa tra gli elementi; i più conservativi lo suddividono in più voci di nodo di testo. - Namespace:
<soap:Envelope xmlns:soap="…">ha sia un prefisso che un URI di binding. La maggior parte dei convertitori preserva il prefisso come parte della chiave JSON (soap:Envelope) e scarta il binding, il che va bene finché il consumatore non ha bisogno di risolvere il namespace. - Commenti e istruzioni di elaborazione: di solito eliminati silenziosamente, poiché JSON non ha sintassi per i commenti.
- Sezioni CDATA: appiattite in stringhe semplici; il wrapper
<![CDATA[…]]>viene perso. - Spazio bianco: XML ha
xml:space="preserve"per gli spazi bianchi significativi; JSON non ha equivalente. La maggior parte dei convertitori elimina i nodi di testo composti solo da spazi bianchi tra gli elementi.
Quando si userebbe questo strumento
- Consumo di servizi SOAP legacy da un frontend JS moderno. Le risposte SOAP sono XML; la conversione una volta al confine consente al resto dell'app di lavorare in JSON.
- Elaborazione di feed RSS / Atom: entrambi sono formati XML; i lettori di notizie e gli aggregatori moderni di solito preferiscono JSON.
- Sitemap XML (
sitemap.xml), la conversione in JSON le rende più facili da ispezionare e processare programmaticamente. - Dati OpenStreetMap OSM: pubblicati come XML, frequentemente necessari come JSON per la mappatura lato client.
- File Google Earth KML / GPX: formati di dati geografici che vengono distribuiti in XML.
- Struttura interna di Office Open XML:
.docx,.xlsxe.pptxsono file XML compressi; se si è estratto uno di essi e si vuole ispezionarne la struttura come JSON, questo è il passaggio di conversione. - Manipolazione SVG: SVG è XML. La conversione in JSON rende più facile attraversare e modificare l'albero in JavaScript prima di ri-serializzare.
- Maven POM, file di build Ant, configurazione Spring, risorse Android, Apple plist, dati finanziari XBRL, cartelle cliniche HL7, MusicXML, documenti legali NMX: formati XML a coda lunga che spesso necessitano di JSON per gli strumenti downstream.
Alternative moderne
- API JSON native. Se il servizio upstream offre una variante JSON, usarla. I servizi SOAP di solito non lo fanno, ma la maggior parte degli equivalenti moderni sì.
- GraphQL. Un linguaggio di query che consente al client di richiedere esattamente la forma JSON di cui ha bisogno da uno schema tipizzato.
- Protocol Buffers (Protobuf), MessagePack, CBOR, Avro. Formati di serializzazione binaria con schemi e dimensioni di trasferimento molto più piccole rispetto a XML o JSON. Comuni nelle mesh di microservizi; raramente usati al confine del browser perché richiedono librerie di decodifica esplicite.
- Restare in XML. Se i dati sono genuinamente orientati ai documenti (contenuto misto, struttura tipizzata profonda, validazione dello schema che conta), XML è la scelta migliore. Il punto di forza di JSON sono i dati a forma di API; la fedeltà al documento non è la sua specialità.
Altre domande
Perché lo stesso XML produce una forma JSON diversa su strumenti diversi?
Perché non esiste una mappatura canonica XML→JSON. Ogni convertitore sceglie una convenzione (BadgerFish, Parker, JsonML, GData-style) e le forme JSON risultanti differiscono nel modo in cui vengono marcati gli attributi, in come viene preservato il contenuto misto e in come vengono disposti in array i figli ripetuti. Il round-trip dell'XML attraverso convertitori diversi produce JSON diversi; il round-trip del JSON di ritorno in XML attraverso convertitori diversi può cambiare la posizione degli attributi e persino l'ordine degli elementi. Per l'interoperabilità, documentare la convenzione utilizzata e rispettarla.
E le sezioni CDATA, i commenti e le istruzioni di elaborazione?
Le sezioni CDATA (<![CDATA[…]]>) vengono appiattite in contenuto stringa semplice; il wrapper viene eliminato, ma il testo interno viene preservato verbatim. I commenti XML (<!-- … -->) e le istruzioni di elaborazione (<?xml-stylesheet …?>) vengono eliminati, poiché JSON non ha sintassi per nessuno dei due. Se è necessaria la fedeltà del round-trip che preserva i commenti, un round-trip solo XML è l'approccio corretto.
Il mio schema XML (XSD) sopravviverà alla conversione?
No. XSD descrive la struttura e i tipi XML; JSON Schema è lo standard analogo (separato) per JSON. Alcuni strumenti avanzati possono tradurre XSD in JSON Schema, ma è un'operazione con perdite; XSD ha funzionalità (contenuto misto, gruppi di sostituzione, tipi derivati) che non hanno un equivalente pulito in JSON Schema. Per la validazione dei documenti che conta, eseguire XSD sull'XML originale, non sulla conversione JSON.
Perché JSON ha vinto per le API web?
Alcune ragioni. JSON si mappa direttamente sugli oggetti JavaScript, quindi il parsing lato browser dista una chiamata JSON.parse(). Il formato è molto più piccolo: nessun tag di chiusura, nessuna dichiarazione di namespace, nessun peso dello schema. REST ha sostituito SOAP per la maggior parte delle API pubbliche alla fine degli anni 2000, e JSON era il payload naturale per REST. I punti di forza di XML (schemi rigorosi, namespace, contenuto misto) contano per i documenti e i sistemi enterprise legacy, ma raramente per «dammi l'oggetto utente». Il web si è ottimizzato per il caso più semplice.
Vengono inviati dati a un server?
No. L'XML viene analizzato dal DOMParser nativo del browser, poi percorso ricorsivamente in JavaScript per costruire l'output JSON. L'XML incollato non lascia mai la pagina. Lo strumento funziona offline una volta caricato, il che conta quando l'XML sorgente contiene endpoint API interni, dati dei clienti o schemi proprietari che si preferisce non caricare da nessuna parte.