в JSON, почему каждое имя цитируется?

Question

Спецификация JSON говорит, что JSON является объектом или массивом. В случае объекта,

Структура объекта представлена ​​в виде пары фигурных скобок окружающий ноль или более пар имя / значение (или членов). Имя это строка. ...

А позже в спецификации говорится, что строка заключена в кавычки.

Почему?

Таким образом,

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

а не

{Property1:"Value1",Property2:18}

Вопрос 1 : почему бы не разрешить использование имени в парах имя / значение без кавычек?

---

Вопрос 2 : Есть ли семантическая разница между двумя представленными выше представлениями при оценке в JavaScript?

Answer 1

Я оставляю цитату из презентации, которую Дуглас Крокфорд (создатель стандарта JSON) дал Yahoo.

Он рассказывает о том, как он обнаружил JSON, и среди прочего, почему он решил использовать цитируемые ключи :

.... Это было, когда мы обнаружили проблема без кавычек. Оказывается ECMA Script 3 имеет зарезервированный удар политика слова. Зарезервированные слова должны быть цитируется в ключевой позиции, которая действительно неприятность. Когда я обошел чтобы сформулировать это в стандарт, я не хотел ставить все зарезервированные слова в стандарте, потому что это выглядело бы действительно глупо.

В то время я пытался убедить люди: да, вы можете написать приложения в JavaScript, это на самом деле собирается работать, и это хорошо язык. Я не хотел тогда говорить, в то же время: и посмотрите на это действительно глупая вещь, которую они сделали! Так что я решил вместо этого просто процитировать ключи.
Таким образом, нам не нужно говорить Кто-нибудь о том, как это больно.

Вот почему по сей день ключи указаны в JSON.

Вы можете найти полное видео и стенограмму здесь .

Answer 2

Вопрос 1: почему нельзя допустить, чтобы имя в парах имя / значение было идентификаторами без кавычек?

Философия дизайна JSON: «Не усложняйте»

"Цитировать имена с "" намного проще, чем "Вы можете заключать в кавычки имена с " или ', но это не обязательно, если они не содержат определенных символы (или комбинации символов, которые делают его ключевым словом) и ' или " могут заключаться в кавычки в зависимости от выбранного разделителя ".

Вопрос 2: Есть ли семантическая разница между двумя представленными выше представлениями при оценке в Javascript?

Нет. В JavaScript они идентичны.

Answer 3

Это может уменьшить размер данных, если кавычки на имя допускаются только при необходимости

Answer 4

Я думаю, что правильный ответ на вопрос Чизо состоит в том, что реализация превзошла документацию. Для него больше не требуется строка в качестве ключа, а скорее что-то еще, что может быть либо строкой (т. Е. Заключенной в кавычки), либо (возможно) всем, что может быть использовано в качестве имени переменной, что, как я предполагаю, означает начинаться с буквы, _ или $ и включают только буквы, цифры, а также $ и _.

Я хотел упростить остальное для следующего человека, который посещает этот вопрос с той же идеей, что и я. Вот мясо:

Имена переменных не интерполируются в JSON при использовании в качестве ключа объекта (Спасибо, Фридо!)

Бретон, используя «идентификатор» вместо «ключ», писал, что «если идентификатор оказывается зарезервированным словом, он интерпретируется как это слово, а не как идентификатор». Это может быть правдой, но я попробовал без проблем:

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

=> 6

Об использовании кавычек Квентин писал: "... но вам не нужно, если [ключ] не содержит определенных символов (или комбинаций символов, которые делают его ключевым словом)"

Я обнаружил, что предыдущая часть (определенные символы) верна, используя знак @ (на самом деле, я думаю, что $ и _ являются единственными символами, которые не вызывают ошибку):

var a = {a@b:1};

=> Синтаксическая ошибка

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

=> 1

но скобки в отношении ключевых слов, как я показал выше, не соответствуют действительности.

То, что я хотел, работает, потому что текст между открывающим {и двоеточием, или между запятой и двоеточием для последующих свойств используется в качестве строки без кавычек для создания ключа объекта или, как выразился Фридо, имени переменной не интерполируется:

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

=> ABC123

Answer 5

В javascript объекты могут использоваться как хеш / хеш-таблица с парами ключей.

Однако, если в вашем ключе есть символы, которые javascript не может пометить токеном как имя, произойдет сбой при попытке доступа к нему как к свойству объекта, а не как к ключу.

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.

идентификаторы могут иногда иметь символы, которые не могут быть оценены как токен / идентификатор в javascript, поэтому лучше всего поместить все идентификаторы в строки для согласованности.

Answer 6

Если json описывает объекты, то на практике вы получаете следующее

var foo = {};

var bar = 1;

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

Итак,

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

так что даже если ваши примеры дают одинаковый результат, их эквиваленты в «сыром коде» не будут. Может быть поэтому ?? не знаю, просто идея.

Answer 7

И :, и пробел допускаются в идентификаторах. Без кавычек это может привести к неоднозначности при попытке определить, что именно представляет собой идентификатор.