Differenze tra XML e JSON per lo scambio di dati

1

Mi sto interrogando sulle differenze tra XML e JSON.

Senza alcun riguardo agli strumenti di elaborazione e ai sistemi di back-end esistenti e semplicemente come mezzo per rappresentare i dati, c'è qualcosa che JSON fa meglio di XML o viceversa? Oppure possono entrambi essere utilizzati nella stessa misura?

vale a dire. c'è qualcosa che potrebbe essere rappresentato da JSON che XML non potrebbe rappresentare o viceversa?

    
posta scrineym 11.11.2015 - 15:46
fonte

3 risposte

7

XML e JSON sono entrambi in grado di trasmettere gli stessi dati, ma il che è meglio dipende principalmente da ciò che si vuole fare con esso.

Questo tocca gli strumenti esistenti, ma non è probabile che si tratti di parser manuali per entrambi, quindi è rilevante.

XML

  • Ha strumenti migliori per la verifica dello schema.
  • È stato integrato nel supporto per gli spazi dei nomi.
  • Può essere più facilmente ristrutturato in HTML.
  • Può essere interrogato con XPath, che è un linguaggio di query davvero eccezionale - pensa SQL per XML. Non ho davvero visto un equivalente per JSON - ma mi piacerebbe sentirlo se mi sbaglio su questo.

JSON

  • Ha una cerimonia significativamente più bassa (e, almeno nella mia esperienza, una migliore stampante), quindi quando un essere umano deve guardarlo, può essere più facile da leggere.
  • È, senza sorprese, il miglior formato quando una parte del trasferimento è scritta in JavaScript.
  • Ha meno eredità, quindi la possibilità di essere costretti ad accettare JSON malformato è inferiore. Non vi è alcuna aspettativa culturale che si debba accettare input malformati.

Dato che uno è in grado di immagazzinare tutto ciò che può essere immagazzinato nell'altro, l'usabilità e gli strumenti è l'unico criterio che è utile per confrontare come è usarli.

Se tutto ciò che è stato cancellato, probabilmente non ne userei né, e trasmetterò i dati come blocchi di Lisp.

È una cerimonia inferiore a JSON (a malapena), molto più facile da trasformare rispetto all'XML, e più facile scrivere un parser per entrambi (cosa che dovrei fare se tutti gli strumenti fossero spariti).

    
risposta data 11.11.2015 - 16:11
fonte
5

È un po 'di mele e arance. Sono entrambi utilizzati per lo stesso compito sì, ma sono distintamente diversi.

XML è Extensible Markup Language. Il vantaggio principale di questo è che può occuparsi dei metadati. In breve:

<tag attribute="something">data</tag>

Quindi avere attributi sui tuoi elementi ti consente di essere più esplicito.

Di più su questo puoi avere uno schema predefinito che applica le tue regole definite della struttura. Ad es. alcuni elementi potrebbero utilizzare determinati attributi, ma se altri tentano di usarlo, la convalida dello schema ti darà un errore.

Questo dà molto potere. Ma con un grande potere derivano grandi responsabilità. Spesso questi XML rappresentano strutture e relazioni più che i dati stessi. Quindi diventa difficile leggere per un umano a causa di tutte le informazioni aggiuntive che trasporta. Quindi, per alcune operazioni, è più ingombrante dal momento che si desidera salvare 5 righe di dati con 20 o più righe di xml perché è necessario soddisfare lo schema.

Wikipedia ne ha un buon riassunto: link

JSON d'altra parte ha il solo scopo di rappresentare i dati e nient'altro. Ottieni i principali tipi di dati:

  • I numeri interi
  • Le stringhe
  • booleane
  • Array
  • Dizionari

Ecco fatto. Puoi annidarli in qualsiasi modo tu voglia ma questo è il tuo limite. Usi solo quei tipi di dati. Altro qui: link

Certo, puoi spostare gli attributi sul proprio array all'interno del dizionario o così e potresti ottenere la maggior parte degli stessi, e questo è il motivo per cui viene spesso menzionato questo confronto. Ma al centro di tutto ci sono 2 strumenti per diversi usi. Proprio quando ottieni un martello tutto diventa un chiodo.

XML è grande quando si hanno strutture complesse, relazioni tra oggetti, forse anche l'override di un file di un altro (gestito da un'altra risposta citata XPath).

JSON è eccezionale quando è necessario comunicare con oggetti di piccole dimensioni che potrebbero avere la propria convalida eseguita nel codice. Inoltre è leggibile e semplice da usare.

    
risposta data 11.11.2015 - 16:41
fonte
4

XML è un eXtensible Markup Language . È importante capire: è progettato per essere essenzialmente simile all'HTML, un linguaggio di markup del documento, ma un po 'più formalizzato. Il problema è che il markup del documento non è quello per cui nessuno lo usa. La gente lo abusa per l'archiviazione dei dati e lo scambio di dati, che è una pessima idea perché l'archiviazione dei dati non è qualcosa come il markup del documento.

Un tipico documento HTML ha un elevato rapporto content-to-markup. È abbastanza possibile scrivere intere pagine senza dover inserire un singolo tag oltre il <p> occasionale, ad esempio. Ma nella memorizzazione dei dati, ogni elemento di dati deve essere definito in un modo formale. Con XML, tutto si trasforma in un pasticcio di zuppa tag molto velocemente. Ad esempio:

Some people, when presented with a problem, think “I know, I’ll use XML.”

<Problem:Worsening> <Problem:TimeDescription>Now</Problem:TimeDescription> <Problem:Posessive>they have</Problem:Posessive> <Problem:Quantity>many, many</Problem:Quantity> <Problem:WorseningDescription>more problems</Problem:WorseningDescription> </Problem:Worsening>

Vediamo che il contenuto molto facilmente finisce completamente sommerso da tutti i tag. (Questo è spesso vero anche quando l'XML è stato stampato a caratteri cubitali.)

Inoltre, XML richiede che ogni <tag> debba essere chiuso da un corrispondente </tag> . Richiede inoltre che le tag vengano chiuse in rigoroso ordine LIFO (cioè Stack). Questo è ridondante: se l'unico tag valido per chiudere è l'ultimo che non è stato ancora chiuso, ogni tag di chiusura potrebbe teoricamente essere un semplice </> senza perdita di informazioni semantiche. (Sarebbe più difficile da seguire se non lo stampassi bene, ma chi vuole comunque provare a leggere l'XML non-pretty-stamp?) Ciò rende i file XML più grandi e ingombranti di quello che devono essere.

Il modello DOM XML è anche incredibilmente complesso. Solo per i principianti, hai due modi distinti di rappresentare i sotto-dati su un nodo: nodi tra il tag di apertura e il suo tag di chiusura e Attributi all'interno del tag di apertura. Di nuovo, questa è un'idea che ha molto senso nel markup del documento ( <a href="http://example.com"> ) ma molto meno per l'archiviazione dei dati. Allora hai tutti i tipi di complessità aggiuntive come spazi dei nomi, schemi e convalida, XSLT e così via ...

La principale differenza tra XML e JSON è che JSON è solo un formato di archiviazione dei dati . È ottimizzato per esprimere i dati serializzati, non per il markup del documento, e quindi fa un lavoro molto migliore di esprimere i dati serializzati. Douglas Crockford lo chiama "l'alternativa senza grassi a XML."

La cosa veramente interessante è che riesce a farlo senza perdere alcun potere. Vuoi schemi e convalida? Usa schema JSON. Interrogazioni? C'è JSONPath per quello. (E se, d'altra parte, non ti importa di queste cose, non hai bisogno di alcun codice per farlo gonfiare il tuo programma.) Vuoi commenti e spazi dei nomi, o anche attributi? {"namespace": "MyNamespace", "attributes": {"attrib1": "value1", "attrib2": "value2"}, "data": "Insert content here", "comment": "It's that simple"}

Per rispondere alla domanda originale, non ci sono dati che possono essere rappresentati in entrambi i sistemi che l'altro non può fare anche. È molto più piccolo e pulito in JSON, quasi ogni volta, perché JSON è stato specificamente progettato per l'archiviazione dei dati e XML non lo era. È una semplice questione di "utilizzare lo strumento giusto per il lavoro".

    
risposta data 11.11.2015 - 17:32
fonte

Leggi altre domande sui tag