Json.NET (Newtonsoft.Json) - два свойства с одинаковым именем?

Я кодирую C # для .NET Framework 3.5.

Я пытаюсь разобрать Json на JObject.

Json выглядит следующим образом:

{
    "TBox": {
        "Name": "SmallBox",
        "Length": 1,
        "Width": 1,
        "Height": 2 },
    "TBox": {
        "Name": "MedBox",
        "Length": 5,
        "Width": 10,
        "Height": 10 },
    "TBox": {
        "Name": "LargeBox",
        "Length": 20,
        "Width": 20,
        "Height": 10 }
}

Когда я пытаюсь преобразовать этот Json в JObject, JObject знает только о LargeBox. Информация для SmallBox и MedBox потеряна. Очевидно, это потому, что он интерпретирует TBox как свойство, и это свойство перезаписывается.

Я получаю этот Json из службы, написанной на Delphi. Я пытаюсь создать прокси C # для этой службы. На стороне Delphi "TBox" понимается как тип возвращаемого объекта. Внутренние свойства («Имя», «Длина», «Ширина», «Высота») тогда понимаются как обычные свойства.

Я могу сериализовать и десериализовать пользовательский объект TBox, который имеет свойства Name, Length, Width и Height. Это нормально.

Я хочу пройти через все разделы TBox таким образом, чтобы извлечь следующие три строки Json.

Первый:

{
    "Name": "SmallBox",
    "Length": 1,
    "Width": 1,
    "Height": 2 }

Второй:

{
    "Name": "MedBox"
    "Length": 5,
    "Width": 10,
    "Height": 10 }

Третий:

{
    "Name": "LargeBox"
    "Length": 20,
    "Width": 20,
    "Height": 10 }

Получив эти строки, я могу сериализовать и десериализовать, сколько душе угодно.

Я считаю, что Newtonsoft.Json очень хорош. Я действительно не хочу возиться с другими фреймворками, если я могу этого избежать.

Любая помощь будет принята с благодарностью.

У меня очень ограниченный ввод изменений, которые можно внести на сервер.


json properties duplicates json.net
person Ubiquitous Che    schedule 06.10.2010    source источник

Ответы (2)


arrow_upward
8
arrow_downward 

using Newtonsoft.Json;
using Newtonsoft.Json.Linq;

JsonTextReader jsonReader = new JsonTextReader(reader);
jsonReader.Read();
while(jsonReader.Read())
{
    if(jsonReader.TokenType == JsonToken.StartObject)
    {
        JObject tbox = JObject.Load(jsonReader);
    }
}

Однако обратите внимание, что в RFC сказано: «Имена внутри объекта ДОЛЖНЫ быть уникальными», поэтому если можете, рекомендую изменить формат.

РЕДАКТИРОВАТЬ: вот альтернативный дизайн, в котором нет повторяющихся ключей:

[
    {
        "TBox": {
            "Width": 1,
            "Length": 1,
            "Name": "SmallBox",
            "Height": 2
        }
    },
    {
        "TBox": {
            "Width": 10,
            "Length": 5,
            "Name": "MedBox",
            "Height": 10
        }
    },
    {
        "TBox": {
            "Width": 20,
            "Length": 20,
            "Name": "LargeBox",
            "Height": 10
        }
    }
]
person Matthew Flaschen    schedule 06.10.2010
comment
Идеально! Это было быстро. Спасибо. - person Ubiquitous Che; 07.10.2010
comment
Отправлено по RFC-ссылке и побеседовал с одним из старших разработчиков. Слово ДОЛЖНО иметь особое значение в RFC 2119, что в основном означает, что политике СЛЕДУЕТ следовать, если нет достаточно веских причин для ее нарушения. В этом случае есть - реализация на сервере включает рассылку списков общих типов. Конкретный тип, который будет сериализован / десериализован, используется как «имя» верхнего уровня Json. Мне неприятно писать код против, но они все еще в RFC. - person Ubiquitous Che; 07.10.2010
comment
@ Вездесущий, я никогда не говорил, что это нарушает RFC. Но это не интуитивно понятно, и я не обязательно согласен, что это причина его нарушить. Есть и другие конструкции, которые предоставляют информацию о типе без повторяющихся ключей. - person Matthew Flaschen; 07.10.2010
comment
В этом случае я бы интерпретировал SHOULD как указание разработчикам-парсерам JSON, что они не должны выдавать ошибку при обнаружении повторяющихся имен. Однако, поскольку JS в JSON означает JavaScript и структуры данных JavaScript НЕ МОГУТ иметь повторяющиеся имена, мне кажется очевидным, что ваши ребята из Delphi нарушают дух, если не букву, спецификации. Поведение Newtonsoft совершенно правильное, потому что это то же самое, что делал бы парсер JavaScript. - person Joel Mueller; 07.10.2010
comment
Ха! Я передам это. Мой аргумент заключался в том, что то, как они это сделали, не будет работать для большинства обычных синтаксических анализаторов. Их ответ заключался в том, что парсеры виноваты в том, что они не соблюдают правильное значение слова «ДОЛЖЕН». ^ _ ^ Спасибо за поддержку и дальнейшие действия, мы очень ценим это. - person Ubiquitous Che; 07.10.2010
comment
Как разработчик рассматриваемой службы я скажу только следующее: спецификация JSON допускает дублирование имен. Если вы не разрешаете дублирование имен в своих структурах, то то, что у вас есть, в соответствии с его собственными условиями, не является JSON. Я бы также сказал, что сервис находится в зачаточном состоянии. Дублированные значения в настоящее время даже не используются, но предполагается, что они могут быть использованы. Может быть разработан альтернативный подход, но любое изменение будет основано на принятии правильного решения для реализации сервера, а не просто на том, чтобы облегчить жизнь людям, желающим использовать несовместимые синтаксические анализаторы. - person Deltics; 07.10.2010
comment
@Matthew: вы заметили, что ваш альтернативный дизайн вводит дополнительную структуру с дополнительным семантическим вкладом NIL. Именно от такого увеличения соотношения шум: сигнал JSON намеревался избавить нас с помощью подобных XML! Текущий совместимый дизайн - в этом смысле - намного больше соответствует духу JSON, помимо того, что он полностью соответствует букве спецификации! ;) - person Deltics; 07.10.2010
comment
Объект в JSON - это коллекция имени / значения, и этот JSON неправильно использует имя. JObject Json.NET в этом примере делает именно то, что сделал бы браузер, если бы ему были предоставлены повторяющиеся свойства: использует последнее значение. Лучшее решение - изменить JSON, чтобы он либо имел объект-оболочку со свойством для имени типа и свойством для значения, либо добавлял тип в качестве специального свойства для объекта значения. - person James Newton-King; 07.10.2010
comment
Услуга не предназначена для использования веб-браузером. Я не вижу особого (нет) смысла в написании этого способа, для которого он не предназначен для использования, когда это менее эффективно (не только в представлении, но и в усилиях по обработке для сериализации / десериализации). Подстаканникам нет места в болидах формулы 1. ;) Если он нарушает спецификацию, тогда вы можете быть правы, но это не так. И это нижняя строка imho. Я просто не понимаю, как быть правым - значит ошибаться. - person Deltics; 07.10.2010
comment
Я использовал веб-браузер в качестве примера, потому что это наиболее популярное использование JSON, и оно определяет, как люди ожидают, что объект JSON будет работать: коллекция имени / значения. Вы не нарушаете спецификацию, но вы нарушаете ожидания пользователей. - person James Newton-King; 07.10.2010
comment
Спасибо, что сообщили нам, чего ждут наши пользователи. Мне интересно, что вы знаете, чего они ожидают, когда вы ничего не знаете о приложении (кроме того, что вы игнорируете то, что я вам уже сказал). На всякий случай, если ФАКТИЧЕСКОЕ использование имеет ЛЮБОЕ значение (это может быть не для вас, но как для человека, реализующего эту вещь, это обязательно для меня), я отмечу, что JSON используется в этом случае как легкий механизм для передача данных между двумя приложениями, НИ ОДИН из которых не является веб-браузером, и НИ ОДИН из которых не будет перекачивать данные через синтаксический анализатор или движок JavaScript. - person Deltics; 07.10.2010
comment
Спокойствие - я высказываю свое мнение, пытаясь помочь, а не критиковать вас. В любом случае, пользователь в данном случае является разработчиком. Разработчики привыкли работать с объектами JSON, которые представляют собой коллекции имя / значение. Домашняя страница JSON - json.org - определяет их как просто: коллекцию имени / значения. Опять же, вы не нарушаете спецификацию, но вы нарушаете ожидания пользователя (разработчика). Если у вас есть веская причина для структурирования JSON, как у вас, тогда это нормально, просто имейте в виду, что, делая что-то нестандартное, у потребителей JSON может возникнуть больше вопросов о помощи, подобных этому. - person James Newton-King; 07.10.2010
comment
Deltics - Если вы найдете хотя бы один парсер JSON, созданный не в вашей компании, который поддерживает повторяющиеся имена в коллекции имен / значений JSON, я съем свою шляпу. И если вы скажете мне, что это означает, что все парсеры JSON не соответствуют спецификации, над вами будут смеяться ... - person Joel Mueller; 07.10.2010
comment
@Joel - ЛЮБОЙ парсер JSON, который не выдает ошибку при обнаружении повторяющихся имен, по определению ПОДДЕРЖИВАЕТ повторяющиеся имена. Парсер Newtonsoft, который использует мой коллега, является еще одним примером. Он не только поддерживает повторяющиеся имена, но также позволяет коду РАБОТАТЬ с представлениями JSON, СОДЕРЖАЩИМИ повторяющиеся имена. Хочешь соуса к шляпе? РОФЛ - person Deltics; 07.10.2010
comment
Deltics, парсер Newtonsoft Джеймса Ньютона-Кинга делает то же самое, что и сам JavaScript - если он обнаруживает повторяющиеся ключи, каждый последующий дублирующий ключ перезаписывает предыдущее значение для этого ключа. В итоге у вас есть один ключ с одним значением. В этом он следует спецификации, которая не требует сохранения нескольких значений при обнаружении повторяющихся ключей. Обходной путь Мэтью, описанный выше, включает непосредственную работу с потоком токенов JSON, в частности, из-за этой проблемы. Боюсь, ты ошибаешься по всем пунктам. Тем не менее, неплохая попытка. - person Joel Mueller; 07.10.2010
comment
@Deltics Любой парсер JSON, который по определению не выдает ошибку при обнаружении повторяющихся имен, ПОДДЕРЖИВАЕТ повторяющиеся имена. Сделай мне одолжение. Откройте Firebug и запустите следующий оператор, чтобы проанализировать ваш JSON и рассказать нам все, что происходит. console.log (eval ({TBox: {Имя: SmallBox, Длина: 1, Ширина: 1, Высота: 2}, TBox: {Имя: MedBox, Длина: 5, Ширина: 10, Высота: 10}, TBox: { Имя: LargeBox, длина: 20, ширина: 20, высота: 10}})) - person Shawn Grigson; 08.10.2010
comment
Как я думал. Вы, ребята, путаете парсер JSON с движком JavaScript. Это все равно, что сказать XML Parser, когда вы имеете в виду .NET Framework в связи с файлом конфигурации .appdata. Да, это XML, но именно то, что вы с ним ДЕЛАЕТЕ, определяет правильность конкретного ИСПОЛЬЗОВАНИЯ. Если рассматривать отдельно от ТИПА документа, то, является ли XML действительным или нет, определяется спецификацией XML. То же самое и здесь. Создаваемый JSON действителен. Он несовместим с JavaScript EXECUTION, но это нормально, потому что он не используется. - person Deltics; 08.10.2010
comment
@Shawn: Это не анализатор JSON, а выполнение кода JavaScript. Если вы не понимаете разницы, то бессмысленно обсуждать с вами то, что вы видите, и пытаться объяснить, почему это не имеет ни малейшего отношения к рассматриваемой проблеме. - person Deltics; 08.10.2010
comment
@Joel: Он делает это, если вы используете его для десериализации объектов с использованием инфраструктуры автоматической десериализации, которую он предоставляет, но если вы рассматриваете его просто как JSON PARSER, можно получить доступ к значениям с такими же именами, как и к дискретным значениям. Я знаю, что можете, потому что я видел, как это было сделано (и мне даже не пришлось писать код самому). - person Deltics; 08.10.2010
comment
@Deltics: У тебя талант быть до раздражения тупым. Это не парсер JSON, он выполняет код JavaScript. JSON - это объектная нотация JavaScript! Невозможно утверждать, что JSON не имеет ничего общего с JavaScript! И как «разобрать» строку JSON с помощью JavaScript? С помощью оператора eval (). Существуют фреймворки Javascript, такие как ExtJS, которые делают что-то вроде Ext.JSON.decode (‹json›), но в основном то, что они делают, - это скрытые вызовы eval (). Вот как JavaScript разбирает JSON. console.log () просто выводит его, чтобы вы могли просмотреть результаты. - person Shawn Grigson; 04.11.2010
comment
@Deltics: Моя точка зрения (которую вы пытаетесь игнорировать) заключается в том, что сам JavaScript не поддерживает несколько ключей в JSON. Вы также заявили, что если он не выдает ошибку, он по своей природе поддерживает несколько ключей, но сам JavaScript не поддерживает несколько ключей, но и не выдает ошибку. Утверждать, что JavaScript на самом деле не разбирает JSON, - это просто семантический обман. Вам нужно выполнить код, чтобы что-то проанализировать, и если вы передадите структуру JSON из файла в JavaScript, вам нужно будет как-то разобрать ее - и когда вы это сделаете, вы обнаружите, что она не поддерживает повторяющиеся ключи. Кей? - person Shawn Grigson; 04.11.2010
comment
@Shawn - у вас есть талант не читать простой английский, который вам поставили. JSON используется здесь как ФОРМАТ ДАННЫХ, а не как исполняемый исходный код. Данные в JSON разработаны и предназначены для вывода кодом Delphi и чтения / анализа синтаксическим анализатором Delphi JSON и / или синтаксическим анализатором C #. Сам JavaScript в любом случае нигде не задействован. При использовании в качестве формата обмена данными, не связанного с JavaScript, требования JavaScript полностью и полностью НЕОБХОДИМЫ, и я думаю, поэтому СПЕЦИФИКАЦИЯ НЕ делает обязательным, чтобы данные JSON полностью соответствовали синтаксису JavaScript. - person Deltics; 05.11.2010
comment
@Deltics - JavaScript Object Notation = JSON - Если при использовании в качестве формата данных он не может быть правильно декодирован в собственные объекты Javascript, то это не JSON. Период. Не имеет ничего общего с тем, прикоснется ли к нему JavaScript или нет. Я никогда не утверждал, что ваш JSON должен быть исполняемым исходным кодом. Я пытаюсь указать на то, что ваш JSON недействителен в контексте JavaScript, что означает, что первые две буквы аббревиатуры нарушены в вашей реализации. Возможно, вы используете ON в качестве формата данных или DON (объектную нотацию Delphi). Однако вы не используете JSON. - person Shawn Grigson; 11.11.2010
comment
@Deltics - Более того, вы сказали, что ЛЮБОЙ парсер JSON, который не выдает ошибку при обнаружении повторяющихся имен, по определению ПОДДЕРЖИВАЕТ повторяющиеся имена. JavaScript не выдает ошибку, когда он анализирует (т. Е. Не выполняет, просто анализирует) JSON с повторяющимися именами. Но он также не поддерживает повторяющиеся имена. Так что я звоню BS по этому заявлению. Я уверен, что вы скажете это, поскольку я использовал eval () в своем примере, что JavaScript «выполняет» JSON, который является только семантикой. json.org объясняет, что вы используете eval () для преобразования текста JSON в объект. json.org/js.html (продолжение) - person Shawn Grigson; 11.11.2010
comment
@Deletics - Обратите особое внимание: поскольку JSON является правильным подмножеством JavaScript, компилятор правильно проанализирует текст и создаст структуру объекта. Получить часть о том, где говорится, что компилятор правильно проанализирует текст? Угадайте, что это такое. Это ваш парсер делает это не правильно. Тем не менее вы утверждаете, что все, что не вызывает ошибки при обнаружении повторяющихся имен, поддерживает повторяющиеся имена, а это не так. JSON - это подходящее подмножество JavaScript. JavaScript не поддерживает повторяющиеся имена. Ты делаешь это неправильно. - person Shawn Grigson; 11.11.2010
comment
@Deltics - при написании парсера на .NET или любом другом языке для JSON вы часто собираетесь передавать данные в / из JavaScript. Вы выведете данные, предназначенные для использования с помощью JavaScript, или получите JavaScript для сериализации данных, чтобы вы могли их прочитать. Вам нужно, чтобы ваш синтаксический анализатор точно отображал вещи на вашем родном языке в соответствии с тем, как они будут обрабатываться JavaScript. Что он делает в данном случае. Что вы предлагаете? Что парсер NewtonSoft должен вести себя в соответствии с вашей интерпретацией спецификации, а не в соответствии с тем, как это обрабатывается JavaScript? - person Shawn Grigson; 11.11.2010
comment
Я не могу поверить, что этот разговор все еще продолжается, но, как мне кажется, Шон пытается сказать следующее: если спецификация для нотации объектов JavaScript каким-либо образом неоднозначна, вы разрешаете неоднозначность, глядя на то, что делают парсеры JavaScript. Не будучи самоуверенным педантом. - person Joel Mueller; 11.11.2010
comment
@Joel: Спецификация JSON совершенно недвусмысленна. Это позволяет дублировать имена. Он НЕ требует уникальности и НЕ относится к ним как к парам ключ / значение, а к парам значений NAME. Шон категорически неправ. Другие парсеры, включая .NET и тот, на который он ссылается Newtonsoft, ОБЯЗАТЕЛЬНО поддерживают поиск нескольких объектов с повторяющимися именами. Наш парсер в этом отношении не уникален и полностью соответствует спецификации. По-видимому, Шон также считает, что MP3 не должен содержать аудио, поскольку MP означает «ДВИЖУЩЕЕСЯ ИЗОБРАЖЕНИЕ», несмотря на то, что сказано в спецификации. - person Deltics; 12.11.2010
comment
@Shawn и @Joel: Последнее слово от меня: спецификация JSON описывает действительное содержимое и структуру текстовой структуры данных JSON. Он специально РАЗРЕШАЕТ дублировать имена значений в заданном наборе пар имя / значение. Спецификация JSON не содержит комментариев и не требует определенного поведения от JSON синтаксического анализатора, хотя разумно сделать вывод, что, поскольку разрешены повторяющиеся имена, синтаксический анализатор должен это учитывать. .. продолжение .. - person Deltics; 12.11.2010
comment
... По крайней мере, один альтернативный синтаксический анализатор, процитированный мной в качестве примера того, как синтаксический анализатор должен себя вести, ТАКЖЕ поддерживает повторяющиеся имена, точно так же, как мы. Таким образом, ясно, что существует путаница и непонимание того, что является правильным, а что нет в этой области (и действительно, относительно того, какие возможности поддерживают и предлагают другие реализации), но эта путаница и недопонимание одинаково явно НЕ на my < / i> часть. - person Deltics; 12.11.2010
comment
@Deltics - В спецификации сказано, что имена ДОЛЖНЫ быть уникальными. Да, я понимаю разницу между ДОЛЖЕН и ДОЛЖЕН. В спецификации не сказано, что парсеры должны делать с повторяющимися ключами - в этом заключается двусмысленность, о которой я имел в виду. Что делает канонический парсер JSON, JavaScript, с дубликатами? Он их отбрасывает. То же самое и с Newtonsoft, если вы не опускаетесь до уровня потока токенов, что никому не нужно делать только для чтения ваших значений. В любом случае, мне очень приятно, что мне никогда не придется с тобой работать. OP имеет мои соболезнования. - person Joel Mueller; 15.11.2010
comment
@Deltics - Думаю, повторение может сработать. Поскольку JSON является правильным подмножеством JavaScript, компилятор правильно проанализирует текст и создаст структуру объекта. Ваш материал не является правильным подмножеством JavaScript, следовательно, это не JSON. Компилятор JavaScript правильно анализирует текст, но вы утверждали, что все, что не вызывает ошибок, поддерживает повторяющиеся ключи, а JavaScript не выполняет ни того, ни другого. Я могу сказать, что заставить вас признать свою неправоту невозможно, но, надеюсь, ваши частые уловки достаточно очевидны для любого, кто приходит сюда, желая знать, как это сделать правильно. - person Shawn Grigson; 15.11.2010
comment
@Joel - OP сидит прямо за мной, и за 10 минут работы удалось получить значения с помощью Newtonsoft без, afaik, необходимости взламывать поток токенов. JavaScript НЕ ЯВЛЯЕТСЯ парсером JSON. Он может выполнять JSON как побочный эффект того факта, что JSON предназначен для выполнения как JavaScript. JSON позволяет дублировать имена, мой компонент тоже. Он не применяет несуществующее правило, но и не ПРИНУЖДАЕТ кого-либо НАРУШИТЬ какие-либо правила. - person Deltics; 16.11.2010
comment
Мое собственное повторение может сработать: СПЕЦИФИКАЦИЯ допускает дублирование имен - вам это может не понравиться, но это простой ФАКТ. Поэтому мой parser поддерживает и допускает повторяющиеся имена. Выбирает ли какое-либо приложение, использующее мой компонент, ИСПОЛЬЗОВАТЬ этот аспект спецификации, затем определяется предполагаемым и ожидаемым использованием вывода. Если бы он выполнялся и интерпретировался JavaScript, вы бы не дублировали имена. Но это НЕ предполагаемое и ожидаемое использование в данном случае, и поэтому мое приложение может свободно использовать ВСЕ функции моего 100% совместимого парсера. КОНЕЦ. ФИНАЛЬНЫЙ. - person Deltics; 17.11.2010
comment
Ух ты. Думаю, ты показал мне этот КОНЕЦ. ФИНАЛЬНЫЙ. вещь. Повезло тебе. Я полагаю, что сообщение json.org о том, что Javascript разбирает текст JSON, - это просто фигура речи. if (language == JavaScript) parser = false? Я полагаю, что JavaScript, который не выдает ошибок при обнаружении повторяющихся имен, не делает недействительным ваше утверждение о парсерах, потому что JavaScript никогда ничего не анализирует. Хорошая работа по переопределению. Я преклоняюсь перед мастером. Однако, если вы хотите заставить людей не соглашаться с вами, вы забыли важную фразу: КОНЕЦ. ФИНАЛЬНЫЙ. РАЗ БЕСКОНЕЧНОСТЬ. пальцы в ушах Лалала .... - person Shawn Grigson; 18.11.2010

arrow_upward
4
arrow_downward

Если я не ошибаюсь, правильный ответ на этот вопрос состоит в том, что ваш ввод - это не JSON. Так что нет, заставить парсер JSON его проанализировать, вероятно, не сработает.

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

{"TBoxes":
    [
        {
            "Name": "SmallBox",
            "Length": 1,
            "Width": 1,
            "Height": 2 
        },
        {
            "Name": "MedBox",
            "Length": 5,
            "Width": 10,
            "Height": 10 
        },
        {
            "Name": "LargeBox",
            "Length": 20,
            "Width": 20,
            "Height": 10 
        }
    ]
}

И относитесь к нему как к массиву, который есть на самом деле.

person Mike Ruhlin    schedule 06.10.2010
comment
Я попробовал Regex, и это оказалось непросто. В некоторых реальных сценариях мне придется обрабатывать объекты внутри объектов внутри объектов. Я попробовал это на всякий случай, и обработка вложенных фигурных скобок и возможных наборов символов быстро стала головной болью. Обычно я большой поклонник регулярных выражений, но в данном случае я надеялся на что-нибудь попроще. - person Ubiquitous Che; 07.10.2010
comment
Оказывается, они технически все еще отправляют действительный Json. См. Мой второй комментарий к Матфею выше. С моей стороны это раздражает, но теперь я справлюсь. - person Ubiquitous Che; 07.10.2010
comment
Нет, это действительно неправильный JSON. Вы неверно истолковываете спецификацию, которая основана на подмножестве языка программирования JavaScript, Standard ECMA-262, 3-е издание - декабрь 1999 г. Не существует парсеров JavaScript, которые сохраняли бы какое-либо значение, кроме самого последнего, связанного с несколькими повторяющимися ключами. Скажите Дугласу Крокфорду, изобретателю JSON, что он ошибается. - person Joel Mueller; 07.10.2010
comment
@ Джоэл: Неправильно. Их как минимум ДВА. Тот, который я написал, и тот, который предоставлен Newtonsoft. Тот факт, что многие синтаксические анализаторы делают одни и те же неверные предположения, не означает, что они ошибочны. Они правильно реализуют спецификацию. Вам не обязательно это нравиться, но упорствовать в том, что что-то, что соответствует спецификации, неправильно, просто глупо. То, что вы получаете, когда запускаете выполнение JS в объекте JSON, не имеет отношения к вопросу о том, что является правильной структурой JSON, особенно если структура JSON не предназначена для выполнения как JS и является просто транспортом данных. Конец. - person Deltics; 07.10.2010
comment
Я правильно интерпретирую спецификацию - это вы неправильно интерпретируете. В спецификации указано, что имена ДОЛЖНЫ быть уникальными. Если бы он предполагал, что имена ДОЛЖНЫ БЫТЬ уникальными, он бы сказал, что они ДОЛЖНЫ быть уникальными. В спецификации явно и намеренно используется термин ДОЛЖЕН, а не ДОЛЖЕН, и отсылается к RFC 2119, который определяет эти термины. Интерпретация, которая гласит СЛЕДУЕТ как ДОЛЖНА, является неправильной интерпретацией. Факт. - person Deltics; 07.10.2010
comment
@Deltics - синтаксический анализатор, который не выдает ошибку при обнаружении повторяющихся ключей, а также создает объект, содержащий только одно значение для каждого ключа, соответствует спецификации. В данном случае я говорю обо всех парсерах JSON, кроме вашего, включая Newtonsoft. Если вы хотите и дальше использовать собственное уникальное определение терминов «пары ключ-значение», продолжайте. Но не делайте вид, будто все остальные должны переписать свои парсеры, чтобы удовлетворить ваши потребности. Но не верьте мне на слово. Вот парсер Delphi JSON. Посмотрите, что он делает. goo.gl/UoKQ - person Joel Mueller; 08.10.2010
comment
Я ничего не притворяюсь. Я следую спецификации, а не воображаемому документу, который, как мне кажется, является спецификацией. пожимают плечами. - person Deltics; 08.10.2010
comment
Я не использую собственное определение пар имя-значение. ПРИМЕЧАНИЕ: * NAME ** / value, * NOT ** key ** / value. Слово ключ встречается только дважды, оба в связи с определением разницы между ДОЛЖНЫ и ДОЛЖНЫ. Вы спецификацию прочитали? Не так ли? Даже если да, очевидно, что вы используете свое собственное, очень уникальное определение слова «спецификация», где то, что говорится в спецификации, не то, что она означает. - person Deltics; 08.10.2010