JSON, нюансы использования

[*Rik*]

JSON - это JavaScript Object Notation, буквальное отображение структуры javascript oбъекта в виде строки. Изначально предполагалось, что javascript объекты сериализуются в строку, передаются куда-то, и потом из строки восстанавливаются исходные объекты. Отсюда и (достаточно скудный) набор сущностей, которые можно записать в json.
Так как у объектов не может быть повторяющихся имен полей, то никакой объект не позволит получить строку, которую рассматривают в данной теме. А чтение такой строки приведет к многократной перезаписи полей, которые в конце будут иметь значения, равные последнему прочитанному.

Хорошо сформулировано, спасибо, пригодится.

Дискуссия начинает слегка напоминать притчу о слепых и слоне.

Да нет, все нормально, всё ясно.

Добавлено спустя 36 минут 4 секунды:

Технически, такая конструкция допустима, но по факту, по какому то неписанному правилу или соглашению о работе с JSON (нигде не нашел почему так), почти все парсеры это прочтут, но из повторяющихся ключей, будут прочитаны только самые последние, т.е все парсеры приведут объект к виду { "tovar" : 180, "kolvo" : 2 }, в т.ч. и парсер fcl-json работает точно так-же.

JSON - это JavaScript Object Notation, буквальное отображение структуры javascript oбъекта в виде строки. Изначально предполагалось, что javascript объекты сериализуются в строку, передаются куда-то, и потом из строки восстанавливаются исходные объекты. Отсюда и (достаточно скудный) набор сущностей, которые можно записать в json.
Так как у объектов не может быть повторяющихся имен полей, то никакой объект не позволит получить строку, которую рассматривают в данной теме. А чтение такой строки приведет к многократной перезаписи полей, которые в конце будут иметь значения, равные последнему прочитанному.

Сергей, Вы не знаете, нет ли подобного описания в официальной документации на JSON?

[Sergei I. Gorelkin]

Сергей, Вы не знаете, нет ли подобного описания в официальной документации на JSON?

Смотря что считать официальной документацией. На www.json.org требования уникальности полей объекта нет, в RFC 4627 оно есть, в более позднем RFC 7159 его убрали и заменили оговоркой, что поведение парсеров на строке с дублирующимися полями может быть каким угодно.

[iskander]

На сегодняшний день актуален RFC 8259, в нём дополнительное требование - JSON должен быть в кодировке UTF-8.

[Alex2013]

то не json

Там разновидностей json как-бы много... ( пытался сходу вникнуть только голова заболела )
https://en.wikipedia.org/wiki/JSON#CSON

[*Rik*]

На сегодняшний день актуален RFC 8259, в нём дополнительное требование - JSON должен быть в кодировке UTF-8.

ааа, вот прям то что нужно...

4. Объекты
Структура объекта представляется парой фигурных скобок, внутри которых могут содержаться пары «имя-значение»
(элементы - member). Имя является строкой и отделяется от значения одним символом двоеточия (:). Одиночный
символ запятой (,) отделяет значение от следующего за ним имени. Именам в объекте следует быть уникальными.
object = begin-object [ member *( value-separator member ) ]
end-object
member = string name-separator value
Объект, все имена в котором уникальны, является функционально совместимым в том смысле, что все реализации,
получившие объект, будут принимать его отображения «имя-значение». Если имена в объекте не уникальны,
поведение получившей объект программы не предсказуемо. Многие реализации сообщают лишь последнюю пару
«имя-значение», а другие будут сообщать об ошибке или не смогут разобрать объект, а некоторые реализации будут
сообщать все пары «имя-значение», включая дубликаты имён.
Отмечено, что библиотеки для анализа JSON различаются в части упорядочения объектов, видимых вызывающей
программе. Реализации, чьё поведение не зависит от порядка элементов, будут совместимы в том смысле, что
изменение порядка не будет влиять на них.

[Sergei I. Gorelkin]

Именам в объекте следует быть уникальными.

А, нет, не убирали, такая фраза и в RFC 7159 есть, это я в спешке не увидел.

[*Rik*]

К тому же, чтобы хоть как то прочитать json вида,
{ "tovar" : 18, "kolvo" : 2, "tovar" : 36, "kolvo" : 2, "tovar" : 123, "kolvo" : 2, "tovar" : 162, "kolvo" : 2, "tovar" : 180, "kolvo" : 2 }
если такой парсер найдется, это предполагает что поля tovar и kolvo должны следовать в определенном порядке, что тоже нарушает требование стандарта, не факт что какая-нибудь левая библиотека, способная создавать такие конструкции, выдаст их в нужном порядке.

[iskander]

Именам в объекте следует быть уникальными.

Мне кажется лучше перевести на русский как "следовало бы":

Код: Выделить всё

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.


это предполагает что поля tovar и kolvo должны следовать в определенном порядке, что тоже нарушает требование стандарта

Это не требование, всего лишь рекомендация.

[*Rik*]

Именам в объекте следует быть уникальными.

Мне кажется лучше перевести на русский как "следовало бы":

Код: Выделить всё

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.


это предполагает что поля tovar и kolvo должны следовать в определенном порядке, что тоже нарушает требование стандарта

Это не требование, всего лишь рекомендация.

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