Здравствуйте, B0FEE664, Вы писали:

BFE>>>Например: где проверка, что значение с именем уже было задано для данного объекта? { "a":"asdf", "a":"fghj"}
vsb>>Это валидный JSON. Тут никаких проверок не нужно.

BFE>Я не знаю Java. Скажите, в HashMap будут сохранены оба значения для "a"?

Нет, будет сохранено последнее.

Здравствуйте, vsb, Вы писали:

vsb>Нет, будет сохранено последнее.
Разве это ожидаемый результат?

Здравствуйте, B0FEE664, Вы писали:

vsb>>Нет, будет сохранено последнее.
BFE>Разве это ожидаемый результат?

JSON.parse('{ "a":"asdf", "a":"fghj"}')
{a: 'fghj'}

Это JS. От которого JSON, собственно, пошёл. Видимо — да, ожидаемый. Если хочется передавать несколько ключей с одинаковым именем — нужно вместо Map взять Multimap, которого в жаве из коробки нет, но подключив нужную библиотеку это скорей всего будет изменение ровно одной строчки.

Здравствуйте, vsb, Вы писали:

vsb>Это JS. От которого JSON, собственно, пошёл. Видимо — да, ожидаемый. Если хочется передавать несколько ключей с одинаковым именем — нужно вместо Map взять Multimap, которого в жаве из коробки нет, но подключив нужную библиотеку это скорей всего будет изменение ровно одной строчки.

Нормальный стандарт прояснял бы такую ситуацию, а JSON — неопределённое поведение во всём.

Здравствуйте, B0FEE664, Вы писали:

BFE>Нормальный стандарт прояснял бы такую ситуацию, а JSON — неопределённое поведение во всём.

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

Здравствуйте, rollcoin, Вы писали:

BFE>>Нормальный стандарт прояснял бы такую ситуацию, а JSON — неопределённое поведение во всём.
R>Не очень глупый человек сначала прочитает стандарт, чтобы рассуждать о том, что он определеята, что нет.

В том-то и дело, что авторы по своей зашоренности изначально упустили из виду множество ситуаций, а потом им пришлось описывать в стандарте наблюдаемое положение дел.

Здравствуйте, vdimas, Вы писали:

V>Что мешало ввести в JSON "уровни", "слои", "диалекты", чтобы общающиеся по протоколу JSON counterparty могли специфировать этот уровень/диалект?

Мешал хорошо известный опыт реализации таких штук. Был SOAP, херово реализованный примерно везде, был и есть XML/XSLT, который можно написать так, что на винде он в .net core будет работать, а в .net core на линуксе — падать.

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

JSON примитивен, и даже его иногда умудряются испортить.

Здравствуйте, Слава, Вы писали:

С>JSON примитивен, и даже его иногда умудряются испортить.

JSON изначально испорчен. И ничем не лучше SOAP. Мне точно так же приходили данные из Java, которые в JS молча парсились неправильно, т.к. в жаве long, а в JS 53-битовые числа, а всё, что больше — округляется там как-то. В SOAP я с таким не сталкивался. Там если что-то не работает, то оно не работает, а не молча портит данные.

Конечно поезд XML уже ушёл, это понятно. Но мне до сих пор смешно, когда я вижу в JSON base64-строку, в которой закодирован ещё один JSON, в котором есть ещё одна BASE64 строка и так далее. Вроде один раз уровня 4 вложенности раскопал. И это предлагается вместо человеческих namespace-ов.

Здравствуйте, B0FEE664, Вы писали:

B>>3. Аномальные величины вроде "гигабайтных 0.000000001" не принимаются. Вернее, парсер должен уметь им противостоять, но никак не обрабатывать, ибо само наличие таких приколов — аномалия, реальные числа такими не бывают.
BFE>парсер должен уметь им противостоять, но многие ли умеют?
По хорошему, именно что парсер должен разобрать входной поток на структурированные токены а валидацией (т.е. пониманием что это не число нифига, или формат даты неправильный) должен заниматься собственно код импорта этой структуры. За каким хреном их постоянно пытаются совместить, создавая этим дополнительные проблемы и вынуждая девелоперов бороться с ними — мне лично не понятно.

B>>Вообще, мы тут именно о JSON — сам формат — простой. Стресс-тесты никак к его простоте не относятся!
BFE>Относятся. В JSON мало ограничений, поэтому работать с ним сложно.
Да в общем то нет.

Здравствуйте, vsb, Вы писали:

vsb>А я считаю, что это одна из лучших технологий сегодня. И то, что почти все интерфейсы сегодня пишут на HTML, даже там, где есть альтернативы (в тех же мобильных приложениях 2 из 3 это webview по моим ощущениям) — лучшее тому доказательство.

Просто веб — дешёвая кроссплатформа. Пока не было нужно поддерживать зоопарк из винды, линукса, мака и мобильных устройств, то делали десктопы и не парились.
Сейчас всем нужна кроссплатформа и не хотят пилить отдельные приложения под разные ОС.

vsb>В IT — не замечал. Когда цена копирования нулевая — выигрывает качество. Иногда выигрывает маркетинг, но только временно, как это было в своё время с виндой, которую втюхали неграмотному населению, но время расставило всё по своим местам.

И что же время расставило? Что за годы развития, линукс так и не повернулся к пользователям лицом и винда удобнее?

Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, maxkar, Вы писали:

BFE>>>Вот вы говорите, что "парсер json — тривиально". Тогда вам не сложно будет ответить на вопрос, что должен выдать парсер для следующего массива?:
M>>А что вам по задаче нужно?
BFE>Речь не про задачу, речь про стандартизованный формат
И было бы почти то же самое. Потому что стандарты мало кто читает и следует им. Куча фреймоврков в http-ответе использует Content-Type:application/json;charset=UTF-8. Хотя в IANA параметр не зарегистрирован, да и все JSON RFC пишут прямым текстом, что "у application/json нет параметра charset". Для практических применений можно взять какую-нибудь JSON Schema. Там будут и типы полей, и ограничения на строки, и все остальное.

Текущая спецификация дает много на откуп реализации, но позволяет делать много и относительно дешево. В 1150 строк (не кода, а всего исходного текста) входит парсер, писатель, сама модель и утилиты для работы с моделью в коде (построение и разбор). Для практических задач можно использовать. А всякие сложности вроде "0.000..01" во многих случаях можно игнорировать.

M>>Парсеры ограничения по глубине не имеют
BFE>Любопытно, сколько времени ушло на написание парсера и сколько строк кода он содержит?
Про тот, который без ограничения по глубине? Сам парсер — 1857 строк текста. Это включает код разбора, интерфейсы интеграции, документацию кода и утилиты (например, утилиты для создания обработчика ошибок — большинству реализаций достаточно просто вывести сообщение). Парсер длинный, но есть некоторая избыточность. Например, парсить числа можно разными способами: можно вычитывать данные, можно читать отдельные секции, можно использовать "конечный автомат" для распознавания входящей строки. Конкретно парсер про стек ничего не знает, ему нужна в помощь конкретная монада. Простейшие тесты используют Unnest. Это 156 строк — преимущественно комментарии. Кода там строк 50. Более интересные примеры (со вводом/выводом) используют корутины. В них 145 строк, но кода больше, чем в Unnest. Собственно, пример — потоковый форматтер. 562 строки (с комментариями, пустыми строками и прочим).

По времени (wall-time) это было примерно полтора месяца. Там было две итерации (переписывание push в pull, в push не все выходило, что я хотел). Но это были не полные рабочие дни. Рабочего времени там где-то 40-80 часов. Плюс много экспериментов, как с API JSON-парсера, так и с нижележащими потоками (основной вопрос — как абстрагировать блокирующий/неблокирующий ввод, сделать look-ahead, как получать позицию входного потока, если о ней парсер не должен ничего знать и т.д.). Если бы я делал сейчас, было бы гораздо быстрее. Зато я научился делать универсальные вещи. Я когда-нибудь сделаю трекинг позиций для конфигурации приложения. Давно уже хочется иметь возможность спросить у приложения: "а в какой конфигурцаии ты запущено, и почему?". А приложение возьмет, да и ответит: "Конфигурация a.b.c=3, потому что я прочитало это из config.properties (строка 10, позиция 15-17). Да, оно также было определено в defaults.json (строка 20, позиция 28-30), но этот конфиг имеет меньший приоритет". У меня уже есть много готовых кирпичиков и технология их склейки вместе .

Здравствуйте, maxkar, Вы писали:

BFE>>Речь не про задачу, речь про стандартизованный формат
M>И было бы почти то же самое. Потому что стандарты мало кто читает и следует им.
Это почему это? Многие по работе читают и обязаны следовать стандартам.

M> Куча фреймоврков в http-ответе использует Content-Type:application/json;charset=UTF-8. Хотя в IANA параметр не зарегистрирован, да и все JSON RFC пишут прямым текстом, что "у application/json нет параметра charset".
Вот поэтому весь веб такой медленный и глючный.

M>Для практических применений можно взять какую-нибудь JSON Schema. Там будут и типы полей, и ограничения на строки, и все остальное.
Там написано, что 1.0 — это integer. здесь

M>Текущая спецификация дает много на откуп реализации, но позволяет делать много и относительно дешево. В 1150 строк (не кода, а всего исходного текста) входит парсер, писатель, сама модель и утилиты для работы с моделью в коде (построение и разбор). Для практических задач можно использовать. А всякие сложности вроде "0.000..01" во многих случаях можно игнорировать.

Для практических...
Допустим контора по контракту пишет продукт, который должен выдавать данные в Json. Допустим в этих данных встречаются вот такие числа, которые парсер заказчика не понимает. Кто должен править свой код?

M>>>Парсеры ограничения по глубине не имеют
BFE>>Любопытно, сколько времени ушло на написание парсера и сколько строк кода он содержит?
M>Про тот, который без ограничения по глубине?
Парсер посмотрелю, но scala я не знаю и не понял как организована работа с результатом. Там должна быть иерархическая структура, но я её не разглядел.

M>По времени (wall-time) это было примерно полтора месяца. Там было две итерации (переписывание push в pull, в push не все выходило, что я хотел). Но это были не полные рабочие дни. Рабочего времени там где-то 40-80 часов.
Ну вот, что-то реальное.

Здравствуйте, B0FEE664, Вы писали:

M>>Для практических применений можно взять какую-нибудь JSON Schema. Там будут и типы полей, и ограничения на строки, и все остальное.
BFE>Там написано, что 1.0 — это integer.
Да уж . В свое оправдание могу сказать только, что схемой не пользуюсь и пишу документацию в markdown.

M>> А всякие сложности вроде "0.000..01" во многих случаях можно игнорировать.
BFE>Для практических...
BFE>Допустим контора по контракту пишет продукт, который должен выдавать данные в Json. Допустим в этих данных встречаются вот такие числа, которые парсер заказчика не понимает. Кто должен править свой код?
Предположу, что заказчим. Потому что поставщик данных приложил дополнительные усилия, чтобы сгенерировать такие числа (в решених по-умолчанию обычно подобного не встречается). Большинство библиотек по разбору это число разберут в 0 и тоже проблем не будет. Так что заказчик здесь скорее всего тоже постарался.

Но в какой-то степени я с вами согласен. Во многих текстовых форматах для машинного обмена есть проблемы с точностью или диапазоном значений — они просто не специфицированы. А там, где специфицированы — опять все сделают не так. Например, apache tomcat был подвержен уязвимости в разборе чисел с плавающей точкой. Это для значения параметра q у значений заголовков, который имеет не более трех десятичных позиций.

BFE>Парсер посмотрелю, но scala я не знаю и не понял как организована работа с результатом. Там должна быть иерархическая структура, но я её не разглядел.
В парсере? Нет, не должно — это нарушает Single Responsibility Principle. Парсер должен уметь парсить. А модель пусть строит кто-нибудь другой, да и моделей может быть много разных . Хотя для стандартных случаев я все же сделал утилиту (строка 147 если вдруг ссылка съехала). Там все скучно и сделано в рекурсивном стиле. Раскруткой рекурсии занимается выше упомянутый Unnest (или корутины). Более сложные случаи вроде атрибутов переиспользуют большую часть реализации, но верхнюю диспетчеризацию делают вручную. Например, сохранение позиции из модели. Я пробовал через callback'и сначала. Мне не понравилось. Особенно не понравились сложности с остановкой в ходе процесса. Например, построитель модели решил, что 500Мб для числа — как-то многовато и нужно бы остановиться. При этом интерфейс модели должен позволять получать позицию в потоке, навешивать дополнительные атрибуты (а их может быть много) и т.п. Вариант с передачей всего контроля наружу и переиспользованием там, где можно, мне пока больше нравится.

Здравствуйте, CreatorCray, Вы писали:

B>>именно за читабельность и простоту.
CC>Шта? То, что в проде в json высирают точно так же нечеловекочитаемо. Только лиспер с опытом сможет на глаз увидеть скобочки в многомегабайтном однострочнике.

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

Здравствуйте, karbofos42, Вы писали:

K>Так парсеру ничего знать и не нужно. У формата есть несколько управляющих символов: {}[],:"
K>Вот посредством них входная строка делится на токены. Значение можно так строкой и хранить, т.к. она из файла и пришла.
K>Ну, а дальше клиентский код сам скажет что ему нужно. Просто нужны будут конвертеры из строки в нужные типы данных.
K>Зачем при чтении преобразовывать 12345 в int, если потом клиентский код может захотеть float? Чтобы добавлять лишние проверки и конвертации сначала из строки в int, а потом из int во float?

Следующие строки в Json эквивалентны: "12345" и "\u00312345". Вы уверены, что клиентский код должен об этом знать?

Все просто и банально: молоток для гвоздей, отвертка для шурупов, а гаечный ключ — для гаек и болтов.

Иначе говоря, назначение и особенности BSON описаны тут: https://bsonspec.org/faq.html:

What is the point of BSON when it is no smaller than JSON in some cases?

BSON is designed to be efficient in space, but in some cases is not much more efficient than JSON. In some cases BSON uses even more space than JSON. The reason for this is another of the BSON design goals: traversability. BSON adds some "extra" information to documents, like length of strings and subobjects. This makes traversal faster.

BSON is also designed to be fast to encode and decode. For example, integers are stored as 32 (or 64) bit integers, so they don't need to be parsed to and from text. This uses more space than JSON for small integers, but is much faster to parse.

Все просто, кратко и понятно ИМХО.

Здравствуйте, CreatorCray, Вы писали:

B>>>3. Аномальные величины вроде "гигабайтных 0.000000001" не принимаются. Вернее, парсер должен уметь им противостоять, но никак не обрабатывать, ибо само наличие таких приколов — аномалия, реальные числа такими не бывают.
BFE>>парсер должен уметь им противостоять, но многие ли умеют?
CC>По хорошему, именно что парсер должен разобрать входной поток на структурированные токены а валидацией (т.е. пониманием что это не число нифига, или формат даты неправильный) должен заниматься собственно код импорта этой структуры. За каким хреном их постоянно пытаются совместить, создавая этим дополнительные проблемы и вынуждая девелоперов бороться с ними — мне лично не понятно.
Не совсем понятно, что именно должен делать в таком случае парсер, что выдавать в качестве результата. Строку с пометкой "это Json число"?

B>>>Вообще, мы тут именно о JSON — сам формат — простой. Стресс-тесты никак к его простоте не относятся!
BFE>>Относятся. В JSON мало ограничений, поэтому работать с ним сложно.
CC>Да в общем то нет.

Что — нет? Вот на прошлой неделе встретился с очередным маразмом: взяли Json файл, сжали его zip'ом, полученную zip-строку закодировали в BASE64, в полученной строке заменили '=' на '\u003D', результат положили в виде строкового значения в Json файл. Ага, Json ведь для того и придуман, чтобы передавать данные в человекочитаемом виде.

Здравствуйте, DiPaolo, Вы писали:

DP>Все просто, кратко и понятно ИМХО.

Ты читать вообще умеешь?

DP>BSON is also designed to be fast to encode and decode.

А по факту — почти в 4 раза медленнее.

Здравствуйте, Codealot, Вы писали:

C>BSON, бинарный формат — по идее должен быть компактее и быстрее.

JSON — очень компактный формат.

C>Как, вот как можно было всё настолько изгадить?

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

Здравствуйте, νsb, Вы писали:

νsb>Размер надо сравнивать после gzip-а. Скорость — скорей всего недоработка реализации. В целом не вижу места никаким форматам общего назначения кроме JSON.

А совсем недавно сегодняшние любители JSON-а в целом не видели места никаким форматам общего назначения, кроме XML...