w formacie JSON, dlaczego każda nazwa jest cytowana?

Specyfikacja JSON mówi, że JSON jest obiektem lub tablicą. W przypadku przedmiotu,

Struktura obiektu jest reprezentowana jako para nawiasów klamrowych otaczających zero lub więcej par nazwa / wartość (lub członków). Nazwa to ciąg. ...

A później specyfikacja mówi, że ciąg jest ujęty w cudzysłów.

Czemu?

A zatem,

{"Property1":"Value1","Property2":18}

i nie

{Property1:"Value1",Property2:18}

Pytanie 1 : dlaczego nie pozwolić, aby nazwa w parach nazwa / wartość była identyfikatorami niecytowanymi?

Pytanie 2 : Czy istnieje różnica semantyczna między dwiema powyższymi reprezentacjami, gdy ocenia się je w JavaScript?

Pytanie 1: dlaczego nie pozwolić, aby nazwa w parach nazwa / wartość była identyfikatorami niecytowanymi?

Filozofia projektowania JSON to „Keep it simple”

„Cytuje nazwy z "” jest dużo prostsze niż „Można przytoczyć nazwiska z "albo ', ale nie muszą, jeżeli nie zawiera niektórych znaków (lub zestawy znaków, które sprawiają, że kluczowe) i 'czy "może muszą być notowane w zależności od wybranego separatora ” .

Pytanie 2: Czy istnieje różnica semantyczna między dwiema powyższymi reprezentacjami, gdy ocenia się je w JavaScript?

Nie. W JavaScript są identyczne.

Zostawiam cytat z prezentacji, którą Douglas Crockford (twórca standardu JSON) przekazał Yahoo.

Opowiada o tym, jak odkrył JSON i między innymi, dlaczego zdecydował się użyć cudzysłowów :

.... Wtedy odkryliśmy problem z nazwami bez cytatów. Okazuje się, że ECMA Script 3 ma politykę dotyczącą słów zastrzeżonych. Zastrzeżone słowa należy cytować w pozycji kluczowej, co jest naprawdę uciążliwe. Kiedy doszedłem do sformułowania tego w standardzie, nie chciałem umieszczać wszystkich zastrzeżonych słów w standardzie, ponieważ wyglądałoby to naprawdę głupio.

W tamtym czasie starałem się przekonać ludzi: tak, możesz pisać aplikacje w JavaScript, to naprawdę zadziała i to jest dobry język. Nie chciałem więc jednocześnie powiedzieć: i spójrz na tę naprawdę głupią rzecz, którą zrobili! Postanowiłem więc zamiast tego zacytować klucze.
W ten sposób nie musimy nikomu mówić o tym, jak to jest.

Dlatego do dziś klucze są cytowane w formacie JSON.

Możesz znaleźć cały film i transkrypcję tutaj .

:W identyfikatorach dozwolone są zarówno znaki, jak i spacje. Bez cudzysłowów spowodowałoby to niejednoznaczność przy próbie ustalenia, co dokładnie stanowi identyfikator.

W javascript obiekty mogą być używane jak hash / hashtable z parami kluczy.

Jeśli jednak twój klucz zawiera znaki, których javascript nie może tokenizować jako nazwy, próba uzyskania dostępu nie powiedzie się, jak właściwość obiektu, a nie klucz.

var test  = {};
test["key"] = 1;
test["#my-div"] = "<div> stuff </div>";

// test = { "key": 1, "#my-div": "<div> stuff </div>" };

console.log(test.key);           // should be 1
console.log(test["key"]);        // should be 1
console.log(test["#my-div"]);    // should be "<div> stuff </div>";
console.log(test.#my-div);       // would not work.

Identyfikatory mogą czasami zawierać znaki, których nie można ocenić jako token / identyfikator w javascript, dlatego najlepiej jest umieścić wszystkie identyfikatory w ciągach, aby zachować spójność.

Myślę, że właściwą odpowiedzią na pytanie Cheeso jest to, że implementacja przerosła dokumentację. Nie wymaga już łańcucha jako klucza, ale raczej coś innego, co może być ciągiem znaków (tj. W cudzysłowie) lub (prawdopodobnie) czymkolwiek, co może być użyte jako nazwa zmiennej, co, jak sądzę, oznacza rozpoczęcie od litery, _ lub $ i zawierają tylko litery, cyfry oraz znaki $ i _.

Resztę chciałem uprościć następnej osobie, która zadaje to pytanie z tym samym pomysłem, co ja. Oto mięso:

Nazwy zmiennych nie są interpolowane w formacie JSON, gdy są używane jako klucz obiektu (dzięki Friedo!)

Breton, używając „identyfikatora” zamiast „klucza”, napisał, że „jeśli okaże się, że identyfikator jest słowem zastrzeżonym, jest on interpretowany jako to słowo, a nie jako identyfikator”. Może to prawda, ale próbowałem bez problemu:

var a = {do:1,long:2,super:3,abstract:4,var:5,break:6,boolean:7};
a.break

=> 6

O używaniu cudzysłowów Quentin napisał „... ale nie musisz tego robić, chyba że [klucz] zawiera określone znaki (lub kombinacje znaków, które uczyniłyby z niego słowo kluczowe)”

Okazało się, że pierwsza część (niektóre znaki) jest prawdą, używając znaku @ (w rzeczywistości myślę, że $ i _ to jedyne znaki, które nie powodują błędu):

var a = {a@b:1};

=> Błąd składni

var a = {"a@b":1};
a['a@b']

=> 1

ale nawias dotyczący słów kluczowych, jak pokazałem powyżej, nie jest prawdziwy.

To, co chciałem, działa, ponieważ tekst między początkiem {a dwukropkiem lub między przecinkiem a dwukropkiem dla kolejnych właściwości jest używany jako niecytowany ciąg do utworzenia klucza obiektu lub, jak ujął to Friedo, nazwa zmiennej nie robi t zostanie interpolowany:

var uid = getUID();
var token = getToken();            // Returns ABC123
var data = {uid:uid,token:token};
data.token

=> ABC123

Jeśli json opisuje obiekty, w praktyce otrzymujesz:

var foo = {};

var bar = 1;

foo["bar"] = "hello";
foo[bar] = "goodbye";

więc wtedy,

foo.bar == "hello";
foo[1] == "goodbye" // in setting it used the value of var bar

więc nawet jeśli twoje przykłady dadzą ten sam wynik, ich odpowiedniki w „surowym kodzie” nie. Może to dlatego?? nie wiem, tylko pomysł.

Może to zmniejszyć rozmiar danych, jeśli cudzysłowy w nazwie są dozwolone tylko wtedy, gdy jest to konieczne