270 votes

Comparaison de JSON et XML

Je veux savoir qui est plus rapide : XML et JSON ? Quand faut-il utiliser celui qui ?

242voto

Felix Kling Points 247451

Plus rapide n'est pas un attribut de JSON ou XML ou un résultat d'une comparaison entre ceux qui donneraient. Le cas échéant, alors c'est un attribut de la analyseurs ou de la bande passante permettant de transmettre les données.

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


JSON

Pro:

  • La syntaxe est Simple, ce qui entraîne moins de "balisage" frais généraux par rapport à XML.
  • Facile à utiliser avec du JavaScript, le langage est un sous-ensemble de JS objet de la notation littérale et a les mêmes types de données de base en JavaScript.

Con:

  • La syntaxe est Simple, seule une poignée de différents types de données est pris en charge.

XML

Pro:

  • Balisage généralisé, il est possible de créer des "dialectes" pour tout type de but
  • Schéma XML pour le type de données, la structure de validation. Il rend également possible de créer de nouveaux types de données.
  • XSLT de transformation en différents formats de sortie.
  • XPath/XQuery pour en extraire des informations (ce qui permet d'obtenir de l'information dans des structures profondément imbriquées et beaucoup plus facile qu'avec JSON).

Con:

  • Relativement long par rapport à JSON (plus les résultats sont données pour la même quantité d'information).

Si à la fin vous avez à décider ce dont vous avez besoin. Évidemment, les deux formats ont leurs légitimes des cas d'utilisation. Si vous êtes principalement à l'utilisation de JavaScript, alors vous devriez aller avec JSON.

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

219voto

jelford Points 1137

Avant de répondre quand utiliser l'un, un peu de contexte:

edit: je tiens à préciser que cette comparaison est vraiment du point de vue de leur utilisation dans un navigateur avec JavaScript. Ce n'est pas la façon dont les données de format a à être utilisé, et il ya beaucoup de bons analyseurs qui va changer les détails pour faire ce que je veux dire, pas tout à fait valide.

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

Dans l'analyse, cela dépend de votre analyseur. Un analyseur tournant le code (JSON ou XML) dans une structure de données (comme une carte) peuvent bénéficier de la sévérité de XML (XML Schémas de lever l'ambiguïté de la structure de données bien) - mais en JSON le type d'un élément (Chaîne de/Nombre de/Imbriquée Objet JSON) peut être déduite du point de vue syntaxique, l'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). Donc, en javascript, on peut faire:

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

En XML, nous aimerions avoir à faire quelque chose comme ce qui suit:

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

(en aparté, cela illustre le fait que XML est un peu plus détaillé; un sujet de préoccupation pour la transmission de données). L'utilisation de ces données, nous avions le lancer à travers un analyseur, nous aurions à 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 analyseur pourrait bien le type de l' age (pour vous, d'autre part, vous pouvez bien voulez pas qu'elle). Ce qui se passe lorsque nous avons accès à ces données est - au lieu de faire un attribut de recherche comme dans le JSON exemple ci - dessus, nous faisons un plan de recherche sur la touche name. Il pourrait être plus intuitive pour former le XML comme ceci:

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

Mais nous avions encore à faire la carte des recherches pour accéder à nos données:

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

EDIT: Origine:

Dans la plupart des langages de programmation (pas tous, par un effort), une carte de recherche tels que ce sera plus coûteux qu'un attribut de recherche (comme nous avons obtenu ci-dessus lorsque nous avons analysé le JSON).

C'est trompeur: n'oubliez pas que dans le JavaScript (et d'autres langages dynamiques) il n'y a pas de différence entre une carte et de recherche dans un champ de recherche. En fait, un champ de recherche est juste une carte de recherche.

Si vous voulez vraiment la peine de comparaison, le meilleur est à l'indice de référence - les repères dans le contexte où vous prévoyez d'utiliser les données.

Comme je viens de le taper, Felix Kling a déjà mis en place une assez succincte réponse de les comparer en termes d'utilisation de chaque, donc je ne vais pas aller plus avant.

21voto

Hibou57 Points 608

La vitesse de traitement peut ne pas être la seule question pertinente, cependant, que c'est la question, voici quelques chiffres d'un indice de référence: JSON vs XML: Quelques chiffres sur le niveau de verbosité. Pour la vitesse, dans ce cas-test simple, XML présente une 21% de frais généraux sur JSON.

Une remarque importante à propos de la verbosité, qui est comme le dit l'article, le plus commun de se plaindre: ce n'est pas pertinente dans la pratique (ni XML, ni les données JSON sont généralement traitées par des humains, mais par des machines), même si la question de la vitesse, il nécessite une certaine raisonnable plus de temps à compresser.

Aussi, dans ce cas-test, une grande quantité de données ont été traitées, et une application web standard ne transmet pas les données des morceaux de telles tailles, aussi grand que 90 MO, et la compression ne peut être bénéfique (pour les petites suffisamment de morceaux de données, un comprimé morceau sera plus grande que la non compressé morceau), donc pas applicable.

Encore, si aucune compression n'est impliqué, JSON, comme évidemment terser, pèse moins sur le canal de transmission, en particulier si elle est transmise par une connexion WebSocket, où l'absence de la classique HTTP généraux peuvent faire la différence à l'avantage de JSON, encore plus significatif.

Après la transmission, les données de consommation, et de ce nombre dans l'ensemble de la durée de traitement. Si grand ou suffisamment complexe pour les données doivent être transmises, l'absence d'un schéma vérifiée automatiquement par une validation XML parser exigent de plus en plus de vérifier sur les données JSON; ces contrôles doivent être réalisés en JavaScript, ce qui n'est pas connu pour être particulièrement rapide, et il peut donc présenter une surcharge supplémentaire de plus de XML dans de tels cas.

De toute façon, seuls les tests vous donne la réponse à votre cas d'utilisation (si la vitesse est vraiment la seule matière, et non la norme, ni la sécurité, ni l'intégrité...).

Mise à jour 1: la peine de mentionner, est EXI, le format XML binaire, qui offre une compression à un coût inférieur à l'aide de Gzip, et économiser du traitement nécessaire pour décompresser comprimé XML. EXI est au format XML, ce qui BFILS est en JSON. Avoir un bref aperçu ici, avec référence à l'efficience dans l'espace et le temps: EXI: La dernière binaire standard?.

Mise à jour 2: il existe également un XML binaire des rapports de performance, menée par le W3C, l'efficacité et la faible mémoire et du PROCESSEUR de l'empreinte, c'est aussi une question pour le XML domaine: Efficace d'Échange XML Évaluation.

14voto

Le XML (extensible Markup Language) est utilisé souvent XHR parce que c'est une norme de radiodiffusion de langue, ce qui peut être utilisé par n'importe quel langage de programmation, et pris en charge à la fois de serveur et côté client, donc c'est la solution la plus souple. Le XML peuvent être séparés pour plus de pièces pour un groupe particulier peut développer le cadre de ce programme, sans affecter les autres parties. Le format XML peut également être déterminé par le XML DTD ou un Schéma XML (XSL) et peut être testé.

Le JSON d'un format d'échange de données qui deviennent de plus en plus populaire que les applications JavaScript format possible. Bref c'est un objet de tableau de notation. JSON est très simple syntaxe peuvent donc être facilement appris. Et aussi la prise en charge de JavaScript parsing JSON avec l' eval de la fonction. D'autre part, la fonction eval a obtenu négatifs par exemple, le programme peut être très lent, car l'analyse de l'JSON et en raison de la sécurité de l'eval peut être très risqué. Cela signifie pas que le JSOn n'est pas bon, seulement il nous faut être plus prudent.

Mes suggestions que vous devriez utiliser JSON si vous créez des jeux amusants avec la lumière de données exxhange parce que vous n'avez pas vraiment de soins aboute les données-traitement, c'est très simple et rapide.

Le XML est le meilleur pour le plus grands sites web, par exemple des sites d'achats ou quelque chose comme ça. Le XML peut être plus sûr et clair, vous pouvez créer de base de données struct schéma et peuvent donc être facilement tester la correction et peuvent être facilement séparés des parties.

Je vous suggère de XML en raison de la vitesse et de la sécurité, mais json pour la légèreté des choses.

6voto

Khajan Pandey Points 11

La chose très importante sur JSON est de maintenir le transfert de données à l’aide d’encripted pour resion de sécurité. sans doute que JSON est beaucoup beaucoup plus vite puis XML. J’ai vu que quand xml prend 100 ms alors que json prend seulement 60 ms. les données JSON sont faciles à manupulate...

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X