Комментарии 21
Может я тут и не в тему со своими проблемами, но никто не в курсе какой JSON парсер использует PHP и какие есть альтернативы? Потому что использовать потоковый парсер было бы ооооочень сладко.
Исходя из цитаты документации «The decoding is handled by a parser based on the JSON_checker by Douglas Crockford.» а также отсетствия внешних зависимостей для этого модуля, предполагаю, что там своя внутренняя реализация и она простая (в памяти и т.п., хоть и быстрая). Можно написать свой модуль, конечно. Другие реализации, что есть — это только РНР-шные, они тоже не умеют потоково работать
Лично я предпочитаю не использовать родной пхп json кодировщик (парсер пока не использовал, только на кодирование) — он иногда из юникода делает кашу.
То есть, куски текста-каши могут чередоваться с нормальными совершенно случайным образом, зависящим только от порядкового номера обращения к скрипту — в один раз будет бить одни куски, в другой — другие, в третий — третьи, и.т.д., совершенно случайно.
Может это баг, может это мемлики, или еще что-то. Но я им не пользуюсь — использую sprintf(), к тому же он работает намного быстрее.
То есть, куски текста-каши могут чередоваться с нормальными совершенно случайным образом, зависящим только от порядкового номера обращения к скрипту — в один раз будет бить одни куски, в другой — другие, в третий — третьи, и.т.д., совершенно случайно.
Может это баг, может это мемлики, или еще что-то. Но я им не пользуюсь — использую sprintf(), к тому же он работает намного быстрее.
Немного оффтоп, конечно, но сейчас я вижу какое-то переизобретенение XML, причем по тому же самому пути.
На мой взгляд, JSON хорош для небольших простых данных, передачи их в браузер (как нативный формат JS). Но на больших объемах мы получим все проблемы, характерные для XML, только в еще худшем варианте — т.к. там система изначально проектировалась под сложные «лохматые» данные. В том же XML есть очень удобный инструмент для выборок XPath — вероятно, очень скоро появится JPath :)
Вопрос риторический: нужно ли нам закладываться на более простой формат для сложных данных? Не получим ли больше проблем, чем упрощений? Ведь для xml все эти инструменты уже существуют и созданы они не спроста.
На мой взгляд, JSON хорош для небольших простых данных, передачи их в браузер (как нативный формат JS). Но на больших объемах мы получим все проблемы, характерные для XML, только в еще худшем варианте — т.к. там система изначально проектировалась под сложные «лохматые» данные. В том же XML есть очень удобный инструмент для выборок XPath — вероятно, очень скоро появится JPath :)
Вопрос риторический: нужно ли нам закладываться на более простой формат для сложных данных? Не получим ли больше проблем, чем упрощений? Ведь для xml все эти инструменты уже существуют и созданы они не спроста.
xml для энтерпрайз решений, json для веб.
Понимаете, часто ведь не надо всей мощи (и избыточности) XML, при этом и сложных структур не надо — а вот данных может быть много. А так как для обычно веб-проектов JSON он нативный для принимающей стороны (браузера), а теперь часто и для сервера (Node.JS, MongoDB)
а xml можно подумать там не нативный? х)
нет конечно, попробуйте сделать из XML-а сразу обьект и работать с ним дальше. DOM-структура все же гораздо сложнее и тормознее.
дом не сложнее и не тормознее. с чего бы вдруг? впрочем, ru.wikipedia.org/wiki/ECMAScript_%D0%B4%D0%BB%D1%8F_XML
Спасибо, это конечно немного меняет дело.
Но, несмотря на немного уродский синтаксис (alert( sales.item.(@type == «морковь»).@quantity );
как обстоят дела с прозрачной поддержкой во всех браузерах? включая давних версий. Пока вижу только Mozilla что в движке есть. Кроме того, XML имеет гораздо бОльшую избыточность и накладные расходы на передачу. Хотя плюсы тоже есть.
Но, несмотря на немного уродский синтаксис (alert( sales.item.(@type == «морковь»).@quantity );
как обстоят дела с прозрачной поддержкой во всех браузерах? включая давних версий. Пока вижу только Mozilla что в движке есть. Кроме того, XML имеет гораздо бОльшую избыточность и накладные расходы на передачу. Хотя плюсы тоже есть.
XPath (и даже с выражениями) для JSON-а уже есть — goessner.net/articles/JsonPath/
Ждем JSLT взамен XSLT xD
О том и разговор :)
Что сейчас начнется переизобретение всего стека технологий :-)
Что сейчас начнется переизобретение всего стека технологий :-)
Полагаю подобных вещей происходить не будет: JSON это не XML, а XML это не JSON. Заменить одно другим без потери в чём-то невозможно: где-то потеряете гибкость структурах, где-то потеряете лёгкость извлечения данных, где-то потеряете во взаимодействии между разными системами, где-то потреяете в скорости обработки и объёме. Области использования, хоть и пересекаются в некоторых областях, не одни и те же.
И тут эти .json'ы) В школе Параграф такими файлами выгрузку на сайт делает
Недавно была задача внести изменения в конфигурационные файлы в формате JSON. Для этого использовал WSH + скрипт на JS. В моей ситуции эта связка сработала просто отлично!
Для XML есть шикарный инструмент xmlstarlet (обзор на Хабре — habrahabr.ru/blogs/xml/56005/) — все операции с XML делаю с его помощью.
Есть, кстати, биндинг этого yajl на Python: softwaremaniacs.org/blog/2010/09/18/ijson/
Как я понимаю, оно даже используется в продакшн для потокового преобразования JSON в XML где-то во внутренностях API яндекса.
Как я понимаю, оно даже используется в продакшн для потокового преобразования JSON в XML где-то во внутренностях API яндекса.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Потоковый JSON-парсер YAJL