Сравнение JSON и XML

206

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

  • 60
    Быстрее где? Коробка передач? Обработка? Генерирование? У обоих нет ног, вы знаете. Вполне вероятно, что JSON в некотором роде «быстрее», поскольку у него меньше накладных расходов на разметку. С другой стороны, XML предоставляет XMLSchema для обеспечения типов, структуры ... так что валидность. Существует XSLT для преобразования XML практически в любой другой выходной формат ... Это зависит от того, что вам нужно .
  • 2
    Также проверьте другие ранее заданные вопросы: stackoverflow.com/search?q=json+vs+xml
Показать ещё 3 комментария
Теги:

6 ответов

192
Лучший ответ

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

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

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

При анализе это зависит от вашего синтаксического анализатора. Парсер, переводящий код (будь то JSON или XML) в структуру данных (например, карту), может извлечь выгоду из строгой природы XML (XML Schemas легко устранить структуру данных) - однако в 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 (и других динамических языках) нет разницы между поиском карты и полевым поиском. Фактически, поиск по полю - это просто поиск по карте.

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

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

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

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

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

JSON

Pro:

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

Con:

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

XML

Pro:

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

Con:

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

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

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

Поделиться
  • 16
    Другой Con для JSON и Pro для XML: JSON не поддерживает ссылку на объект (циклический или нет), XML поддерживает. XML делает это, заставляя атрибут id быть уникальным в документе.
  • 6
    @EarthEngine На самом деле Json.Net ( json.codeplex.com ) поддерживает ссылки на объекты: james.newtonking.com/projects/json/help/index.html?topic=html/… .
Показать ещё 6 комментариев
18

Скорость обработки может быть не единственным релевантным вопросом, однако, поскольку в этом вопросе приведены некоторые цифры в тесте: JSON vs. XML: некоторые жесткие числа о verbosity. Для скорости, в этом простом тесте, 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).

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

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

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

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

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

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

Поделиться
  • 0
    Я не провоцирую, но мне любопытно, как вы видите JSON как более тяжелую полезную нагрузку или медленнее в целом. GZip / Deflate может быть применен. Его синтаксис по своей сути делает его меньше в байтах. JSON также может определить свою схему как контракт и легко ее сериализовать.
  • 0
    JSON не нужно анализировать eval'd.
7

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

О JSON-профи:

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

О преимуществах XML:

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

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

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

Поделиться
7

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

Поделиться
  • 5
    Я согласен, JSON побеждает в битве за передачу данных, но не хватает разметки, проверки и расширения элементов. Вот почему Google сканирует sitemap.xml, а не sitemap.json
  • 1
    Карта сайта была определена до того, как json стал популярным, так что это не лучший пример. Карта сайта также рассматривается как сервер-сервер, где XML более популярен, чем JSON. (JSON действительно только потому, что популярен, потому что с ним легко работать в JavaScript.)
Показать ещё 1 комментарий

Ещё вопросы

Сообщество Overcoder
Наверх
Меню