Есть ли практическая причина использовать цитируемые строки для ключей JSON?

Согласно Crockford json.org, объект JSON состоит из элементов, состоящих из пар.

Каждая пара состоит из строки и значения со строкой, которая определяется как:

Строка представляет собой последовательность из нуля или более Юникодовые символы, завернутые в двойные кавычки, используя обратную косую черту. символ представлен как единый символьная строка. Строка очень как строка C или Java.

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

Есть ли смысл беспокоиться, окружая ваш JSON в двойных кавычках?

Действительный пример:

{
  "keyName" : 34
}

В отличие от недопустимого:

{
   keyName : 34
}

Ответ 1

Настоящая причина того, почему ключи JSON должны быть в кавычках, зависит от семантики идентификаторов ECMAScript 3.

Зарезервированные слова не могут использоваться как имена свойств в объектных литералах без кавычек, например:

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

Если вы используете кавычки, имена свойств действительны:

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

Собственный Крокфорд объясняет это в в этом разговоре, они хотели, чтобы стандарт JSON был простым, и они не хотели бы иметь все эти семантические ограничения на него:

....

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

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

Вот почему, по сей день, ключи цитируются в JSON.

...

Стандарт ECMAScript 5th Edition исправляет это, теперь в реализации ES5 даже зарезервированные слова могут использоваться без кавычек, как в литералах Object, так и в доступе членов (obj.function Ok в ES5).

Как раз для записи, этот стандарт в настоящее время реализуется разработчиками программного обеспечения, вы можете видеть, какие браузеры включают эту функцию в эту таблицу совместимости (см. Зарезервированные слова как имена свойств)

Ответ 2

Да, это недействительный JSON и во многих случаях будет отвергаться иначе, например jQuery 1.4+ имеет чек, который делает неупорядоченный JSON бесшумным. Почему бы не быть совместимым?

Возьмем еще один пример:

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

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

Еще один распространенный пример в мире веб-разработчиков: Есть тысячи примеров недействительных HTML, которые отображаются в большинстве браузеров... это делает его менее болезненным для отладки или поддержки? Совсем нет, совсем наоборот.

Также @Matthew делает наилучшую точку зрения в комментариях ниже, этот уже не работает, неузнанные ключи выдают синтаксическую ошибку с JSON.parse() во всех основных браузерах (и любых других, которые его реализуют правильно), вы можете протестировать его здесь.

Ответ 3

YAML, который на самом деле является надмножеством JSON, поддерживает то, что вы хотите сделать. Несмотря на то, что он является надмножеством, он позволяет вам сохранять его как можно проще.

YAML - это глоток свежего воздуха, и это может стоить вашего времени, чтобы взглянуть на него. Лучшее место для начала здесь: http://en.wikipedia.org/wiki/YAML

Существуют ливы для каждого языка под солнцем, включая JS, например https://github.com/nodeca/js-yaml