Confronto JSON e XML [chiuso]

Voglio sapere quale è più veloce: XML e JSON? Quando usare quale?

Prima di rispondere a quando usare quale, un piccolo sfondo:

modifica: dovrei menzionare che questo confronto è davvero dal punto di vista del loro utilizzo in un browser con JavaScript. Non è il modo in cui entrambi i formati di dati devono essere utilizzati e ci sono molti buoni parser che cambieranno i dettagli per rendere ciò che sto dicendo non del tutto valido.

JSON è sia più compatto che (a mio avviso) più leggibile - in trasmissione può essere "più veloce" semplicemente perché vengono trasferiti meno dati.

Nell'analisi, dipende dal tuo parser. Un parser che trasforma il codice (sia esso JSON o XML) in una struttura di dati (come una mappa) può trarre vantaggio dalla natura rigorosa di XML ( gli schemi XML chiariscono bene la struttura dei dati) - tuttavia in JSON il tipo di un elemento (String / Numero / oggetto JSON nidificato) può essere dedotto sintatticamente, ad esempio:

myJSON = {"age" : 12,
          "name" : "Danielle"}

Il parser non ha bisogno di essere abbastanza intelligente da capire che 12rappresenta un numero (ed Danielleè una stringa come qualsiasi altra). Quindi in JavaScript possiamo fare:

anObject = JSON.parse(myJSON);
anObject.age === 12 // True
anObject.name == "Danielle" // True
anObject.age === "12" // False

In XML dovremmo fare qualcosa di simile al seguente:

<person>
    <age>12</age>
    <name>Danielle</name>
</person>

(a parte questo, illustra il fatto che XML è piuttosto più dettagliato, una preoccupazione per la trasmissione dei dati). Per utilizzare questi dati, li eseguiremo attraverso un parser, quindi dovremmo chiamare qualcosa del tipo:

myObject = parseThatXMLPlease();
thePeople = myObject.getChildren("person");
thePerson = thePeople[0];
thePerson.getChildren("name")[0].value() == "Danielle" // True
thePerson.getChildren("age")[0].value() == "12" // True

In realtà, un buon parser potrebbe benissimo digitarlo ageper te (d'altra parte, potresti non volerlo). Cosa succede quando accediamo a questi dati è - invece di fare una ricerca degli attributi come nell'esempio JSON sopra - stiamo facendo una ricerca della mappa sulla chiave name. Potrebbe essere più intuitivo formare l'XML in questo modo:

<person name="Danielle" age="12" />

Ma dovremmo comunque effettuare ricerche di mappe per accedere ai nostri dati:

myObject = parseThatXMLPlease();
age = myObject.getChildren("person")[0].getAttr("age");

MODIFICA: Originale:

Nella maggior parte dei linguaggi di programmazione (non tutti, per ogni tratto) una ricerca di mappe come questa sarà più costosa di una ricerca di attributi (come abbiamo visto sopra quando abbiamo analizzato il JSON).

Questo è fuorviante: ricorda che in JavaScript (e altri linguaggi dinamici) non c'è differenza tra una ricerca di mappe e una ricerca di campo. In effetti, una ricerca sul campo è solo una ricerca sulla mappa.

Se si desidera un confronto davvero utile, la cosa migliore è fare un benchmark: fare i benchmark nel contesto in cui si prevede di utilizzare i dati.

Mentre scrivevo, Felix Kling ha già fornito una risposta abbastanza concisa confrontandola in termini di quando usarla, quindi non proseguirò più.

Più veloce non è un attributo di JSON o XML o un risultato che un confronto tra questi produrrebbe. Se presente, allora è un attributo dei parser o della larghezza di banda con cui si trasmettono i dati.

Ecco (l'inizio di) un elenco di vantaggi e svantaggi di JSON e XML:

JSON

Pro:

• Sintassi semplice, che comporta un overhead di "markup" inferiore rispetto a XML.
• Facile da usare con JavaScript poiché il markup è un sottoinsieme della notazione letterale dell'oggetto JS e ha gli stessi tipi di dati di base di JavaScript.
• Schema JSON per la descrizione, il tipo di dati e la convalida della struttura
• JsonPath per l'estrazione di informazioni in strutture profondamente annidate

con:

• Sintassi semplice, sono supportati solo pochi tipi di dati diversi.

• Nessun supporto per i commenti.

XML

Pro:

• Markup generalizzato; è possibile creare "dialetti" per qualsiasi tipo di scopo
• Schema XML per tipo di dati, convalida della struttura. Consente inoltre di creare nuovi tipi di dati
• XSLT per trasformazione in diversi formati di output
• XPath / XQuery per l'estrazione di informazioni in strutture profondamente annidate
• supporto integrato per gli spazi dei nomi

con:

• Relativamente prolisso rispetto a JSON (risulta in più dati per la stessa quantità di informazioni).

Quindi alla fine devi decidere di cosa hai bisogno . Ovviamente entrambi i formati hanno i loro casi d'uso legittimi. Se utilizzerai principalmente JavaScript, dovresti andare con JSON.

Sentiti libero di aggiungere pro e contro. Non sono un esperto XML;)

La velocità di elaborazione potrebbe non essere l'unica questione rilevante, tuttavia, poiché questa è la domanda, ecco alcuni numeri in un benchmark: JSON vs. XML: alcuni numeri concreti sulla verbosità . Per la velocità, in questo semplice benchmark, XML presenta un overhead del 21% su JSON.

Una nota importante sulla verbosità, che è come dice l'articolo, il reclamo più comune: questo non è molto rilevante nella pratica (né i dati XML né JSON sono generalmente gestiti da umani, ma da macchine), anche se per la questione di velocità, richiede un po 'di tempo ragionevole per comprimere.

Inoltre, in questo benchmark, è stata elaborata una grande quantità di dati e un'applicazione Web tipica non trasmetterà blocchi di dati di dimensioni tali, fino a 90 MB, e la compressione potrebbe non essere vantaggiosa (per blocchi di dati abbastanza piccoli, un blocco compresso sarà più grande del pezzo non compresso), quindi non applicabile.

Tuttavia, se non è implicata alcuna compressione, JSON, come ovviamente terser, peserà meno sul canale di trasmissione, specialmente se trasmesso attraverso una connessione WebSocket, dove l'assenza del classico overhead HTTP può fare la differenza a vantaggio di JSON, anche di più significativo.

Dopo la trasmissione, i dati devono essere consumati e questo conta nel tempo complessivo di elaborazione. Se devono essere trasmessi dati abbastanza grandi o complessi, la mancanza di uno schema verificato automaticamente da un parser XML di convalida può richiedere un controllo più approfondito sui dati JSON; questi controlli dovrebbero essere eseguiti in JavaScript, che non è noto per essere particolarmente veloce, e quindi in questi casi potrebbe presentare un sovraccarico aggiuntivo su XML.

Ad ogni modo, solo i test forniranno la risposta per il tuo particolare caso d'uso (se la velocità è davvero l'unica cosa, e non standard, né sicurezza, né integrità ...).

Aggiornamento 1: vale la pena ricordare, è EXI, il formato XML binario, che offre la compressione a un costo inferiore rispetto all'utilizzo di Gzip e risparmia l'elaborazione altrimenti necessaria per decomprimere l'XML compresso. EXI è XML, ciò che BSON è JSON. Avere una rapida panoramica qui, con qualche riferimento all'efficienza sia nello spazio che nel tempo: EXI: l'ultimo standard binario? .

Aggiornamento 2: esiste anche un rapporto binario sulle prestazioni XML, condotto dal W3C, in quanto efficienza, memoria insufficiente e footprint della CPU, è un aspetto che interessa anche l'area XML: un'efficace valutazione dell'interscambio XML .

Aggiornamento 01-03-2015

Vale la pena di essere notato in questo contesto, poiché l'overhead HTTP è stato sollevato come un problema: lo IANA ha registrato la codifica EXI (l'efficiente codice binario XML sopra menzionato), come una codifica dei contenuti per il protocollo HTTP (insieme a compress , deflate e gzip ) . Ciò significa che EXI è un'opzione che può essere compresa dai browser probabilmente da altri client HTTP. Vedere i parametri del protocollo di trasferimento ipertestuale (iana.org) .

Ho trovato questo articolo al bazar digitale davvero interessante. Citando le loro citazioni da Norm:

Informazioni sui professionisti JSON:

Se tutto ciò che vuoi passare sono valori atomici o elenchi o hash di valori atomici, JSON ha molti dei vantaggi di XML: è facilmente utilizzabile su Internet, supporta un'ampia varietà di applicazioni, è facile scrivere programmi per elaborare JSON, ha poche funzionalità opzionali, è leggibile e ragionevolmente chiaro, il suo design è formale e conciso, i documenti JSON sono facili da creare e utilizza Unicode. ...

Informazioni sui professionisti XML:

XML si occupa in modo straordinario della piena ricchezza di dati non strutturati. Non sono affatto preoccupato per il futuro di XML, anche se la sua morte è celebrata allegramente da un gruppo di progettisti di API Web.

E non posso resistere a infilare un "Te l'ho detto!" token via nella mia scrivania. Non vedo l'ora di vedere cosa fanno le persone JSON quando viene loro chiesto di sviluppare API più ricche. Quando vogliono scambiare dati meno strutturati, li calcheranno su JSON? Vedo menzioni occasionali di un linguaggio di schema per JSON, seguiranno altre lingue? ...

Sono personalmente d'accordo con Norm. Penso che la maggior parte degli attacchi a XML provenga da sviluppatori Web per applicazioni tipiche e non da sviluppatori di integrazione. Ma questa è la mia opinione! ;)

L'XML (extensible Markup Language) viene spesso utilizzato XHR perché si tratta di un linguaggio di trasmissione standard, che può essere utilizzato da qualsiasi linguaggio di programmazione, e supporta sia il server che il lato client, quindi questa è la soluzione più flessibile. L'XML può essere separato per più parti in modo che un gruppo specificato possa sviluppare la parte del programma, senza influire sulle altre parti. Il formato XML può anche essere determinato dal DTD XML o dallo Schema XML (XSL) e può essere testato.

JSON è un formato di scambio di dati che sta diventando sempre più popolare come il formato possibile delle applicazioni JavaScript. Fondamentalmente questa è una matrice di notazione di oggetti. JSON ha una sintassi molto semplice, quindi può essere facilmente appreso. E anche il supporto JavaScript che analizza JSON con la evalfunzione. D'altra parte, la evalfunzione ha aspetti negativi. Ad esempio, il programma può essere molto lento nell'analisi di JSON e, a causa della sicurezza, evalpuò essere molto rischioso. Questo non significa che JSON non sia buono, dobbiamo solo stare più attenti.

Il mio suggerimento è di usare JSON per applicazioni con leggero scambio di dati, come i giochi. Poiché non devi preoccuparti davvero del trattamento dei dati, questo è molto semplice e veloce.

L'XML è il migliore per i siti Web più grandi, ad esempio siti di shopping o qualcosa del genere. L'XML può essere più sicuro e chiaro. È possibile creare una struttura e uno schema di dati di base per testare facilmente la correzione e separarla facilmente in parti.

Ti suggerisco di utilizzare XML a causa della velocità e della sicurezza, ma JSON per roba leggera.

L'importante di JSON è mantenere crittografato il trasferimento dei dati per motivi di sicurezza. Non c'è dubbio che JSON è molto più veloce di XML. Ho visto XML impiegare 100 ms, mentre JSON ha impiegato solo 60 ms. I dati JSON sono facili da manipolare.