La sintassi JSON consente chiavi duplicate in un oggetto?

Questo json è valido?

{
    "a" : "x",
    "a" : "y"
}

http://jsonlint.com/ dice sì.

http://www.json.org/ non dice nulla in merito al fatto che è proibito.

Ma ovviamente non ha molto senso, vero? La maggior parte delle implementazioni utilizza probabilmente una tabella hash, quindi viene comunque ignorata.

Dallo standard (p. Ii) :

Si prevede che altri standard faranno riferimento a questo, aderendo rigorosamente al formato di testo JSON, imponendo al contempo restrizioni su vari dettagli di codifica. Tali standard possono richiedere comportamenti specifici. JSON stesso non specifica alcun comportamento.

Più in basso nello standard (p. 2), la specifica per un oggetto JSON:

Una struttura di oggetti è rappresentata come una coppia di token parentesi graffa che circonda zero o più coppie nome / valore. Un nome è una stringa. Un singolo token di due punti segue ogni nome, separando il nome dal valore. Un singolo token virgola separa un valore dal seguente nome.

Non fa alcuna menzione del fatto che le chiavi duplicate non siano valide o valide, quindi in base alle specifiche presumo che significhi che sono consentite.

Il fatto che la maggior parte delle implementazioni delle librerie JSON non accetta chiavi duplicate non è in conflitto con lo standard, a causa della prima citazione.

Ecco due esempi relativi alla libreria standard C ++. Quando si deserializza un oggetto JSON in un std::mapsenso, avrebbe senso rifiutare chiavi duplicate. Ma quando si deserializza un oggetto JSON in un std::multimapsenso, avrebbe senso accettare chiavi duplicate normalmente.

La risposta breve: Sì, ma non è raccomandato.
La risposta lunga: dipende da ciò che chiami valido ...

ECMA-404 "La sintassi di interscambio dati JSON" non dice nulla sui nomi duplicati (chiavi).

Tuttavia, RFC 8259 "Il formato di interscambio di dati JSON (JavaScript Object Notation)" dice:

I nomi all'interno di un oggetto DOVREBBERO essere univoci.

In questo contesto DOVREBBE essere compreso come specificato nel BCP 14 :

DOVREBBE Questa parola, o l'aggettivo "RACCOMANDATO", significa che possono esistere ragioni valide in circostanze particolari per ignorare un elemento particolare, ma le implicazioni complete devono essere comprese e ponderate attentamente prima di scegliere un corso diverso.

RFC 8259 spiega perché i nomi univoci (chiavi) sono buoni:

Un oggetto i cui nomi sono tutti univoci è interoperabile, nel senso che tutte le implementazioni software che ricevono quell'oggetto saranno d'accordo sulle mappature nome-valore. Quando i nomi all'interno di un oggetto non sono univoci, il comportamento del software che riceve tale oggetto è imprevedibile. Molte implementazioni riportano solo la coppia cognome / valore. Altre implementazioni riportano un errore o non riescono ad analizzare l'oggetto e alcune implementazioni riportano tutte le coppie nome / valore, inclusi i duplicati.

Inoltre, come sottolineato da Serguei nei commenti: ECMA-262 "ECMAScript® Language Specification", recita:

Nel caso in cui vi siano stringhe di nomi duplicati all'interno di un oggetto, i valori che precedono lessicamente per la stessa chiave devono essere sovrascritti.

In altre parole, vince l'ultimo valore.

Cercare di analizzare una stringa con nomi duplicati con l' implementazione Java di Douglas Crockford (il creatore di JSON) genera un'eccezione :

org.json.JSONException: Duplicate key "status"  at
org.json.JSONObject.putOnce(JSONObject.java:1076)

Esistono 2 documenti che specificano il formato JSON:

1. http://json.org/
2. https://tools.ietf.org/html/rfc7159

La risposta accettata cita dal 1o documento. Penso che il primo documento sia più chiaro, ma il secondo contiene più dettagli.

Il secondo documento dice:

4. Oggetti

   Una struttura di oggetti è rappresentata come una coppia di parentesi graffe che circondano zero o più coppie nome / valore (o membri). Un nome è una stringa. Un singolo punto viene dopo ogni nome, separando il nome dal valore. Una singola virgola separa un valore dal seguente nome. I nomi all'interno di un oggetto DOVREBBERO essere univoci.

Quindi non è vietato avere un nome duplicato, ma è scoraggiato.

Mi sono imbattuto in una domanda simile quando ho a che fare con un'API che accetta sia XML che JSON, ma non documenta come gestirà quelle che ci si aspetterebbe fossero chiavi duplicate nell'accettazione JSON.

Di seguito è riportata una rappresentazione XML valida del JSON di esempio:

<object>
  <a>x</a>
  <a>y</a>
</object>

Quando questo viene convertito in JSON, si ottiene quanto segue:

{
  "object": {
    "a": [
      "x",
      "y"
    ]
  }
}

Una mappatura naturale da una lingua che gestisce quelle che potresti chiamare chiavi duplicate a un'altra, può servire come potenziale riferimento alle migliori pratiche qui.

Spero che aiuti qualcuno!

Le specifiche JSON dicono questo:

Un oggetto è un insieme non ordinato di coppie nome / valore.

La parte importante qui è "non ordinata": implica l'unicità delle chiavi, perché l'unica cosa che puoi usare per fare riferimento a una coppia specifica è la sua chiave.

Inoltre, la maggior parte delle librerie JSON deserializza gli oggetti JSON in mappe / dizionari hash, dove le chiavi sono garantite uniche. Cosa succede quando si deserializza un oggetto JSON con chiavi duplicate dipende dalla libreria: nella maggior parte dei casi, si riceverà un errore o verrà preso in considerazione solo l'ultimo valore per ogni chiave duplicata.

Ad esempio, in Python, json.loads('{"a": 1, "a": 2}')restituisce {"a": 2}.

DOVREBBE essere unico non significa che DEVE essere unico. Tuttavia, come affermato, alcuni parser fallirebbero e altri userebbero solo l'ultimo valore analizzato. Tuttavia, se le specifiche sono state ripulite un po 'per consentire i duplicati, allora potrei vedere un uso in cui potresti avere un gestore di eventi che sta trasformando il JSON in HTML o in qualche altro formato ... in questi casi sarebbe perfettamente valido per analizzare JSON e creare un altro formato di documento ...

[
  "div":
  {
    "p":"hello",
    "p":"universe"
  }
  "div":
  {
    "h1":"Heading 1",
    "p":"another paragraph"
  }
]

potrebbe quindi analizzare facilmente HTML, ad esempio

<body>
 <div>
  <p>hello</p>
  <p>universe</p>
 </div>
 <div>
  <h1>Heading 1</h1>
  <p>another paragraph</p>
 </div>
</body>

Riesco a vedere il ragionamento alla base della domanda ma così com'è ... Non mi fiderei.

Chiedere uno scopo, ci sono diverse risposte:

Utilizzando JSON per serializzare gli oggetti (JavaScriptObjectNotation), ciascun elemento del dizionario viene mappato su una proprietà dell'oggetto individuale, quindi le diverse voci che definiscono un valore per la stessa proprietà non hanno alcun significato.

Tuttavia, mi è venuta la stessa domanda da un caso d'uso molto specifico: scrivendo campioni JSON per i test API, mi chiedevo come aggiungere commenti nel nostro file JSON senza interrompere l'usabilità. Le specifiche JSON non conoscono i commenti, quindi ho trovato un approccio molto semplice:

Per utilizzare chiavi duplicate per commentare i nostri esempi JSON . Esempio:

{ "property1" : "value1", "REMARK" : "... prop1 controls ...", "property2" : "value2", "REMARK" : "... value2 raises an exception ...", }

I serializzatori JSON che stiamo utilizzando non hanno problemi con questi duplicati "REMARK" e il nostro codice dell'applicazione ignora semplicemente questo piccolo sovraccarico.

Pertanto, anche se non esiste alcun significato a livello di applicazione, questi duplicati forniscono per noi una soluzione alternativa utile per aggiungere commenti ai nostri campioni di test senza compromettere l'usabilità di JSON.

Pubblicare e rispondere perché ci sono molte idee obsolete e confusione sugli standard. A dicembre 2017, ci sono due standard concorrenti:

RFC 8259 - https://tools.ietf.org/html/rfc8259

ECMA-404 - http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

json.org suggerisce che ECMA-404 è lo standard, ma questo sito non sembra essere un'autorità. Mentre penso che sia giusto considerare ECMA l'autorità, ciò che è importante qui è, l'unica differenza tra le norme (in materia di chiavi univoche) è che RFC 8259 dice che le chiavi dovrebbero essere unico, e l'ECMA-404 dice che sono non sono necessari per essere unico.

RFC-8259:

"I nomi all'interno di un oggetto DOVREBBERO essere univoci."

La parola "dovrebbe" in maiuscolo, ha un significato all'interno del mondo RFC, che è specificamente definito in un altro standard (BCP 14, RFC 2119 - https://tools.ietf.org/html/rfc2119 ) come,

3. DOVREBBE Questa parola, o l'aggettivo "RACCOMANDATO", significa che possono esistere ragioni valide in circostanze particolari per ignorare un particolare elemento, ma le implicazioni complete devono essere comprese e ponderate attentamente prima di scegliere un corso diverso.

ECMA-404:

"La sintassi JSON non impone alcuna restrizione alle stringhe utilizzate come nomi, non richiede che le stringhe di nomi siano univoche e non assegna alcun significato all'ordinamento delle coppie nome / valore."

Quindi, indipendentemente da come lo tagli, è JSON sintatticamente valido .

Il motivo fornito per la raccomandazione chiave unica in RFC 8259 è,

Un oggetto i cui nomi sono tutti univoci è interoperabile, nel senso che tutte le implementazioni software che ricevono quell'oggetto saranno d'accordo sulle mappature nome-valore. Quando i nomi all'interno di un oggetto non sono univoci, il comportamento del software che riceve tale oggetto è imprevedibile. Molte implementazioni riportano solo la coppia cognome / valore. Altre implementazioni riportano un errore o non riescono ad analizzare l'oggetto e alcune implementazioni riportano tutte le coppie nome / valore, inclusi i duplicati.

In altre parole, dal punto di vista di RFC 8259, è valido ma il tuo parser potrebbe fallire e non ci sono promesse su quale valore, se presente, verrà associato a quella chiave. Dal punto di vista dell'ECMA-404 (che prenderei personalmente come autorità), è valido, punto. Per me questo significa che qualsiasi parser che rifiuta di analizzarlo è rotto. Dovrebbe almeno analizzare secondo entrambi questi standard. Ma il modo in cui viene trasformato nel tuo oggetto nativo di scelta è, in ogni caso, chiavi uniche o no, completamente dipendente dall'ambiente e dalla situazione, e nulla di tutto ciò è nello standard per cominciare.

Non è definito nello standard ECMA JSON . E in generale, una mancanza di definizione in modo standard significa "Non contare su questo lavoro allo stesso modo ovunque".

Se sei un giocatore d'azzardo, "molti" motori JSON consentiranno la duplicazione e utilizzeranno semplicemente l'ultimo valore specificato. Questo:

var o = {"a": 1, "b": 2, "a": 3}

Diventa questo:

Object {a: 3, b: 2}

Ma se non sei un giocatore d'azzardo, non contare su di esso!

Lo standard dice questo:

I linguaggi di programmazione variano ampiamente a seconda che supportino gli oggetti e, in tal caso, quali caratteristiche e vincoli offrono gli oggetti. I modelli dei sistemi di oggetti possono essere selvaggiamente divergenti e continuano a evolversi. JSON fornisce invece una semplice notazione per esprimere raccolte di coppie nome / valore. La maggior parte dei linguaggi di programmazione avrà alcune funzionalità per rappresentare tali raccolte, che possono andare con nomi come record, struct, dict, map, hash o object.

Il bug è almeno in node.js. Questo codice ha esito positivo in node.js.

try {
     var json = {"name":"n","name":"v"};
     console.log(json); // outputs { name: 'v' }
} catch (e) {
     console.log(e);
}

Secondo RFC-7159, l'attuale standard per JSON pubblicato da Internet Engineering Task Force (IETF), afferma "I nomi all'interno di un oggetto DOVREBBERO essere univoci". Tuttavia, secondo RFC-2119 che definisce la terminologia utilizzata nei documenti IETF, la parola "dovrebbe" in effetti significa "... possono esistere ragioni valide in circostanze particolari per ignorare un elemento particolare, ma le implicazioni complete devono essere comprese e attentamente valutato prima di scegliere un corso diverso ". Ciò significa essenzialmente che, sebbene si consigliano chiavi univoche, non è un must. Possiamo avere chiavi duplicate in un oggetto JSON e sarebbe comunque valido.

Dall'applicazione pratica, ho visto che il valore dell'ultima chiave viene considerato quando vengono trovate chiavi duplicate in un JSON.

In C # se si deserializza a a Dictionary<string, string>, prende l'ultima coppia di valori chiave:

string json = @"{""a"": ""x"", ""a"": ""y""}";
var d = JsonConvert.DeserializeObject<Dictionary<string, string>>(json);
// { "a" : "y" }

se provi a deserializzare

class Foo
{
    [JsonProperty("a")]
    public string Bar { get; set; }

    [JsonProperty("a")]
    public string Baz { get; set; }
}

var f = JsonConvert.DeserializeObject<Foo>(json);

ottieni Newtonsoft.Json.JsonSerializationExceptionun'eccezione.