Сравнение JSON и XML [закрыто]


273

Я хочу знать, что быстрее: XML и JSON? Когда использовать какой?


60
Быстрее где? Передача инфекции? Обработка? Генерирование? У обоих нет ног, ты знаешь. Вполне вероятно, что JSON в некотором роде «быстрее», поскольку у него меньше накладных расходов на разметку. С другой стороны, XML предоставляет XMLSchema для обеспечения типов, структуры ... так что валидность. Существует XSLT для преобразования XML практически в любой другой выходной формат ... Это зависит от того, что вам нужно .
Феликс Клинг

2
Также проверьте другие ранее заданные вопросы: stackoverflow.com/search?q=json+vs+xml
Феликс Клинг

16
BLARG! Это то, что я действительно хотел знать, и был очень рад, что это было здесь, и ответы были ОТЛИЧНЫ. BAD ON YOU , как таковые модераторы: может быть , пришло время расширить ваш раздражает вовлеченность. Хорошо, что ты позволил ему ответить, по крайней мере!
Марк Геролиматос

Мне все равно, если этот пост очень поздно в игре, но я согласен. Если вопрос является дурацким, неуместным или противоречащим условиям обслуживания, возможно, (закрытая / бесполезная тема) не должна быть первой вещью, которая возникает при поиске. (кстати, это второй [дублированный] результат, который появляется) Я согласен, что, возможно, ответы должны быть точными и краткими, но если результат за результатом - это закрытая, оставшаяся без ответа тема, заполненная не по теме комментариями (что противоречит условиям использования), то это никому не помогает.
Исаак Корбетт

2
Хотя заданный вопрос неясен, это НЕ основанный на мнении вопрос.
сентября

Ответы:


221

Прежде чем ответить, когда использовать какой, немного фона:

редактировать: я должен отметить, что это сравнение действительно с точки зрения использования их в браузере с JavaScript. Это не так , как формат либо данные должен быть использован, и есть много хороших анализаторы , которые изменят детали , чтобы сделать то , что я говорю , не совсем справедлив.

JSON более компактен и (на мой взгляд) более читабелен - при передаче он может быть «быстрее» просто потому, что передается меньше данных.

В разборе это зависит от вашего парсера. Парсер, превращающий код (будь то JSON или XML) в структуру данных (например, карту), может извлечь выгоду из строгой природы XML ( схемы XML однозначно устраняют неоднозначность структуры данных), однако в JSON тип элемента (String / Number / Nested JSON Object) может быть выведен синтаксически, например:

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

Парсер не должен быть достаточно умным, чтобы понимать, что он 12представляет собой число (и Danielleявляется строкой, как и любой другой). Итак, в javascript мы можем сделать:

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

В XML мы должны сделать что-то вроде следующего:

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

(кроме того, это иллюстрирует тот факт, что XML более многословен; проблема передачи данных). Чтобы использовать эти данные, мы бы запустили их через анализатор, а затем мы должны вызвать что-то вроде:

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

На самом деле, хороший синтаксический анализатор вполне может напечатать ageдля вас (с другой стороны, вы вполне можете этого не хотеть). Когда мы обращаемся к этим данным, происходит следующее: вместо поиска атрибутов, как в примере JSON выше, мы выполняем поиск карты для ключа name. Это может быть более интуитивно понятно, чтобы сформировать XML следующим образом:

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

Но для доступа к нашим данным нам все же придется искать карту:

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

РЕДАКТИРОВАТЬ: Оригинал:

В большинстве языков программирования (не во всех отношениях) поиск карты, такой как этот, будет более дорогостоящим, чем поиск атрибутов (как мы получили выше, когда анализировали JSON).

Это вводит в заблуждение: помните, что в JavaScript (и других динамических языках) нет разницы между поиском по карте и поиском по полю. На самом деле поиск по полю - это просто поиск по карте.

Если вы хотите действительно стоящее сравнение, лучше всего сравнить его с эталонным тестом в контексте, в котором вы планируете использовать данные.

Как я уже писал, Феликс Клинг уже сформулировал довольно краткий ответ, сравнивая их с точки зрения того, когда использовать каждый из них, поэтому я не буду продолжать дальше.


Просто педантичное примечание ... Поиск поля JavaScript не обязательно поиск карты. Это зависит от объекта и рассматриваемой области. Небольшие объекты (особенно те, у которых свойства не были прикреплены после построения) часто используют оптимизированные «быстрые типы» со встроенными кэшами в современных движках JS и используют более медленные пакеты свойств (поиск карт) для объектов с большим количеством свойств или случаи, когда структура объектов часто меняется.
Брэндон Паддок

2
Я считаю, что JSON легче анализировать людям, но XML легче анализировать компьютерам.
Jus12

5
Не верно, например, в PHP, JSON использует json.so без зависимостей на 78k, XML с другой стороны, требует xml.so или xmlreader.so на 54k / 32k, но также требует libxml2.so, который 1.4megs , Чем больше кода, тем дольше обрабатывается и используется больше памяти. Не говоря уже о том, что XML, из-за его узловой / древовидной структуры, имеет циклические ссылки, что может быть проблемой для любого языка, который не имеет слабых ссылок. Я обнаружил на нескольких языках, что синтаксический анализатор XML на FAR больше (занимает больше памяти и использует больше памяти), чем любой из их аналогичных анализаторов JSON.
Рахли

Почему вы смешиваете проблему строгого статуса JS с этим несвязанным сравнением? Ссылаясь на двойные или тройные знаки равенства.
atilkan

1
@atilkan, потому что многие парсеры интерпретируют числовые строки как числа или хранят числа как числовые строки.
мазунки

244

Быстрее не является атрибутом JSON или XML или результатом, который даст сравнение между ними. Если таковые имеются, то это атрибут синтаксического анализатора или пропускной способности, с которой вы передаете данные.

Вот (начало) список преимуществ и недостатков JSON и XML:


JSON

Pro:

  • Простой синтаксис, который приводит к меньшим затратам на «разметку» по сравнению с XML.
  • Простой в использовании с JavaScript, так как разметка является подмножеством буквенной нотации объекта JS и имеет те же основные типы данных, что и JavaScript.
  • Схема JSON для описания, типа данных и проверки структуры
  • JsonPath для извлечения информации в глубоко вложенных структурах

Против:

  • Простой синтаксис, поддерживается только несколько разных типов данных.

  • Нет поддержки для комментариев.


XML

Pro:

  • Обобщенная разметка; можно создавать «диалекты» для любых целей
  • Схема XML для типа данных, проверка структуры. Позволяет также создавать новые типы данных
  • XSLT для преобразования в различные выходные форматы
  • XPath / XQuery для извлечения информации в глубоко вложенных структурах
  • встроенная поддержка пространств имен

Против:

  • Относительно многословно по сравнению с JSON (приводит к большему количеству данных для того же объема информации).

Итак, в конце концов, вы должны решить, что вам нужно . Очевидно, что оба формата имеют свои законные варианты использования. Если вы в основном собираетесь использовать JavaScript, вам следует использовать JSON.

Пожалуйста, не стесняйтесь добавлять плюсы и минусы. Я не эксперт XML;)


20
Другой Con для JSON и Pro для XML: JSON не поддерживает ссылку на объект (циклический или нет), XML поддерживает. XML делает это, заставляя idатрибут быть уникальным в документе.
Земля Двигатель

7
@EarthEngine На самом деле Json.Net ( json.codeplex.com ) поддерживает ссылки на объекты: james.newtonking.com/projects/json/help/index.html?topic=html/… .
Дмитрий Лобанов

22
@DmitryLobanov: Они просто добавляют некоторые дополнительные ограничения в стандарт JSON, но другие инструменты JSON не распознают его. Так что это не "родной" для JSON. Однако для XML ограничение написано в стандарте, поэтому оно является нативным.
Земля Двигатель

1
Как насчет JSON Schema? en.wikipedia.org/wiki/JSON#JSON_Schema
Джон Доу

5
У JSON есть встроенные массивы, а также «нулевое» значение. В то время как в XML вам нужно какое-то соглашение для ваших анализаторов схемы. Есть также XSLT-подобные конверсионные проекты для JSON (например, github.com/emlynoregan/bOTLjs )
Василий Боровяк

22

Однако скорость обработки может быть не единственным важным вопросом, так как в этом вопросе, вот некоторые цифры в тесте: JSON против XML: некоторые точные цифры о многословности . Для скорости в этом простом тесте XML представляет 21% накладных расходов по сравнению с JSON.

Важное замечание о многословности, которое, как говорится в статье, является наиболее распространенной жалобой: на практике это не так уж важно (ни данные XML, ни JSON обычно обрабатываются людьми, но машинами), даже если речь идет о Скорость, это требует некоторого разумного больше времени для сжатия.

Кроме того, в этом тесте был обработан большой объем данных, и типичное веб-приложение не будет передавать фрагменты данных таких размеров, как 90 МБ, и сжатие может быть не выгодным (для достаточно маленьких фрагментов данных - сжатый блок). будет больше, чем несжатый кусок), поэтому не применяется.

Тем не менее, если сжатие не задействовано, JSON, как, очевидно, более кратко, будет меньше весить по каналу передачи, особенно если он передается через соединение WebSocket, где отсутствие классических HTTP-издержек может изменить ситуацию к преимуществу JSON, даже больше существенный.

После передачи данные должны быть использованы, и это учитывается в общем времени обработки. Если необходимо передать большие или достаточно сложные данные, отсутствие схемы, автоматически проверяемой проверяющим анализатором XML, может потребовать дополнительной проверки данных JSON; эти проверки должны были бы выполняться в JavaScript, который, как известно, не особенно быстр, и поэтому в таких случаях он может представлять дополнительную нагрузку на XML.

В любом случае, только тестирование даст ответ для вашего конкретного случая использования (если скорость действительно является единственным вопросом, а не стандартом, безопасностью или целостностью…).

Обновление 1: стоит упомянуть EXI, двоичный формат XML, который предлагает сжатие с меньшими затратами, чем использование Gzip, и сохраняет обработку, необходимую для распаковки сжатого XML. EXI для XML, что BSON для JSON. Краткий обзор здесь, с некоторыми ссылками на эффективность как в пространстве, так и во времени: EXI: Последний двоичный стандарт? ,

Обновление 2: существуют также отчеты о производительности в двоичном XML-формате, составленные W3C, поскольку эффективность и низкий объем памяти и занимаемая площадь процессора также важны для области XML: Эффективная оценка обмена XML-данными .

Обновление 2015-03-01

Стоит обратить внимание в этом контексте, так как издержки HTTP были подняты как проблема: IANA зарегистрировала кодировку EXI (эффективный двоичный XML, упомянутый выше), как кодировку контента для протокола HTTP (наряду с сжатием , дефляцией и gzip ) , Это означает, что EXI - это опция, которую браузеры могут ожидать от других HTTP-клиентов. См. Параметры протокола передачи гипертекста (iana.org) .


«Для быстродействия в этом простом бенчмарке XML представляет собой накладные расходы в 21% по сравнению с JSON» - существует огромная разница в разборе JSON в зависимости от используемого используемого синтаксического анализатора. Почти бессмысленно цитировать любой конкретный парсер. То же самое для XML.
Джеффри Блатман

17

Я нашел эту статью на цифровом базаре действительно интересной. Цитирую их цитаты из норм:

О JSON профи:

Если все, что вы хотите передать - это атомарные значения или списки или хэши атомарных значений, JSON обладает многими преимуществами XML: он прост в использовании через Интернет, поддерживает широкий спектр приложений, легко писать программы для обработки JSON, у него мало дополнительных функций, он понятен человеку и достаточно понятен, его дизайн формален и лаконичен, документы JSON просты в создании, и он использует Unicode. ...

О плюсах XML:

XML замечательно справляется со всем богатством неструктурированных данных. Я совсем не беспокоюсь о будущем XML, даже если его радостно отмечают кадры дизайнеров веб-API.

И я не могу устоять перед тем, чтобы сказать "Я же тебе говорил!" в моем столе. Я с нетерпением жду возможности увидеть, что делают JSON, когда их просят разработать более богатые API. Когда они захотят обменяться менее структурированными данными, будут ли они включать их в JSON? Я вижу случайные упоминания языка схемы для JSON, будут ли другие языки следовать? ...

Я лично согласен с нормой. Я думаю, что большинство атак на XML совершаются веб-разработчиками типичных приложений, а не разработчиками интеграции. Но это мое мнение! ;)


Хорошо сказано! Если 80% активных разработчиков являются детишками на JavaScript, 80% высказывают свое мнение о том, что JSON «лучше». Но любой, кто использует типизированные языки, просто немного удивлен JSON. { "foo": 42 }Какого типа этот объект? Затем, чтобы зафиксировать отсутствие типа, такие вещи , как это шоу вверх: { "__type": "Bar", "foo": 42 }. В XML по типу контраста можно connotated названия элемента: <Bar><foo>42</foo></Bar>. Только парни из lisp и javascript, такие как json;)
BitTickler,

15

XML (расширяемый язык разметки) часто используется XHR, потому что это стандартный язык вещания, который может использоваться любым языком программирования и поддерживается как на стороне сервера, так и на стороне клиента, поэтому это наиболее гибкое решение. XML можно разделить на несколько частей, чтобы указанная группа могла разработать часть программы, не затрагивая другие части. Формат XML также может быть определен XML DTD или схемой XML (XSL) и может быть протестирован.

JSON - формат обмена данными, который становится все более популярным в качестве возможного формата приложений JavaScript. По сути это массив обозначений объектов. JSON имеет очень простой синтаксис, поэтому его легко выучить. А также JavaScript поддерживает синтаксический анализ JSON с помощью evalфункции. С другой стороны, evalфункция имеет негативы. Например, программа может очень медленно анализировать JSON и из-за безопасности evalможет быть очень рискованной. Это не значит, что JSON не очень хорош, просто мы должны быть более осторожными.

Я предлагаю вам использовать JSON для приложений с легким обменом данными, таких как игры. Поскольку вам не нужно заботиться об обработке данных, это очень просто и быстро.

XML лучше всего подходит для больших сайтов, например для магазинов или чего-то подобного. XML может быть более безопасным и понятным. Вы можете создать базовую структуру данных и схему, чтобы легко проверить исправление и легко разделить его на части.

Я предлагаю вам использовать XML из-за скорости и безопасности, но JSON для легких вещей.


Я не провоцирую, но мне любопытно, как вы видите JSON как более тяжелую полезную нагрузку или медленнее в целом. GZip / Deflate может быть применен. Синтаксис по сути делает его меньше в байтах. JSON также может определить свою схему как контракт и легко ее сериализовать.
Энтони Мейсон

JSON не нужно анализировать eval'd.
Yay295

7

Важной особенностью JSON является сохранение шифрования данных в целях безопасности. Нет сомнений, что JSON намного быстрее, чем XML. Я видел, как XML занимал 100 мс, а JSON - только 60 мс. Данные JSON легко манипулировать.


5
Я согласен, JSON побеждает в битве за передачу данных, но ему не хватает разметки, проверки и расширения элементов. Вот почему Google сканирует sitemap.xml, а не sitemap.json
Четабахана,

1
Карта сайта была определена до того, как json стал популярным, так что это не лучший пример. Карта сайта также рассматривается как сервер-сервер, где XML более популярен, чем JSON. (JSON на самом деле только потому, что популярен, потому что с ним легко работать в JavaScript.)
Мэтью Уайтед

но Google AMP использует json, а не xml
Ашраф
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.