Czy klucze JSON muszą być otoczone cudzysłowami?


235

Przykład: czy następujący kod jest poprawny w stosunku do zgodny ze specyfikacją JSON ?

{
    precision: "zip"
}

Czy powinienem zawsze używać następującej składni? (A jeśli tak, to dlaczego?)

{
    "precision": "zip"
}

Tak naprawdę nie znalazłem czegoś na ten temat w specyfikacjach JSON. Chociaż w swoich przykładach używają cudzysłowów wokół swoich kluczy.

Odpowiedzi:


147

Tak, potrzebujesz cudzysłowów. Ma to na celu uproszczenie i uniknięcie konieczności stosowania innej metody zmiany znaczenia dla słów kluczowych zarezerwowanych w javascript, tj {for:"foo"}.


12
Cytaty nie są prostsze w wielu sytuacjach, takich jak pliki konfiguracyjne edytowane ręcznie. Niefortunne jest to, że JSON jest używany (i niewłaściwie używany) jako prawie uniwersalny format wymiany, ponieważ ma funkcje specyficzne dla Javascript.
— Miguel

12
Prawdziwy powód - sprawdź również tę odpowiedź - stackoverflow.com/questions/4201441/…
— TechMaze

3
Tl; dr: nie chcieli zajmować się ograniczeniem ECMAScript dla (niecytowanych) zarezerwowanych słów kluczowych jako kluczy, więc po prostu wymagali cytowania wszystkich kluczy.
— BallpointBen,

136

Poprawne jest używanie ciągów jako klucza. Oto fragment RFC 4627 - Aplikacja / json Media Type dla JavaScript Object Notation (JSON)

2.2 Obiekty

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 znaków . Po każdej nazwie występuje pojedynczy dwukropek, oddzielający nazwę od wartości. Pojedynczy przecinek oddziela wartość od następującej nazwy. Nazwy w obiekcie POWINNY być unikalne.

object = begin-object [ member *( value-separator member ) ] end-object

member = string name-separator value

[...]

2.5 Smyczki

Reprezentacja ciągów znaków jest podobna do konwencji używanych w rodzinie języków programowania C. Ciąg zaczyna się i kończy znakiem cudzysłowu. [...]

string = quotation-mark *char quotation-mark

quotation-mark = %x22 ; "

Przeczytaj cały RFC tutaj .


11
I dokończyć myśl, sekcja 2.5 mówi: A string begins and ends with quotation marks..
— rakslice,

13

Od 2.2. Obiekty

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 znaków.

i od 2.5. Smyczki

Ciąg zaczyna się i kończy znakiem cudzysłowu.

Powiedziałbym więc, że zgodnie ze standardem: tak, zawsze powinieneś cytować klucz (chociaż niektóre parsery mogą być bardziej wybaczające)



0

Tak, robią. Ale jeśli potrzebujesz inaczej, sprawdź JSON5 .

JSON5 to nadzbiór JSON, który umożliwia składnię ES5, w tym:

  • niecytowane klucze własności
  • ciągi cudzysłowu, znaki specjalne i wieloliniowe
  • alternatywne formaty liczb
  • komentarze
  • dodatkowe białe znaki

Implementacja referencyjna JSON5 ( json5pakiet npm ) zapewnia JSON5obiekt, który ma parsei stringifymetody z tymi samymi argumentami i semantyką jak obiekt wbudowany JSON.


-2

Ponieważ możesz umieścić kropkowaną notację „parent.child” i nie musisz umieszczać nadrzędnej [„child”], która jest również ważna i przydatna, powiedziałbym, że obie metody są technicznie dopuszczalne. Wszystkie parsery powinny działać w obie strony w porządku. Jeśli twój parser nie potrzebuje cudzysłowów na klawiszach, prawdopodobnie lepiej nie wstawiać ich (oszczędza miejsce). Sensowne jest nazywanie ich ciągami, ponieważ takie są, a ponieważ nawiasy kwadratowe dają możliwość używania wartości dla kluczy, w zasadzie nie ma sensu. W Json możesz umieścić ...

>var keyName = "someKey";
>var obj = {[keyName]:"someValue"};

>obj
Object {someKey: "someValue"}

w porządku bez problemów, jeśli potrzebujesz wartości dla klucza i żaden cytowany nie będzie działał, więc jeśli nie, nie możesz, więc nie będziesz tak „nie potrzebował cudzysłowów na kluczach”. Nawet jeśli słusznie jest powiedzieć, że są technicznie sznurkami. Logika i użycie argumentują inaczej. Oficjalnie nie wypisuje też obiektu {"someKey": "someValue"} dla obj w naszym przykładzie z konsoli dowolnej przeglądarki.


2
Zarówno zaakceptowana odpowiedź, jak i RFC, które definiują JSON, mówią, że cytaty są wymagane.
— Keith Thompson

To prawda, ale warto zauważyć, że logicznie nie musi. Podejrzewam, że wynik JavaScript Object Notation ze wszystkich konsoli przeglądarki jest nieprawidłowy i powinniśmy powiedzieć komuś, żeby to naprawił. Może to, co konsola przeglądarki wyświetla dla obiektu, nie jest JSON, więc może JSON, jak określa specyfikacja, nie jest potrzebny ani implementowany w ten sposób w większości miejsc. W każdym razie chciałem po prostu przedstawić sprawę, która patrzy na fakty w innym świetle. Naprawdę, może specyfikacja powinna zostać zmieniona, „Cytowane klucze” nie są po prostu potrzebne nigdzie, co jest dla mnie ważne. (Po prostu nie stosuje się go w praktyce).
— Mistrz James

2
Mieszasz trzy różne rzeczy: JSON, literały obiektów JavaScript i dane wyjściowe konsoli narzędzi programistycznych przeglądarki. Podczas pisania objw konsoli przeglądarka wyświetla czytelną dla człowieka reprezentację obiektu. Może wyświetlać go jako dosłowny obiekt (tak jak w twoim przykładzie) lub może użyć innej reprezentacji, nawet interaktywnej. Literały obiektów JavaScript nie wymagają cudzysłowów wokół nazwy klucza, jeśli klucz jest prawidłowym identyfikatorem, a nie słowem zastrzeżonym. Jednak JSON zawsze wymaga cudzysłowów wokół nazw kluczy.
— Michael Geary,

3
Jako dalsze przykłady, zamiast pisać objw konsoli, spróbuj JSON.stringify(obj). Teraz zobaczysz prawidłową reprezentację JSON obiektu wraz z cytowaną nazwą klucza. I odwrotnie, aby sprawdzić, czy łańcuch jest prawidłowy JSON, spróbuj JSON.parse(string). Jeśli klucze nie zostaną podane, spowoduje to wyjątek. Na przykład JSON.parse('{"a":"b"}')odniesie sukces, ale JSON.parse('{a:"b"}')zakończy się niepowodzeniem.
— Michael Geary,

1
OTOH, twoje użycie var obj = {[keyName]:"someValue"};jest bardzo interesujące! Nie wiedziałem, że możesz to zrobić w dosłownym obiekcie JavaScript. Trochę sprawdzania pokazuje, że jest to coś nowego w ES6 - nie można tego zrobić w ES5.
— Michael Geary,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.