Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 96
Подразумевать, что теги в XML-документе расположены в определённом порядке — одна из самых распространённых ошибок при работе с XML: http://forums.worsethanfailure.com/forums/thread/126704.aspx
Это не только ломает расширяемость, но и ставит под угрозу возможность редактирования XML-файлов вручную: ведь мало кто способен выучить строгий порядок следования 20-и тегов. К тому же, это противоречит спецификации.
> Итак, только сами разработчики при создании приложения могут инициировать отправку cookies на сторонний сайт.
Вы упустили возможность такой атаки: представьте себе, что вы загружаете данные гостевой книги через JSON. Серверный скрипт неправильно обрабатывает данные escape-последовательностями, но не все, а только некоторые спецсимволы, и сообщение предыдущего пользователя будет выполнено через eval().
Это не только ломает расширяемость, но и ставит под угрозу возможность редактирования XML-файлов вручную: ведь мало кто способен выучить строгий порядок следования 20-и тегов. К тому же, это противоречит спецификации.
> Итак, только сами разработчики при создании приложения могут инициировать отправку cookies на сторонний сайт.
Вы упустили возможность такой атаки: представьте себе, что вы загружаете данные гостевой книги через JSON. Серверный скрипт неправильно обрабатывает данные escape-последовательностями, но не все, а только некоторые спецсимволы, и сообщение предыдущего пользователя будет выполнено через eval().
+1 с замечанием по безопасности согласен. Но, по сути, это проблемы разработчика, который "прошляпил" обработку escape-sequence, а не дыра в безопасности JSON
Да, но если это рассматривать в свете сравнения XML и JSON, то у XML нет такой "фичи".
а это точно преимущество?
Ну это как посмотреть. С одной стороны, с XML мы не можем "автомагически" выполнять JavaScript на клиенте. С другой, нехорошо смешивать данные и код, даже если всё 100% безопасно. Хотя в принципе, что мешает добавить в XML-документ элемент <evalthis> и исполнять на клиенте, но только при помощи явного eval()?
вот-вот :) Ничего не мешает добавить в XML.
Но. При хороших условиях нужно иметь некий автоматический разборщик XML, который превращает наши XML данные, например, в массивы или классы, с которыми продолжаем работать.
При плохих условиях - мы разбираем XML ручками под себя.
Перворе решение - практичное и громоздкое, второе чревато аццкой поддержкой.
Ну и JSON, который, грубо говоря, решает вышенаписанные проблемы XML на 70%.
Но. При хороших условиях нужно иметь некий автоматический разборщик XML, который превращает наши XML данные, например, в массивы или классы, с которыми продолжаем работать.
При плохих условиях - мы разбираем XML ручками под себя.
Перворе решение - практичное и громоздкое, второе чревато аццкой поддержкой.
Ну и JSON, который, грубо говоря, решает вышенаписанные проблемы XML на 70%.
Тут снова вопрос не в том, что лучше, а что удобнее в данной ситуации. XML — общий язык, не привязан к JavaScript. Его можно использовать для передачи данных в AJAX, можно — для передачи мгновенных сообщений (Jabber), а можно в формате XML хранить конфиг своей умной микроволновки. В этом его сила — в возможности обмена информацией между разными программами и поддержке во многих платформах.
JSON же удобен, когда данные специально генерируются для одного клиента на JavaScript.
JSON же удобен, когда данные специально генерируются для одного клиента на JavaScript.
речь же шла о веб-программировании, или я что-то недопонял?
то есть, если рассматривать исползование в общем XML vs JSON, то безусловно разделяю мнение выше
то есть, если рассматривать исползование в общем XML vs JSON, то безусловно разделяю мнение выше
Нет, всё верно. Если брать только веб-программирование — то на данном этапе развития встроенных возможностей JavaScript, JSON без вопросов удобнее. Но как только сюда подмешать какую-то необычную базу данных на сервере, или другое внешнее условие — то XML может выйти удобнее. Хотя сходу, наверное, примеров не придумаю.
Что мешает парсить JSON?
ИМХО, ресурсоёмкость намного ниже.
ИМХО, ресурсоёмкость намного ниже.
json - родной формат не только для яваскрипта, но и для того же питона, например
> Подразумевать, что теги в XML-документе расположены в определённом порядке — одна из самых распространённых ошибок при работе с XML
В целом да, но иногда бывает полезно жестко задать порядок следования элементов с помощью XSD — например, для обработки XMLя SAXом.
В целом да, но иногда бывает полезно жестко задать порядок следования элементов с помощью XSD — например, для обработки XMLя SAXом.
А как же насчет YAML? Который намного лаконичнее, понятнее, удобоваримее чем XML и тот же JSON?
Статью надо было назвать "Почему XML хуже JSON?" ;-)
Быстрее найти ошибку в xml, чем в js.
Можно полдня целый день долбаться из-за одной пропущенной точки запятой.
Когда я увижу обработчики обработчики на стороне сервера, то я возможно и перейду на него.
И основной вопрос, зачем посторонним людям его легко читать? Те, кто это приложение разрабатывают, должны сами хорошо разбираться в своем коде, зачем им делать удобства для других?
Плодить новых кулхацкеров?
Можно полдня целый день долбаться из-за одной пропущенной точки запятой.
Когда я увижу обработчики обработчики на стороне сервера, то я возможно и перейду на него.
И основной вопрос, зачем посторонним людям его легко читать? Те, кто это приложение разрабатывают, должны сами хорошо разбираться в своем коде, зачем им делать удобства для других?
Плодить новых кулхацкеров?
Веб — открытая среда. Те, кто рассчитывают на то, что их код не прочитают, поступают неосмотрительно :)
Есть библиотеки для автоматической генерации JSON, а в php это вроде уже на уровне ядра начиная с 5й версии. А посторонним людям реально не стоит знать.....а вот те кто будут работать с этим кодом(я за опенсорс) те уже не посторонние
В PHP с версии 5.2 автоматически включается модуль JSON. Кстати, в том же PHP есть довольно удобный extension SimpleXML.
Всё так, но, например, на мастерхосте поддержки JSON нет... Наверно, и некоторые другие провайдеры этим же страдают.
comparison of php json libraries
http://gggeek.altervista.org/sw/article_…
Ознакомьтесь с производительностью конкурентов. Я, конечно, поставил временную заглушку, но отсутствие поддержки json у такого крупного хостера настораживает.
http://gggeek.altervista.org/sw/article_…
Ознакомьтесь с производительностью конкурентов. Я, конечно, поставил временную заглушку, но отсутствие поддержки json у такого крупного хостера настораживает.
да я не против этого, мне просто не хочется в пустую тратить время для удобства посторонних.
А вы на каком языке (языках) программируете? Зайдите на http://json.org/ там есть список языков, для которых уже есть библиотеки и это только "официальные".
В рамках примера:
XML[130 байт]:
Subbu
Allamaraju
JSON[71 байт]:
({
"firstName" : "Subbu",
"lastName" : "Allamaraju"
});
XML[130 байт]:
Subbu
Allamaraju
JSON[71 байт]:
({
"firstName" : "Subbu",
"lastName" : "Allamaraju"
});
Кстати, отличная статья, вроде одна из самых интересных за последнее время.
Автор забыл упомянуть (или не захотел), что JSON поддерживается ActionScript в Flash.
Автор забыл упомянуть (или не захотел), что JSON поддерживается ActionScript в Flash.
JSON удобнее, это неоспоримо. Но безопасность… поэтому он не идеален.
Четко сквозит попытка навязать свое мнение со стороны автора.
Момент с расширяемостью несколько озадачил. То, что в XML есть возможность выбрать элемент по номеру, а в JSON нет - это не значит, что XML хуже расширяется. Просто у XML есть дополнительная фича.
Я бы расписал сравнительные преимущества AJAX+XML так:
- Простота отладки
- Безопасность
- Устоявшийся стандарт, инвариантность.
Сравнительные преимущества JSON:
- В разы меньший объем данных (экономия трафика, плюс к скорости работы сайта)
- Меньшая загрузка процессора и клиента, и сервера
- Почти неограниченные возможности расширения (т.к. можно выполнить ф-цию)
Момент с расширяемостью несколько озадачил. То, что в XML есть возможность выбрать элемент по номеру, а в JSON нет - это не значит, что XML хуже расширяется. Просто у XML есть дополнительная фича.
Я бы расписал сравнительные преимущества AJAX+XML так:
- Простота отладки
- Безопасность
- Устоявшийся стандарт, инвариантность.
Сравнительные преимущества JSON:
- В разы меньший объем данных (экономия трафика, плюс к скорости работы сайта)
- Меньшая загрузка процессора и клиента, и сервера
- Почти неограниченные возможности расширения (т.к. можно выполнить ф-цию)
Как мне кажется, фраза «AJAX+XML» — тавтология. Вы, по-сути, написали: «Advanced Javascript and XML + XML». Куда уж второй-то XML?
Набор полезностей для заинтересованных:
1. конвертор php-массива в json-строку
1. конвертор php-массива в json-строку
function php2js($a) {2. запрос и обработка результата с использованием prototype
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).'}';
}}
new Ajax.Request(url,{3. замечание к примеру в тексте
method: 'get',
onSuccess: function(transport) {
var arr=transport.responseText.evalJSON();
//blablabla with arr
}});
var person=eval("("+xhr.responseText+")");
а можно поподробнее с третьим пунктом? мы предполагаем, что
xhr.responseText изначально не является правильной структурой что ли?Нужны скобки, выделенные жирным. Тут как раз и предполагается, что структура правильная. А prototype в примере 2 валидит структуру, тут можно не беспокоится о безопасности.
a php_json не рулит?!
Рулит, но не у любого хостера есть.
JSON и XML очень разные форматы и подходят для совершенно различных вещей. Думаю, выбирать среди них лучший то же, что выбирать между малолитражкой и пикапом.
XML прекрасно подходит для обработки данных на стороне сервера, а JSON —для передачи небольших порций данных клиенту, тот же ajax. Хотя если требуется передать от клиента серверу, лучше использовать XML да API на XML-RCP.
ИМХО, эти каждый из этих форматов имеет свои плюсы, которыми просто надо уметь пользоваться.
XML прекрасно подходит для обработки данных на стороне сервера, а JSON —для передачи небольших порций данных клиенту, тот же ajax. Хотя если требуется передать от клиента серверу, лучше использовать XML да API на XML-RCP.
ИМХО, эти каждый из этих форматов имеет свои плюсы, которыми просто надо уметь пользоваться.
Судя по предложенным именам Allamaraju и тп.. автор статьи - ИНДУС.
Вы таки проницательны: «I am an alumni of Indian Institute of Technology, Kharagpur (India) for my Masters and Ph.D., both in Electrical Engineering, and J.N.T.U., Kakinada (India) for my B.Tech., also in Electrical Engineering». Для вас «индус» в IT — диагноз?
Peter-Paul Kock -> Peter-Paul Koch
Не очень нравится фраза «Для большинства приложений, основанных на разметке, ответ будет простым — HTML». Думаю, врезать голую разметку HTML — каменный век. XHTML и DOM же есть.
Кстати, http://quirksmode.org/ не работает, верный адрес — http://www.quirksmode.org/.
Кстати, http://quirksmode.org/ не работает, верный адрес — http://www.quirksmode.org/.
спасибо
есть довольно много случаев, когда удобно получать HTML разметку динамически, зря вы так. Все навороты с генерацией иногда совершенно не нужны и лишь усложняют код.
DOM универсальнее / современнее. Экономия на сложности кода и времени разработки — вопрос не такой однозначный, зависящий от того, кто и что пишет.
DOM не универсальнее ни разу, когда надо к примеру подгрузить в область страницы html блок. Надо выбирать средства более удобные для конкретной задачи, а не более "современные", по-моему.
Если «область страницы» — это XHTML, то лучше DOM. Если речь о том, что было и будет text/html, а времени на ревизию кода нет и не будет, то, конечно, DOM ни при чем. Спорить тут не о чем.
по-моему я не понял ваш коммент, изначально.
я за
$("div#myid").html("text");
и против document.createElement("span");
для меня первое - это "врезание голой разметки", второе - это DOM в изначальном понимании этого слова.
Мы правильно друг друга поняли?
я за
$("div#myid").html("text");
и против document.createElement("span");
для меня первое - это "врезание голой разметки", второе - это DOM в изначальном понимании этого слова.
Мы правильно друг друга поняли?
Да, DOM он и есть DOM. Я ни за первое, ни за второе. Я за document.createElementNS("http://www.w3.org/1999/xhtml", "span");
;-)
;-)
Почему все забыли о том, что JSON с кодировкой windows-1251 в IE не работает, критическая ошибка!
Это очень важно, если проект весь в кодировке windows-1251, то речь о JSON не идет, только XML!
Пример из моей практики:
Необходимо было передавать данные, используя AJAX, данные представляли собой XML из 1000 позиций, в каждой позиции - информация о продукте: название, принадлежность категории, урл и описание.
Все отлично работает, но появилась необходимость увеличить массив данных до 5000 позиций. И тут браузер стал нереально притормаживать при распарски XML в DOM, замирал на несколько секунд, причем это было заметно.
Решение на тот момент - JSON.
Могу сказать, лично для меня проще генерировать XML (меньше вероятность допустить ошибку и больше найти ее :) и читается лучше, чем JSON.
Причем XML-данные это не одно и то же, что структура данных JavaScript.
Если использовать JSON, то на протокол обмена можно забить.
В некоторых проектах протокол очень важен!
Это очень важно, если проект весь в кодировке windows-1251, то речь о JSON не идет, только XML!
Пример из моей практики:
Необходимо было передавать данные, используя AJAX, данные представляли собой XML из 1000 позиций, в каждой позиции - информация о продукте: название, принадлежность категории, урл и описание.
Все отлично работает, но появилась необходимость увеличить массив данных до 5000 позиций. И тут браузер стал нереально притормаживать при распарски XML в DOM, замирал на несколько секунд, причем это было заметно.
Решение на тот момент - JSON.
Могу сказать, лично для меня проще генерировать XML (меньше вероятность допустить ошибку и больше найти ее :) и читается лучше, чем JSON.
Причем XML-данные это не одно и то же, что структура данных JavaScript.
Если использовать JSON, то на протокол обмена можно забить.
В некоторых проектах протокол очень важен!
не знаю насчет поддержки windows-1251 в IE, но у меня есть работающий проект, в котором русские данные гоняются через JS-массив (имхо, «не совсем» JSON). Никаких проблем с кодировками на клиенте в IE 5.5,6,7 не наблюдаю.
попробуй AJAJ погонять в IE c windows-1251
Все на utf.
не всегда есть возможность использовать unicode в проектах,
поэтому надо быть подкованным :)
поэтому надо быть подкованным :)
все прекрасно работает. единственное НО - ослик хочет чтоб кодировка была явно указано в ответе сервера. при этом он не знает про "СП1251", ему требуется именно "Виндоуз-1251"
У меня с сафари на маке была подобная проблема. В ответе сервера надо было указать кодировку:
header("Content-type: application/x-javascript;charset=utf-8");
header("Content-type: application/x-javascript;charset=utf-8");
не работает, если сервер отвечает в windows-1251
ответ сервера или кодировка в заголовке?
это таки несколько не связанные друг с другом вещи получаются :)
это таки несколько не связанные друг с другом вещи получаются :)
работает, готовить надо уметь :)
можно ссылку на работающий JSON в cp1251 в IE
надо зарегистрироваться на mail.ru и вот тут:
http://blogs.mail.ru/cgi-bin/journal/jed…
создать новую группу друзей (слева в желтом блоке)
http://blogs.mail.ru/cgi-bin/journal/jed…
создать новую группу друзей (слева в желтом блоке)
5000 — что-то запредельное. Может, стоит пять раз подгрузить по мере пролистывания пользователем новый блок.)
а разве XMLHttpRequest в основе своей не предполагает использование только utf?
лично для меня проще генерировать XML (меньше вероятность допустить ошибку и больше найти ее :) и читается лучше, чем JSON.
для генерации JSON существует масса уже готовых сериализаторов. пользуйте из и не ошибетесь ;)
а на счет "читается лучше", так тут скорее от привычки и структуры данных зависит. иногда JSON нагляднее из-за компактности, иногда XML (особенно если смотреть с фолдингом)...
JSON - несомненно хорошая вещь для передачи простых конструкций. Но когда я начал им пользоваться, первым делом определил для себя правило - JSON ответ всегда содержит код возврата, текст ошибки, и данные. Чуть SOAP на json'е не написал :)
Беда JSON при работе с PHP - есть только одна пристойная реализация, и, как ни печально, она работает только с utf-8. Почему одна - посмотрите на графики на comparison of php json libraries - php json очень сильно - на два порядка - превосходит по скорости другие реализации, и пользоваться ими просто страшно.
Беда JSON при работе с PHP - есть только одна пристойная реализация, и, как ни печально, она работает только с utf-8. Почему одна - посмотрите на графики на comparison of php json libraries - php json очень сильно - на два порядка - превосходит по скорости другие реализации, и пользоваться ими просто страшно.
А еще JSON легко получать из анонимных объектов в C#
… Используя обычный eval()...
Простите, а разве JSON.parse() не более «светлый путь»?
Если я неправ, то расскажите, пожалуйста, в чем плюсы метода из поста (я не особо компетентен в этом вопросе, JS использую только в QML).
UPD посту 6 лет почти, вот это поворот)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
JSON и XML. Что лучше?