Я хочу знать, что быстрее: XML и JSON? Когда использовать какой?
Я хочу знать, что быстрее: XML и JSON? Когда использовать какой?
Ответы:
Прежде чем ответить, когда использовать какой, немного фона:
редактировать: я должен отметить, что это сравнение действительно с точки зрения использования их в браузере с 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 (и других динамических языках) нет разницы между поиском по карте и поиском по полю. На самом деле поиск по полю - это просто поиск по карте.
Если вы хотите действительно стоящее сравнение, лучше всего сравнить его с эталонным тестом в контексте, в котором вы планируете использовать данные.
Как я уже писал, Феликс Клинг уже сформулировал довольно краткий ответ, сравнивая их с точки зрения того, когда использовать каждый из них, поэтому я не буду продолжать дальше.
Быстрее не является атрибутом JSON или XML или результатом, который даст сравнение между ними. Если таковые имеются, то это атрибут синтаксического анализатора или пропускной способности, с которой вы передаете данные.
Вот (начало) список преимуществ и недостатков JSON и XML:
Pro:
Против:
Простой синтаксис, поддерживается только несколько разных типов данных.
Нет поддержки для комментариев.
Pro:
Против:
Итак, в конце концов, вы должны решить, что вам нужно . Очевидно, что оба формата имеют свои законные варианты использования. Если вы в основном собираетесь использовать JavaScript, вам следует использовать JSON.
Пожалуйста, не стесняйтесь добавлять плюсы и минусы. Я не эксперт XML;)
id
атрибут быть уникальным в документе.
Однако скорость обработки может быть не единственным важным вопросом, так как в этом вопросе, вот некоторые цифры в тесте: 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-данными .
Стоит обратить внимание в этом контексте, так как издержки HTTP были подняты как проблема: IANA зарегистрировала кодировку EXI (эффективный двоичный XML, упомянутый выше), как кодировку контента для протокола HTTP (наряду с сжатием , дефляцией и gzip ) , Это означает, что EXI - это опция, которую браузеры могут ожидать от других HTTP-клиентов. См. Параметры протокола передачи гипертекста (iana.org) .
Я нашел эту статью на цифровом базаре действительно интересной. Цитирую их цитаты из норм:
О JSON профи:
Если все, что вы хотите передать - это атомарные значения или списки или хэши атомарных значений, JSON обладает многими преимуществами XML: он прост в использовании через Интернет, поддерживает широкий спектр приложений, легко писать программы для обработки JSON, у него мало дополнительных функций, он понятен человеку и достаточно понятен, его дизайн формален и лаконичен, документы JSON просты в создании, и он использует Unicode. ...
О плюсах XML:
XML замечательно справляется со всем богатством неструктурированных данных. Я совсем не беспокоюсь о будущем XML, даже если его радостно отмечают кадры дизайнеров веб-API.
И я не могу устоять перед тем, чтобы сказать "Я же тебе говорил!" в моем столе. Я с нетерпением жду возможности увидеть, что делают JSON, когда их просят разработать более богатые API. Когда они захотят обменяться менее структурированными данными, будут ли они включать их в JSON? Я вижу случайные упоминания языка схемы для JSON, будут ли другие языки следовать? ...
Я лично согласен с нормой. Я думаю, что большинство атак на XML совершаются веб-разработчиками типичных приложений, а не разработчиками интеграции. Но это мое мнение! ;)
{ "foo": 42 }
Какого типа этот объект? Затем, чтобы зафиксировать отсутствие типа, такие вещи , как это шоу вверх: { "__type": "Bar", "foo": 42 }
. В XML по типу контраста можно connotated названия элемента: <Bar><foo>42</foo></Bar>
. Только парни из lisp и javascript, такие как json;)
XML (расширяемый язык разметки) часто используется XHR, потому что это стандартный язык вещания, который может использоваться любым языком программирования и поддерживается как на стороне сервера, так и на стороне клиента, поэтому это наиболее гибкое решение. XML можно разделить на несколько частей, чтобы указанная группа могла разработать часть программы, не затрагивая другие части. Формат XML также может быть определен XML DTD или схемой XML (XSL) и может быть протестирован.
JSON - формат обмена данными, который становится все более популярным в качестве возможного формата приложений JavaScript. По сути это массив обозначений объектов. JSON имеет очень простой синтаксис, поэтому его легко выучить. А также JavaScript поддерживает синтаксический анализ JSON с помощью eval
функции. С другой стороны, eval
функция имеет негативы. Например, программа может очень медленно анализировать JSON и из-за безопасности eval
может быть очень рискованной. Это не значит, что JSON не очень хорош, просто мы должны быть более осторожными.
Я предлагаю вам использовать JSON для приложений с легким обменом данными, таких как игры. Поскольку вам не нужно заботиться об обработке данных, это очень просто и быстро.
XML лучше всего подходит для больших сайтов, например для магазинов или чего-то подобного. XML может быть более безопасным и понятным. Вы можете создать базовую структуру данных и схему, чтобы легко проверить исправление и легко разделить его на части.
Я предлагаю вам использовать XML из-за скорости и безопасности, но JSON для легких вещей.
Важной особенностью JSON является сохранение шифрования данных в целях безопасности. Нет сомнений, что JSON намного быстрее, чем XML. Я видел, как XML занимал 100 мс, а JSON - только 60 мс. Данные JSON легко манипулировать.