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

Question

Согласно json.org Крокфорда, объект JSON состоит из членов , который состоит из пар .

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

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

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

Имеет ли смысл заморачивать ваш JSON двойными кавычками?

Допустимый пример:

{
  "keyName" : 34
}

В отличие от недействительного:

{
   keyName : 34
}

Answer 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 5-е издание исправляет это, теперь в реализации ES5 даже зарезервированные слова могут использоваться без кавычек как в литералах объектов, так и в доступе к элементам (obj.function Хорошо в ES5).

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

Answer 2

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

Давайте рассмотрим другой пример:

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

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

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

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

Answer 3

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

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

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