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 за много добър. Наистина не искам да се забърквам с други рамки, ако мога да го избегна.

Всяка помощ ще бъде високо оценена.

Имам много ограничена информация относно промените, които могат да бъдат направени на сървъра.


person Ubiquitous Che    schedule 06.10.2010    source източник


Отговори (2)


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
@Ubiquitous, никога не съм казвал, че нарушава RFC. Но това е неинтуитивно и не съм непременно съгласен, че това е причина да го счупите. Има други проекти, които предоставят информация за типа без дублиращи се ключове. - person Matthew Flaschen; 07.10.2010
comment
В този случай бих интерпретирал ТРЯБВА като насока към JSON-parser-разработчиците, че не трябва да извеждат грешка, когато срещнат дублирани имена. Въпреки това, тъй като JS в JSON означава JavaScript и структурите от данни на JavaScript НЕ МОГАТ да имат дублиращи се имена, изглежда ми ясно, че вашите хора от Delphi нарушават духа, ако не и буквата, на спецификацията. Поведението на Newtonsoft е точно правилно, защото е същото, което би направил анализатор на JavaScript. - person Joel Mueller; 07.10.2010
comment
ха! Ще го предам. Моят аргумент беше, че начинът, по който са го направили, няма да работи за повечето парсери в дивата природа. Техният отговор беше, че това е грешката на анализаторите, че не са уважили правилно значението на SHOULD. ^_^ Благодаря за подкрепата и последващите действия, много се оценявам. - 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 представяния, СЪДЪРЖАЩИ дублирани имена. Искаш ли сос с шапката си? ROFL - person Deltics; 07.10.2010
comment
Deltics, анализаторът Newtonsoft на Джеймс Нютън-Кинг прави същото, което прави самият JavaScript - ако срещне дублирани ключове, всеки следващ дублиран ключ презаписва предишната стойност за този ключ. В крайна сметка имате един ключ с една стойност. В това следва спецификацията, която не изисква запазването на множество стойности, когато се срещнат дублиращи се ключове. Заобиколното решение на Matthew, по-горе, включва директна работа с 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 Parser с JavaScript двигателя. Това е все едно да кажете XML Parser, когато имате предвид .NET Framework във връзка с конфигурационен файл .appdata. Да, това е XML, но това, което ПРАВИТЕ С НЕГО, определя дали определена УПОТРЕБА от него е правилна. Разглеждано отделно от това какъв ТИП на документа е, дали XML е валиден или не се определя от XML спецификацията. Същото важи и тук. Създаденият JSON е валиден. Не е съвместим с ИЗПЪЛНЕНИЕТО на JavaScript, но това е ОК, защото не се използва по този начин. - 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 и прочетени/анализирани от анализатор на JSON на Delphi и/или анализатор на 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 Object Notation). Вие обаче не използвате 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 Object Notation е двусмислена по някакъв начин, разрешавате двусмислието, като погледнете какво правят анализаторите на 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, освен ако не се потопите до нивото на потока от токени, което никой не трябва да прави само за да чете вашите стойности. Във всеки случай наистина се радвам, че никога няма да се наложи да работя с теб. ОП има моите симпатии. - 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
Моето собствено повторение може да свърши работа: СПЕЦИФИКАЦИЯТА позволява дублирани имена - това може да не ви харесва, но това е прост ФАКТ. Следователно моят парсер поддържа и позволява дублирани имена. Дали някое приложение, използващо моя компонент, избира да ИЗПОЛЗВА този аспект от спецификацията, се определя от предвиденото и очаквано използване на изхода. Ако трябваше да се изпълнява и интерпретира от 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

Ако не греша, правилният отговор на това е, че вашият вход всъщност не е 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 и се оказа трудно. В някои от сценариите от реалния свят ще трябва да боравя с обекти в обекти в обекти. Изпробвах го, за да съм сигурен, и работата с вложените фигурни скоби и възможните набори от символи бързо се превърна в болка в задника. Обикновено съм голям фен на regex, но в този случай се надявах на нещо по-лесно. - person Ubiquitous Che; 07.10.2010
comment
Оказва се, че технически все още изпращат валиден Json. Вижте втория ми коментар към Матю по-горе. От моя страна е досадно, но вече мога да се справя. - person Ubiquitous Che; 07.10.2010
comment
Не, наистина не е правилен JSON. Вие тълкувате погрешно спецификацията, която се основава на подмножество от езика за програмиране на JavaScript, стандартен ECMA-262 3-то издание - декември 1999 г. Няма анализатори на JavaScript, които да запазят която и да е стойност освен последната, свързана с множество дублирани ключове. Кажете на Дъглас Крокфорд, изобретателя на JSON, че греши. - person Joel Mueller; 07.10.2010
comment
@Joel: Грешка. Има поне ДВА. Този, който написах, и този, предоставен от Newtonsoft. Това, че много анализатори правят едни и същи невалидни предположения, които правите и вие, не означава, че те са грешни. Те правилно изпълняват спецификацията. Не е нужно да ви харесва, но да упорствате с мнението, че нещо, което отговаря на спецификацията, е грешно, е просто глупаво. Това, което получавате, когато стартирате изпълнение на JS в JSON обект, не е от значение за въпроса коя е правилната JSON структура, особено ако JSON структурата не е предназначена да се изпълнява като JS и е просто транспорт на данни. Край. - person Deltics; 07.10.2010
comment
Правилно тълкувам спецификацията - вие сте този, който я тълкува неправилно. Спецификацията гласи, че имената ТРЯБВА да бъдат уникални. Ако имаше за цел имената ТРЯБВА ДА БЪДАТ уникални, тогава щеше да се каже, че те ТРЯБВА да бъдат уникални. Спецификацията ясно и съзнателно използва термина ТРЯБВА, а не ТРЯБВА, и препраща към RFC 2119, който дефинира тези термини. Тълкуване, което гласи ТРЯБВА като ТРЯБВА, е неправилно тълкуване. Факт. - person Deltics; 07.10.2010
comment
@Deltics - анализатор, който не извежда грешка, когато срещне дублиращи се ключове, и също така в крайна сметка произвежда обект, който съдържа само една стойност на ключ, следва спецификацията. В този случай говоря за всички JSON анализатори, освен вашия, включително Newtonsoft. Ако искате да продължите да използвате собствената си уникална дефиниция на термина двойки ключ-стойност, непременно давайте. Но не се преструвайте, че всички останали трябва да пренапишат анализаторите си, за да се погрижат за вас. Но не ми вярвайте на думата. Ето анализатор на JSON на Delphi. Вижте какво прави. goo.gl/UoKQ - person Joel Mueller; 08.10.2010
comment
Не се преструвам на нищо. Следвам спецификацията, а не някакъв въображаем документ, който според мен е спецификация. сви рамене. - person Deltics; 08.10.2010
comment
Не използвам моя собствена дефиниция на двойки име-стойност ЗАБЕЛЕЖКА: *ИМЕ**/стойност, *НЕ **ключ**/стойност. Думата ключ се среща само два пъти, и двете във връзка с определянето на разликата между ТРЯБВА и ТРЯБВА. Прочетохте ли спецификацията? не сте ли Дори и да имате, очевидно използвате собствената си уникална дефиниция на думата спецификация, където това, което се казва в спецификацията, не е това, което спецификацията означава. - person Deltics; 08.10.2010