XML in JSON e viceversa
Incolla o carica un XML e ottieni il JSON corrispondente, oppure fai il percorso inverso. Se l'XML è rotto ti diciamo a quale riga, a quale colonna e quale regola è saltata.
Oppure trascina qui un file .xml o .json, o tocca per sceglierlo
Come si legge la conversione
Un elemento XML diventa un oggetto JSON. Gli attributi prendono il prefisso @, quindi <prezzo valuta="EUR">12.90</prezzo> diventa {"@valuta":"EUR","#text":"12.90"}. Se un elemento ha solo testo e nessun attributo, il valore è direttamente la stringa; se è vuoto vale null. Gli elementi fratelli con lo stesso nome diventano una lista, e l'elemento radice resta come unica chiave in cima. La convenzione non può dare collisioni perché la chiocciola e il cancelletto non sono ammessi in un nome XML, quindi nessun elemento potrà mai chiamarsi #text.
La trappola degli elenchi con un solo elemento
È l'errore che si paga in produzione. Se il tracciato contiene tre <riga> ottieni una lista, ma se lo stesso tracciato ne contiene una sola ottieni un oggetto, e il codice che scorre la lista si rompe con un file che sembrava identico. Nessun convertitore può indovinarlo dal solo XML, perché la cardinalità sta nello schema (XSD), non nei dati. Per questo c'è la casella che mette sempre i figli in una lista: attivala quando il JSON deve essere letto da un programma, lasciala spenta quando ti serve un JSON leggibile a occhio.
Quello che il tool non porta dentro il JSON
Commenti e istruzioni di elaborazione restano fuori, perché in JSON non esiste un posto dove metterli, e te lo diciamo con un avviso invece di farlo in silenzio. Le sezioni CDATA diventano testo normale. Il DOCTYPE viene saltato, quindi le entità dichiarate in un DTD non vengono risolte: se ne compare una il tool si ferma e ti dice quale. I prefissi dei namespace restano scritti così come sono (soap:Envelope resta soap:Envelope), senza risolvere gli URI. Gli spazi all'inizio e alla fine del testo di un elemento vengono tolti.
Perché l'errore indica riga e colonna
Il controllo è fatto da un parser scritto apposta per questa pagina, non dal lettore XML del browser, che dà messaggi diversi su Chrome, Firefox e Safari. Così puoi vedere il punto esatto e la regola violata: le virgolette degli attributi in XML sono obbligatorie, i tag vanno chiusi nell'ordine inverso a quello di apertura, l'elemento radice deve essere uno solo e una e commerciale isolata va scritta &. Sono i quattro motivi per cui un export di un gestionale viene rifiutato quasi sempre.
Il ritorno da JSON a XML, e la codifica dei file
Nel verso opposto le chiavi diventano elementi, quelle con la chiocciola diventano attributi, #text diventa il testo e le liste diventano elementi ripetuti. Se una chiave non può essere un nome XML valido (inizia con una cifra, contiene uno spazio) il tool si ferma e ti dice quale, invece di storpiarla. I caratteri speciali vengono protetti sia nel testo sia negli attributi. Quando carichi un file che dichiara una codifica diversa da UTF-8, per esempio ISO-8859-1 come fanno molti gestionali italiani, il file viene riletto con quella codifica e il risultato è sempre UTF-8. Tutto avviene nel browser, senza inviare nulla a un server.