C'è qualche ragione pratica per usare stringhe tra virgolette per chiavi JSON?

Secondo json.org di Crockford , un oggetto JSON è composto da membri , che si compongono di coppie .

Ogni coppia è composta da una stringa e un valore , con una stringa definita come:

Una stringa è una sequenza di zero o più caratteri Unicode, racchiusi tra virgolette doppie, utilizzando caratteri di escape backslash. Un carattere è rappresentato come una singola stringa di caratteri. Una stringa è molto simile a una stringa C o Java.

Ma in pratica la maggior parte dei programmatori non sa nemmeno che una chiave JSON dovrebbe essere racchiusa tra virgolette doppie, perché la maggior parte dei browser non richiede l'uso di virgolette doppie.

Ha senso preoccuparsi di racchiudere il tuo JSON tra virgolette doppie?

Esempio valido:

{
  "keyName" : 34
}

Al contrario dell'invalido:

{
   keyName : 34
}

Il vero motivo per cui le chiavi JSON dovrebbero essere tra virgolette, si basa sulla semantica degli identificatori di ECMAScript 3.

Le parole riservate non possono essere utilizzate come nomi di proprietà negli oggetti letterali senza virgolette, ad esempio:

({function: 0}) // SyntaxError
({if: 0}) // SyntaxError
({true: 0}) // SyntaxError
// etc...

Mentre se usi le virgolette i nomi delle proprietà sono validi:

({"function": 0}) // Ok
({"if": 0}) // Ok
({"true": 0}) // Ok

Il proprio Crockford lo spiega in questo discorso , volevano mantenere semplice lo standard JSON e non vorrebbero avere tutte quelle restrizioni semantiche su di esso:

....

Fu allora che scoprimmo il problema del nome non quotato. Si scopre che ECMA Script 3 ha una politica di parole riservate whack. Le parole riservate devono essere citate nella posizione chiave, il che è davvero un fastidio. Quando sono arrivato a formularlo in uno standard, non volevo mettere tutte le parole riservate nello standard, perché sarebbe sembrato davvero stupido.

A quel tempo, stavo cercando di convincere le persone: sì, puoi scrivere applicazioni in JavaScript, in realtà funzionerà ed è un buon linguaggio. Non volevo dire, quindi, allo stesso tempo: e guarda questa cosa davvero stupida che hanno fatto! Quindi ho deciso, invece, di citare solo le chiavi.
In questo modo, non dobbiamo dire a nessuno di quanto sia schifoso.

Ecco perché, fino ad oggi, le chiavi sono quotate in JSON.

...

Lo standard ECMAScript 5a edizione risolve questo problema, ora in un'implementazione ES5, anche le parole riservate possono essere utilizzate senza virgolette, sia nei letterali oggetto che nell'accesso ai membri ( obj.functionOk in ES5).

Solo per la cronaca, questo standard viene implementato in questi giorni dai fornitori di software, puoi vedere quali browser includono questa funzione in questa tabella di compatibilità (vedi Parole riservate come nomi di proprietà )

Sì, è un JSON non valido e verrà rifiutato altrimenti in molti casi, ad esempio jQuery 1.4+ ha un controllo che fa fallire silenziosamente JSON non quotato. Perché non essere conforme?

Facciamo un altro esempio:

{ myKey: "value" }
{ my-Key: "value" }
{ my-Key[]: "value" }

... tutti questi sarebbero validi con virgolette, perché non essere coerenti e utilizzarli in tutti i casi, eliminando la possibilità di un problema?

Un altro esempio comune nel mondo degli sviluppatori web: ci sono migliaia di esempi di HTML non valido che viene visualizzato nella maggior parte dei browser ... questo rende meno doloroso il debug o la manutenzione? Niente affatto, al contrario.

Anche @ Matthew fa il punto migliore di tutti nei commenti qui sotto, questo già fallisce, i tasti non quotati genereranno un errore di sintassi JSON.parse()in tutti i principali browser (e in tutti gli altri che lo implementano correttamente), puoi testarlo qui .

YAML, che in realtà è un superset di JSON, supporta ciò che vuoi fare. Sebbene sia un superset, ti consente di mantenerlo semplice come desideri.

YAML è una boccata d'aria fresca e potrebbe valere la pena di dare un'occhiata. Il posto migliore per iniziare è qui: http://en.wikipedia.org/wiki/YAML

Ci sono librerie per ogni lingua sotto il sole, incluso JS, ad esempio https://github.com/nodeca/js-yaml