Comparaison JSON et XML

Je veux savoir qui est le plus rapide: XML et JSON? Quand utiliser lequel?

Avant de répondre quand utiliser lequel, un petit fond:

edit: Je devrais mentionner que cette comparaison est vraiment dans la perspective de les utiliser dans un navigateur avec JavaScript. Ce n’est pas la façon dont le format de données doit être utilisé, et il y a beaucoup de bons parsingurs qui changeront les détails pour faire ce que je dis pas tout à fait valide.

JSON est à la fois plus compact et (à mon avis) plus lisible – en transmission, il peut être “plus rapide” simplement parce que moins de données sont transférées.

En analysant, cela dépend de votre parsingur. Un parsingur transformant le code (que ce soit JSON ou XML) en une structure de données (comme une carte) peut tirer parti de la nature ssortingcte de XML ( les schémas XML désambiguïsent parfaitement la structure des données). Cependant, en JSON, le type d’un élément L’object JSON Number / Nested) peut être déduit syntaxiquement, par exemple:

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

L’parsingur n’a pas besoin d’être suffisamment intelligent pour réaliser que 12 représente un nombre (et Danielle est une chaîne comme une autre). Donc, en javascript, nous pouvons faire:

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

En XML, nous devrions faire quelque chose comme ceci:

  12 Danielle  

(en passant, ceci illustre le fait que XML est plus verbeux, une préoccupation pour la transmission de données). Pour utiliser ces données, nous les exécutions via un parsingur, puis nous devions appeler quelque chose comme:

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

En fait, un bon parsingur peut taper l’ age pour vous (d’autre part, vous ne le voudrez peut-être pas). Ce qui se passe lorsque nous accédons à ces données est – au lieu de faire une recherche d’atsortingbut comme dans l’exemple JSON ci-dessus – nous effectuons une recherche de carte sur le name la clé. Il pourrait être plus intuitif de former le XML comme ceci:

  

Mais nous aurions toujours à faire des recherches de cartes pour accéder à nos données:

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

EDIT: Original:

Dans la plupart des langages de programmation (pas tous, en tout cas), une recherche de carte comme celle-ci sera plus coûteuse qu’une recherche d’atsortingbut (comme ci-dessus lorsque nous avons analysé le JSON).

Cela est trompeur: rappelez-vous qu’en JavaScript (et dans d’autres langages dynamics), il n’y a pas de différence entre une recherche de carte et une recherche de champ. En fait, une recherche de champ est juste une recherche de carte.

Si vous voulez une comparaison vraiment intéressante, le mieux est de la comparer. Faites les tests dans le contexte où vous prévoyez d’utiliser les données.

Comme je tapais, Felix Kling a déjà donné une réponse assez succincte en les comparant en termes d’utilisation de chacun, donc je ne vais pas continuer.

Plus rapide n’est pas un atsortingbut de JSON ou de XML ou un résultat qu’une comparaison entre ceux-ci donnerait. Le cas échéant, il s’agit d’un atsortingbut des parsingurs ou de la bande passante avec laquelle vous transmettez les données.

Voici (au début de) une liste des avantages et inconvénients de JSON et XML:


JSON

Pro:

  • Syntaxe simple, qui se traduit par moins de surcharge de “balisage” par rapport à XML.
  • Facile à utiliser avec JavaScript, le balisage est un sous-ensemble de la notation littérale des objects JS et possède les mêmes types de données de base que JavaScript.
  • Schéma JSON pour la description et le type de données et la validation de la structure
  • JsonPath pour extraire des informations dans des structures profondément nestedes

Con:

  • Syntaxe simple, seule une poignée de types de données différents est prise en charge.

XML

Pro:

  • Balisage généralisé il est possible de créer des “dialectes” pour tout type d’object
  • Schéma XML pour le type de données, validation de la structure. Permet également de créer de nouveaux types de données
  • XSLT pour la transformation en différents formats de sortie
  • XPath / XQuery pour extraire des informations dans des structures profondément nestedes
  • prise en charge intégrée des espaces de noms

Con:

  • Relativement verbeux par rapport à JSON (donne plus de données pour la même quantité d’informations).

Donc, à la fin, vous devez décider de ce dont vous avez besoin . De toute évidence, les deux formats ont leurs cas d’utilisation légitimes. Si vous allez principalement utiliser JavaScript, vous devriez aller avec JSON.

N’hésitez pas à append des avantages et des inconvénients. Je ne suis pas un expert XML;)

La vitesse de traitement n’est peut-être pas la seule question pertinente, cependant, comme c’est la question, voici quelques chiffres dans un benchmark: JSON vs XML: quelques chiffres sur la verbosité . Pour la rapidité, dans ce simple test, XML présente une surcharge de 21% sur JSON.

Une note importante à propos de la verbosité, qui est, comme le dit l’article, la plainte la plus courante: ce n’est pas tellement pertinent en pratique (ni les données XML ni les données JSON ne sont généralement traitées par des humains, mais par des machines). vitesse, il faut un peu plus de temps pour compresser.

De plus, dans cette évaluation, une grande quantité de données a été traitée et une application Web classique ne transmettra pas des blocs de données de tailles telles que 90 Mo, et la compression risque de ne pas être bénéfique (pour des blocs de données suffisamment petits, un bloc compressé). sera plus grand que le morceau non compressé), donc non applicable.

Cependant, si aucune compression n’est impliquée, JSON, de toute évidence terser, pèsera moins sur le canal de transmission, surtout s’il est transmis via une connexion WebSocket, où l’absence de surcharge HTTP classique peut faire la différence important.

Une fois la transmission terminée, les données doivent être consommées et ce délai est pris en compte dans le temps de traitement global. Si des données suffisamment grandes ou complexes doivent être transmises, l’absence d’un schéma automatiquement vérifié par un parsingur XML de validation peut nécessiter davantage de vérification sur les données JSON; Ces vérifications devraient être exécutées en JavaScript, ce qui n’est pas connu pour être particulièrement rapide. Par conséquent, il pourrait en résulter une surcharge supplémentaire par rapport à XML.

Quoi qu’il en soit, seul le test sera la réponse à votre cas particulier (si la vitesse est vraiment la seule question, et non la norme, la sécurité ni l’intégrité…).

Mise à jour 1: il convient de mentionner EXI, le format XML binary, qui offre une compression à moindre coût que l’utilisation de Gzip, et le traitement de sauvegarde nécessaire pour décompresser le XML compressé. EXI est à XML, ce que BSON est à JSON. Ayez un aperçu rapide ici, avec une référence à l’efficacité dans l’espace et le temps: EXI: Le dernier standard binary? .

Mise à jour 2: il existe également des rapports de performances XML binarys, réalisés par le W3C, car l’efficacité et la faible mémoire et le faible encombrement du processeur sont également concernés par le domaine XML: Evaluation de l’échange XML efficace .

Mise à jour 2015-03-01

Cela vaut la peine d’être remarqué dans ce contexte, car la surcharge HTTP a été soulevée comme un problème: l’IANA a enregistré le codage EXI (le XML binary efficace mentionné ci-dessus) comme code de contenu pour le protocole HTTP (avec compress , deflate et gzip ) . Cela signifie qu’EXI est une option dont on peut s’attendre à ce que les navigateurs puissent la comprendre parmi d’autres clients HTTP. Voir Paramètres du protocole de transfert hypertexte (iana.org) .

J’ai trouvé cet article au bazar numérique vraiment intéressant. Citant leurs citations de Norm:

A propos des pros JSON:

Si tout ce que vous voulez faire circuler, ce sont des valeurs atomiques, des listes ou des hachages de valeurs atomiques, JSON présente de nombreux avantages: il est directement utilisable sur Internet, prend en charge une grande variété d’applications, il a peu de fonctionnalités optionnelles, il est lisible et raisonnablement clair, sa conception est formelle et concise, les documents JSON sont faciles à créer et utilisent Unicode. …

A propos de XML:

XML est remarquablement bien adapté à la richesse des données non structurées. Je ne m’inquiète pas du futur de XML, même si sa mort est joyeusement célébrée par un groupe de concepteurs d’API Web.

Et je ne peux pas résister à rentrer un “Je te l’avais bien dit!” jetez-vous dans mon bureau. Je suis impatient de voir ce que font les gens JSON lorsqu’ils sont invités à développer des API plus riches. Quand ils veulent échanger des données moins bien structurées, vont-ils les intégrer dans JSON? Je vois des mentions occasionnelles d’un langage de schéma pour JSON, d’autres langues suivront-elles? …

Je suis personnellement d’accord avec Norm. Je pense que la plupart des attaques contre XML proviennent des développeurs Web pour des applications typiques, et pas vraiment des développeurs d’intégration. Mais c’est mon avis! 😉

Le langage XML (Extensible Markup Language) est souvent utilisé car il s’agit d’un langage de diffusion standard, utilisable par tous les langages de programmation, et supporté côté serveur et côté client. Il s’agit donc de la solution la plus flexible. Le XML peut être séparé pour plus de parties afin qu’un groupe spécifié puisse développer la partie du programme sans affecter les autres parties. Le format XML peut également être déterminé par XML DTD ou XML Schema (XSL) et peut être testé.

Le JSON est un format d’échange de données qui devient de plus en plus populaire en tant que format d’application JavaScript possible. Fondamentalement, il s’agit d’un tableau de notation d’object. JSON a une syntaxe très simple et peut donc être facilement apprise. Et aussi la prise en charge de JavaScript en analysant JSON avec la fonction eval . Par contre, la fonction eval a des négatifs. Par exemple, le programme peut être très lent en analysant JSON et en raison de la sécurité, l’ eval peut être très risquée. Cela ne signifie pas que le JSON n’est pas bon, il faut juste être plus prudent.

Ma suggestion est que vous devriez utiliser JSON pour les applications avec échange de données léger, comme les jeux. Comme vous n’avez pas à vous soucier vraiment du traitement des données, c’est très simple et rapide.

Le XML est le meilleur pour les plus grands sites Web, par exemple les sites commerciaux ou quelque chose du genre. Le XML peut être plus sûr et plus clair. Vous pouvez créer une structure de données et un schéma de base pour tester facilement la correction et la séparer facilement en plusieurs parties.

Je vous suggère d’utiliser XML à cause de la vitesse et de la sécurité, mais JSON pour les choses légères.

L’important à propos de JSON est de garder le transfert de données crypté pour des raisons de sécurité. Nul doute que JSON est beaucoup plus rapide que XML. J’ai vu XML prendre 100ms où JSON ne prenait que 60ms. Les données JSON sont faciles à manipuler.