Comparaison JSON et XML]
6 réponses
avant de répondre quand utiliser lequel, un peu de fond:
edit: je dois mentionner que cette comparaison est vraiment de la perspective de les utiliser dans un navigateur avec JavaScript. Ce n'est pas la façon dont le format de données a à utiliser, et il ya beaucoup de bons analyseurs qui vont changer les détails pour rendre ce que je dis pas tout à fait valide.
JSON est à la fois plus compact et (à mon avis) plus lisible - dans la transmission, il peut être "plus rapide" simplement parce que moins de données sont transférées.
en parsing, cela dépend de votre analyseur. Un analyseur tournant le code (que ce soit JSON ou XML) en une structure de données (comme une carte) peut bénéficier de la nature stricte de XML ( XML Schemas désambiguer la structure de données bien) - cependant dans JSON le type d'un élément (String/Number/Nested JSON Object) peut être déduit syntaxiquement, E. g:
myJSON = {"age" : 12,
"name" : "Danielle"}
L'analyseur n'a pas besoin d'être assez intelligent pour réaliser que 12 représente un nombre, (et Danielle est une chaîne comme les autres). Ainsi, en javascript, nous pouvons faire:
anObject = JSON.parse(myJSON);
anObject.age === 12 // True
anObject.name == "Danielle" // True
anObject.age === "12" // False
en XML, nous aurions à faire quelque chose comme ceci:
<person>
<age>12</age>
<name>Danielle</name>
</person>
(soit dit en passant, cela illustre le fait que le langage XML est un peu plus verbeux; un souci de transmission de données). Pour utiliser ces données, nous les passerions à travers un analyseur, puis nous
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 analyseur pourrait bien taper le age pour vous (d'un autre côté, vous pourriez bien ne pas vouloir). Ce qui se passe lorsque nous accédons à ces données est - au lieu de faire une recherche d'attribut comme dans L'exemple JSON ci - dessus-nous faisons une recherche de carte sur la clé name . Il pourrait être plus intuitif de former le XML comme ceci:
<person name="Danielle" age="12" />
mais nous aurions encore à faire des recherches de carte à 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, par extension) une recherche de carte comme celle-ci sera plus coûteuse qu'une recherche d'attribut (comme nous sommes allés plus haut quand nous avons analysé le JSON).
ceci est trompeur: rappelez-vous que dans JavaScript (et d'autres langages dynamiques) il y a aucune différence entre une recherche de carte et une champ de recherche. En fait, une recherche de terrain est juste une recherche de carte.
si vous voulez une comparaison vraiment valable, le mieux est de benchmark it - faire les benchmarks dans le contexte où vous prévoyez d'utiliser les données.
comme J'ai tapé, Felix Kling a déjà mis en place une réponse assez succincte les comparant en termes de quand utiliser chacun d'eux, donc je ne vais pas aller plus loin.
Faster n'est pas un attribut de JSON ou XML ou un résultat qu'une comparaison entre ceux-ci donnerait. Le cas échéant, il s'agit d'un attribut des analyseurs ou de la bande passante avec laquelle vous transmettez les données.
voici (le début de) une liste d'avantages et d'inconvénients de JSON et XML:
JSON
Pro:
- syntaxe Simple, qui résulte en moins de" markup " overhead par rapport à XML.
- facile à utiliser avec JavaScript car le markup est un sous-ensemble de notation littérale objet JS et a les mêmes types de données de base que JavaScript.
- JSON Schema pour la description et le type de données et la structure de validation
- JsonPath pour extraire des informations dans des structures profondément imbriquées
Con:
- syntaxe Simple, seulement une poignée de différents types de données sont pris en charge.
XML
Pro:
- Generalized markup; il est possible de créer des "dialectes" pour tout type de but
- schéma XML pour type de données, la structure de validation. Permet également de créer de nouveaux types de données
- XSLT pour la transformation en différents formats de sortie
- XPath / XQuery pour l'extraction d'informations dans des structures profondément imbriquées
- construit en support pour les espaces de noms
Con:
- relativement verbeux comparé à JSON (résultats dans plus de données pour la même quantité d'information).
donc, à la fin, vous devez décider ce que vous besoin . Évidemment, les deux formats ont leurs cas d'utilisation légitime. Si vous allez principalement utiliser JavaScript, alors vous devriez aller avec JSON.
s'il vous Plaît n'hésitez pas à ajouter des avantages et des inconvénients. Je ne suis pas un expert en XML ;)
la vitesse de traitement peut ne pas être la seule question pertinente, mais comme c'est la question, voici quelques chiffres dans un benchmark: JSON vs XML: quelques chiffres durs sur la verbosité . Pour la vitesse, dans ce benchmark simple, XML présente un overhead de 21% sur JSON.
une note importante sur la verbosité, qui est, comme le dit l'article, la plainte la plus fréquente: ce n'est pas tellement pertinent dans la pratique (ni XML ni JSON données ne sont généralement manipulée par les humains, mais par des machines), même si pour la question de la vitesse, il faut un peu plus de temps raisonnable pour compresser.
en outre, dans ce benchmark, une grande quantité de données a été traitée, et une application web typique ne transmet pas des morceaux de données de telles tailles, aussi grand que 90 Mo, et la compression peut ne pas être bénéfique (pour les petits morceaux de données assez, un morceau comprimé sera plus grand que le morceau non compressé), donc non applicable.
Encore, si aucune la compression est impliquée, JSON, comme évidemment terser, pèsera moins sur le canal de transmission, surtout si elle est transmise via une connexion WebSocket, où l'absence du HTTP classique peut faire la différence à l'avantage de JSON, encore plus significative.
après la transmission, les données doivent être consommées, et cela compte dans le temps de traitement global. Si grand ou suffisamment complexe pour les données doivent être transmises, l'absence d'un schéma vérifiée automatiquement par un analyseur XML de validation, peut exiger plus de vérification sur les données JSON; ces vérifications devraient être exécutées en JavaScript, qui n'est pas connu pour être particulièrement rapide, et il peut donc présenter un overhead supplémentaire sur XML dans de tels cas.
de toute façon, seuls les tests fourniront la réponse pour votre cas d'utilisation particulier (si la vitesse est vraiment la seule question, et pas la norme, la sécurité ou l'intégrité...).
mise à Jour 1: la peine de mentionner, est EXI, le format binaire XML, qui offre la compression à moindre coût que L'utilisation de Gzip, et de sauver le traitement autrement nécessaire pour décompresser XML comprimé. EXI est à XML, ce que BSON est à JSON. Vous avez un rapide aperçu ici, avec quelques références à l'efficacité dans l'espace et le temps: EXI: le dernier standard binaire? .
mise à jour 2: Il existe également un binaire XML rapports de performance, menée par le W3C, comme l'efficacité et la faible mémoire et l'empreinte CPU, est aussi une question pour le domaine XML aussi: évaluation efficace de L'échange XML .
mise à jour 2015-03-01
vaut la peine d'être remarqué dans ce contexte, car la charge HTTP a été soulevée comme un problème: L'IANA a enregistré l'encodage existant (le XML binaire efficace mentionné ci-dessus), comme un codage de contenu pour le protocole HTTP (avec compresse , deflate et gzip ). Cela signifie que EXI est une option que l'on peut s'attendre à ce qu'elle soit comprise par les navigateurs parmi éventuellement 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:
à propos de JSON pros:
si tout ce que vous voulez passer sont des valeurs atomiques ou des listes ou des hachures de les valeurs atomiques, JSON a beaucoup d'avantages de XML: il est directement utilisable sur Internet, prend en charge une grande variété de applications, il est facile d'écrire des programmes pour traiter JSON, il a quelques caractéristiques optionnelles, lisible par l'homme et raisonnablement clair, sa conception est formel et concis, les documents JSON sont faciles à créer, et il utilise Unicode. ...
à propos de XML pros:
XML traite remarquablement bien avec toute la richesse de non structuré données. Je ne m'inquiète pas du tout de L'avenir de XML même si sa mort est joyeusement célébré par un cadre de concepteurs D'API web.
Et I ne peut pas résister à l'insérant un "je vous l'avais dit!"jeton loin dans mon Desk. J'ai hâte de voir ce que les gens de JSON font quand ils sont on leur a demandé de développer des IPA plus riches. Quand ils veulent échanger moins bien des données structurées, vont-elles être jetées dans JSON? Je vois occasionnel mention d'un langage schema pour JSON, d'autres langues suivront-elles? ...
je suis personnellement D'accord avec Norm. Je pense que la plupart des attaques à XML proviennent de développeurs Web pour des applications typiques, et pas vraiment des développeurs d'intégration. Mais c'est mon opinion! ;)
le XML (extensible Markup Language) est souvent utilisé XHR parce qu'il s'agit d'un langage de diffusion standard, ce qui peut être utilisé par n'importe quel langage de programmation, et pris en charge à la fois côté serveur et côté client, de sorte qu'il s'agit de la solution la plus souple. Le XML peut être séparé pour plusieurs parties de sorte 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 la DTD XML ou le schéma XML (XSL) et peut être testé.
Le JSON un format d'échange de données qui devient plus populaire que le format JavaScript applications possibles. Fondamentalement, il s'agit d'un tableau de notation d'objet. JSON a une syntaxe très simple donc peut être facilement appris. Et aussi le JavaScript soutient parsing JSON avec la fonction eval . D'un autre côté, la fonction eval est négative. Par exemple, le programme peut être très lent parsing JSON et à cause de la sécurité le eval peut être très risqué. Cela ne signifie pas que le JSON c'est pas bon, on doit juste être plus prudent.
ma suggestion est que vous devriez utiliser JSON pour des applications avec light data-exchange, comme des jeux. Parce que 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 de magasinage ou quelque chose comme ça. Le XML peut être plus sûr et plus clair. Vous pouvez créer la structure de données de base et le schéma pour tester facilement la correction et de les séparer en parties facilement.
je vous suggère D'utiliser XML en raison de la vitesse et de la sécurité, mais JSON pour les trucs légers.
l'important à propos de JSON est de garder le transfert de données crypté pour des raisons de sécurité. Il ne fait aucun doute que JSON est beaucoup plus rapide que XML. J'ai vu XML prendre 100ms où as JSON n'a pris que 60ms. JSON data est facile à manipuler.