что быстрее json или xml
JSON и XML. Что лучше?
Примечание: ниже перевод обзорной статьи «JSON vs XML», посвященной JSON и его сравнению с XML по ряду критериев. Публикуется в целях популяризации JSON среди читателей Хабрахабра.
JSON (англ. JavaScript Object Notation) — формат обмена данными, легко читаем людьми, легко обрабатывается и генерируется программами.
Что является правильным форматом ответа на XMLHttpRequest в AJAX-приложениях? Для большинства приложений, основанных на разметке, ответ будет простым — (X)HTML. Для информационно-ориентированных приложений выбор будет лежать между XML и JSON. До недавнего времени я не сильно задавался вопросом, что лучше использовать, XML или JSON. Я просто предполагал, что в каждом конкретном случае стоит выбирать наиболее подходящий формат, и все. Но недавно мне довелось проверить на практике этот подход. В этой заметке я опишу критерии, по которым проводил сравнение между XML и JSON, и собственные умозаключения.
Итак, критерии следующие.
Удобочитаемость кода
Peter-Paul Koch c QuirksMode.org рассматривает удобочитаемость кода как основной критерий своего анализа. По моему мнению, она является только второстепенной целью, но вы с легкостью согласитесь, что JSON гораздо проще воспринимается «на глаз», чем XML — стоит просто посмотреть на следующие примеры.
XML
JSON
Но я готов поспорить, что возможность отладки и исправления ошибок гораздо важнее, чем удобочитаемость.
Простота создания
Формат XML уже известен много лет (прим.: первая рабочая версия была заявлена в 1996 году, а спецификация — уже в 2000), поэтому существует некоторый набор программных интерфейсов (API) для привязки данных к XML на нескольких языках программирования. Например, на Java можно использовать JAXB и XmlBeans для создания XML-ответа. Ниже приведен пример с использованием JAXB.
С другой стороны, все интерфейсы для создания ответа на JSON появились относительно недавно. Тем не менее, на JSON.org опубликован довольно впечатляющий их список на различных языках. Ниже приведен пример создания ответа при помощи Json-lib.
Если рассматривать функционирование таких программных интерфейсов, то создания JSON не сильно отличается от сериализации Java beans в объекты. Однако, стоит отметить, что сейчас известно гораздо больше способов генерации XML, нежели JSON. Некоторые из этих программных интерфейсов для XML существуют уже много лет и по этой причине могут быть стабильнее при использовании для сложных приложений.
Другим аспектом, который стоит рассмотреть, будет количество ресурсов, которое используется для генерации ответа. Если при получении данных уже производятся «тяжелые» операции, то для серверной части не составит большого труда дополнительно их преобразовывать в XML для ответа. Если же создание XML будет являться самой ресурсоемкой операцией, то лучше использовать JSON.
Простота использования
На стороне клиентского приложения обработка JSON-данных как ответа на XMLHttpRequest чрезвычайно проста.
Теперь рассмотрим XML. Чтобы сделать нижеприведенный фрагмент кода прозрачнее, я убрал все проверки на ошибки.
В общем, если я буду выбирать между XML и JSON, я предпочту JSON из-за простоты реализации обработки на стороне клиента.
Расширяемость
Расширяемость помогает уменьшить число связей между поставщиком и получателем данных. В контексте AJAX-приложений, скрипт на стороне клиента должен быть достаточно инвариантным относительно совместимых изменениях в данных.
По общему убеждению, XML автоматически является расширяемым просто благодаря наличию буквы «X». Но это не является безусловным правилом (т.е. действующим по умолчанию). Расширяемость XML исходит из того принципа, что вы можете определить дополнительные узлы в вашем XML, а затем применять правило «ненужное пропустить» (т.е. если при обработке XML вам встретился незнакомый элемент или атрибут, просто пропустите его).
Вернемся к JSON. Я утверждаю, что расширить JSON-данные проще, чем XML. Это бесспорно требует меньше усилий. Рассмотрим добавление свойства middleName к JSON-ответу. Для того, чтобы получить к нему доступ, вам достаточно просто его вызвать.
Этот код не изменится, если вы добавите отчество в ваш ответ. Но что делать в случае обработки человека с или без отчества? С JSON это просто.
Моя позиция заключается в том, что, если иметь в виду возможную будущую расширяемость, и XML-, JSON-данные могут быть расширены. Но с JSON расширять данные проще, чем с XML. Вам просто требуется проверить, что требуемое свойство существует у объекта, и действовать в соответствии с результатом проверки.
Существует и другая возможность расширить JSON-данные, она заключается в использовании вызовов функций вместе с объявлениями данных прямо в ответе.
Отладка и исправление ошибок
Этот аспект касается как серверной части вашего приложения, так и клиентской. На сервере необходимо удостовериться в том, что данные правильно сформированы и корректны. На стороне клиента должно быть просто отлаживать ошибки в ответе.
В случае XML, относительно просто проверять, что данные, отправляемые клиенту, правильно сформированы и корректны. Вы можете использовать schema для ваших данных, и применить ее для проверки данных. С JSON эта задача становится ручной и требует проверку того, что в результате ответа у объекта присутствуют правильные атрибуты.
На стороне клиента в обоих случаях тяжело обнаружить ошибки. Для XML браузер будет просто не способен преобразовать его в responseXML. При небольших объемах JSON-данных можно воспользоваться расширением FireBug для отладки и исправления ошибок. Но при больших объемах данных становится несколько затруднительно соотнести сообщение об ошибке с конкретным местом в коде.
Безопасность
Dave Johnson в своей заметке JSON и Золотое руно высказывает мнение, что JSON может стать причиной проблем безопасности. Суть заметки сводится к тому, что если вы допускаете вставку вызовов функций наряду с данными в JSON-ответах и используете eval() для обработки ответа, то тем самым вы исполняете произвольный код, фактически, который уже может содержать угрозу безопасности.
Если ответ в примере выше будет выполнен, это вызовет отправку браузером пользовательских cookies на сторонний сайт. Но в данном случае, существует некоторое заблуждение в определении угрозы безопасности. Не следует доверять данным или коду, полученным из непроверенного источника. И во-вторых, мы не сможете использовать XMLHttpRequest для связи с доменами, отличными от домена-источника скрипта. Итак, только сами разработчики при создании приложения могут инициировать отправку cookies на сторонний сайт. Это довольно сомнительно, потому что они могут с тем же успехом разместить этот зловредный код где угодно в документе за пределами передаваемого от сервера ответа с данными. Возможно, я что-то упустил, но я не вижу смысла рассматривать JSON как небезопасный по сравнению с XML.
Мой выбор
В случае информационно-ориентированных приложений я предпочту использовать JSON, а не XML, в силу его простоты и легкости обработки данных на стороне клиента. XML может быть незаменимым на сервере, но с JSON определенно проще работать на клиенте.
Ссылки по теме
Спасибо всем, кто прочитал этот перевод. Ценю и уважаю ваше мнение и комментарии. Постараюсь учесть все пожелания и не остаться в долгу. Если у вас возникнут какие-либо предложения по тематике будущих переводов, не стесняйтесь, напишите их — я постараюсь сделать подборку или детальный обзор материалов по этим темам. Спасибо за внимание.
JSON и XML
Многие разработчики сравнивают JSON с XML при создании приложений, которые обмениваются данными между разными системами, особенно в Интернете. Это часто превращается в спор «JSON против XML», поскольку каждая сторона защищает свой предпочтительный формат.
Оказывается, JSON и XML имеют несколько разные цели, поэтому не всегда справедливо или уместно говорить, что одно «лучше» другого. Всё зависит от цели.
Давайте сперва рассмотрим пример документа на JSON и XML, содержащего одинаковые данные.
Пример на JSON
Вот некоторые данные, содержащиеся в JSON-документе.
Пример на XML
Те же данные, содержащиеся в XML-документе.
Обучаемость
XML основан на тегах, поэтому его несколько легче выучить тем, кто привык к языкам разметки, таким как HTML или ColdFusion. Однако подобное утверждение можно сказать и в пользу JSON для тех, кто знаком с программированием на JavaScript или Си. Любому, кто испытывает сложности в понимании синтаксиса XML или JSON, вряд ли будет удобно работать с любым языком программирования или языком разметки.
Тем не менее, с помощью JSON можно многому научиться — простота одна из сильных его сторон. XML, с другой стороны, содержит правила, касающиеся чувствительности к регистру, закрывающих тегов, атрибутов и др. Поэтому для большинства людей, вероятно, потребуется больше времени для изучения XML. Кроме того, как только вы отойдёте от простого обмена данными, XML окажется намного больше, чем кажется на первый взгляд.
Размер файла
XML требует закрывающих тегов (кроме самозакрывающихся элементов) и, скорее всего, приведёт к увеличению размера файла. Что может легко повлиять на время, требуемое для передачи файла (особенно если это большой файл и он передаётся по Интернету).
Также можно утверждать, что добавление закрывающих тегов добавляет и больше печатной работы разработчикам. Отчасти это правда, хотя большинство продвинутых разработчиков используют программное обеспечение, которое автоматически закрывает для них теги. Так что в подобных случаях это не является проблемой.
Метаданные
Одним из больших преимуществ XML по сравнению с JSON являются метаданные. В XML вы можете использовать атрибуты для хранения метаданных, а сами атрибуты могут размещаться внутри элемента и хранить больше информации об этом элементе.
Например, вы можете сделать что-то вроде этого.
Хотя есть возможность представить метаданные в JSON, например, превратив сущность в объект, а затем добавив метаданные в виде элементов в объекте, это не так изящно, как подход XML.
Читабельность
Браузеры, как правило, отображают XML так, чтобы человеку было легче его читать. Читатель может сразу увидеть иерархическую структуру, а также развернуть и свернуть любой элемент в дереве.
Производительность
Исследования часто показывают, что JSON быстрее и потребляет меньше ресурсов, чем XML. Например, вот это исследование — Comparison of JSON and XML Data Interchange Formats: A Case Study [PDF] из Университета штата Монтана.
Вот также интересная статья, в которой сравнивается производительность между XML, JSON, CSV и Protocol Buffers с помощью разных парсеров. JSON, похоже, имеет преимущество над XML в различных тестах производительности.
JSON и XML служат двум разным целям.
JSON — это формат обмена данными, его цель — облегчить обмен структурированными данными. Это достигается путём непосредственного представления объектов, массивов, чисел, строк и логических значений, которые часто присутствуют в исходном окружении и в месте назначения.
XML, с другой стороны, является языком разметки, его цель — разметка документа. Несмотря на то, что XML легко выучить для обмена данными, можно узнать намного больше, если вы хотите научиться использовать XML в качестве языка разметки. Например, вам необходимо узнать, как создать определение типа документа, как использовать XSLT для преобразования документов XML в другую форму и как запрашивать XML-документы с помощью XPath.
Заключение
Итак, JSON и XML оба подходят для обмена данными. Что вы будете используете, зависит от ситуации.
JSON, безусловно, имеет преимущество в большинстве случаев, но вы можете столкнуться с ситуациями, когда XML оказывается более подходящей технологией для работы.
Тем не менее, популярность JSON растёт, и он, безусловно, заменяет XML в качестве предпочтительного формата обмена данными по сети.
Кроме того, это не единственные форматы обмена данными, например, существуют и другие форматы, такие как Protocol Buffers. В зависимости от ситуации, CSV может оказаться даже лучшим форматом для работы.
JSON против XML
Разница между JSON и XML
JSON означает JavaScript Object Notation. Это открытый формат файлов, который используется для связи между браузером и сервером. Это независимый от языка формат данных. XML расшифровывается как расширяемый язык разметки. Это набор правил, которые помогают пользователям кодировать документы в удобочитаемом и машиночитаемом формате.
Давайте подробнее рассмотрим JSON vs XML:
«Общение жизненно важно». Это утверждение может быть процитировано с бесчисленными примерами. В техническом термине общение означает обмен данными и информацией. Органы, осуществляющие эту связь, могут быть системой или сервером. С тех пор, как люди организовали себя в сложное образование с прогрессом в технологиях, что также привело нас к созданию сетей, которые соответствуют нашим потребностям.
Когда мы просим компьютеры обрабатывать вещи, на практике они загружают эти данные. Эта загрузка данных имеет решающее значение, потому что процессор должен прочитать это в память. В процессе этого он хранит числа для чтения; Значение этих данных зависит от основы интерпретации.
Теперь начинается коммуникация или обмен данными. Настоящая проблема заключается здесь, когда предполагается, что связь происходит между бесчисленными системами и сетями, доступными по всему миру, и как происходит интерпретация. JSON против XML является наиболее распространенным форматом, предпочитаемым для обмена данными в Интернете.
Чтобы избежать этих проблем, должна быть общая терминология, которая актуальна и проще для понимания системами по всему миру. Это сводит на нет необходимость интерпретаций. Это очень важно, потому что необходимы некоторые стандарты и общая терминология, с которыми может согласиться каждый компьютер.
Сравнение лицом к лицу между JSON и XML (инфографика)
Ниже приведено 9 главных отличий между JSON и XML: 
Ключевые различия между JSON и XML
Оба являются популярным выбором на рынке; Давайте обсудим некоторые основные различия между JSON и XML:
Сравнительная таблица JSON и XML
Ниже приведено самое лучшее сравнение между JSON и XML:
