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

Question 1

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

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

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

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

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

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

{
  "keyName" : 34
}

В отличие от инвалида:

{
   keyName : 34
}

Question 2

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

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

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

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

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

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

....

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

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

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

...

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

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

Question 3

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

Возьмем другой пример:

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

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

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

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

Question 4

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

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

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