Czy w JSON można używać komentarzy?

7603

Czy mogę używać komentarzy w pliku JSON? Jeśli tak to jak?

Michael Gundlach
źródło
153
@StingyJack: Aby wyjaśnić rzeczy, które mogą nie być oczywiste lub cokolwiek innego, co można zrobić z komentarzami. Na przykład często mam komentarze w plikach danych. XML, pliki ini i wiele innych formatów zawiera postanowienia dotyczące komentarzy.
Michael Burr
24
Jeśli, podobnie jak ja, zastanawiasz się, czy //commentsjest OK dla konkretnego przypadku użycia pliku konfiguracyjnego Sublime Text, odpowiedź brzmi tak (od wersji 2). Sublime Text przynajmniej nie będzie na to narzekał, podczas gdy narzeka {"__comment": ...}w konsoli, ponieważ jest to nieoczekiwane pole.
driftcatcher
8
i być może jest to jeden z powodów, dla których powstał TOML.
Alex Nolasco
10
Nieco noobish, ale próbowałem też użyć // do komentarzy w JSON. Teraz zdaję sobie sprawę, że jest ściśle używany do wymiany / wymiany. Westchnienie! Nie mogę już komentować :(. Życie jest skazane!
Sid
12
JSON5 obsługuje komentarze: stackoverflow.com/a/7901053/108238
schoetbi

Odpowiedzi:

5587

Nie.

JSON powinien być danymi, a jeśli dodasz komentarz, to również będą to dane.

Możesz mieć wyznaczony element danych o nazwie "_comment"(lub coś takiego), który byłby ignorowany przez aplikacje korzystające z danych JSON.

Prawdopodobnie lepiej byłoby mieć komentarz w procesach, które generują / odbierają JSON, ponieważ powinni wiedzieć, jakie będą dane JSON z wyprzedzeniem lub przynajmniej jego struktura.

Ale jeśli zdecydujesz się:

{
   "_comment": "comment text goes here...",
   "glossary": {
      "title": "example glossary",
      "GlossDiv": {
         "title": "S",
         "GlossList": {
            "GlossEntry": {
               "ID": "SGML",
               "SortAs": "SGML",
               "GlossTerm": "Standard Generalized Markup Language",
               "Acronym": "SGML",
               "Abbrev": "ISO 8879:1986",
               "GlossDef": {
                  "para": "A meta-markup language, used to create markup languages such as DocBook.",
                  "GlossSeeAlso": ["GML", "XML"]
               },
               "GlossSee": "markup"
            }
         }
      }
   }
}
Eli
źródło
232
Może warto mieć jakiś prefiks na faktycznym komentarzu, na wypadek, gdyby kiedykolwiek było prawidłowe pole o nazwie komentarz:"__comment":"comment text goes here...",
Rob Fonseca-Ensor
19
BTW, biblioteka json dla Java google-gson obsługuje komentarze.
centyczny
11
Co jeśli chciałbym osobny komentarz do Accronymi Abbrevwłaściwości? Użyłem tego wzoru wcześniej, ale przestałem, ponieważ nie pozwala mi to zrobić. To jest hack. Może jeśli __comment__zamiast tego wstawię nazwę właściwości . To jest „__comment__Abbrev”, wciąż hack, ale pozwoliłbym skomentować wszystkie prpoerties
Juan Mendes
41
możesz także użyć „//”: wygląda to bardziej natywnie i nadal jest powtarzalne u tego samego rodzica
smnbbrv
4
Gdy JSON jest używany do plików konfiguracyjnych przeznaczonych dla ludzi, należy je opatrzyć adnotacjami, aby ludzie mogli lepiej zrozumieć. Z adnotacjami taki plik nie jest już prawidłowym JSON, ale istnieją rozwiązania. Na przykład GYP Google obsługuje komentarze w stylu #. JSON.Minify pomoże Ci odrzucić komentarze w stylu C / C ++ z pliku wejściowego.
Петър Петров
1841

Nie , komentarze do formularza //…lub /*…*/są zabronione w JSON. Ta odpowiedź jest oparta na:

  • http://www.json.org
  • RFC 4627 : Typ application/jsonnośnika dla JavaScript Object Notation (JSON)
  • RFC 8259 Format wymiany danych JavaScript Object Notation (JSON) (zastępuje RFC 4627, 7158, 7159)
stakx - już nie przyczynia się
źródło
67
Jeśli chcesz komentować swój JSON komentarzami (czyniąc go niepoprawnym JSON), to zminimalizuj go przed parsowaniem lub przesyłaniem. Sam Crockford potwierdził to w 2012 roku w kontekście plików konfiguracyjnych.
toolbear
24
@alkuzad: Jeśli chodzi o gramatykę formalną, musi być coś, co wyraźnie mówi, że dozwolone, a nie na odwrót. Na przykład, wybierz wybrany język programowania: To, że niektóre pożądane (ale brakujące) funkcje nie są wyraźnie niedozwolone, nie oznacza, że ​​Twój kompilator magicznie je rozpozna.
stakx - nie przyczynia się już
5
Tak. Format JSON ma dużo martwej przestrzeni między elementami i jest niewrażliwy na przestrzeń w tych regionach, więc nie ma powodu, dla którego nie można tam mieć komentarzy jedno- lub wieloliniowych. Wiele parserów i minizerów obsługuje również komentarze JSON, więc upewnij się, że parser je obsługuje. JSON jest często używany do danych aplikacji i ustawień konfiguracji, więc komentarze są teraz potrzebne. „Oficjalna specyfikacja” to fajny pomysł, ale jest niewystarczający i przestarzały, więc szkoda. Zminimalizuj JSON, jeśli martwisz się wielkością ładunku lub wydajnością.
Triynko
58
Chociaż twoja odpowiedź jest absolutnie poprawna, należy powiedzieć, że to jest BS. Przy tak dużej liczbie użytkowników końcowych potrzebujących konfiguracji json, komentarze są niezwykle pomocne. Tylko dlatego, że niektóre kapelusze z folii cynowej uznały, że JSON jest i zawsze musi być odczytywalny maszynowo, ignorując fakt, że ludzie muszą go czytać, jest to parodia drobiazgowości.
cmroanirgo
18
@cmroanirgo: Oczywiście nie jesteś pierwszym, który narzeka na to ograniczenie JSON ... dlatego mamy parsery, które po cichu pozwalają na komentarze i inne formaty, takie jak YAML i JSON5. Nie zmienia to jednak faktu, że JSON jest tym, czym jest. Interesujące wydaje mi się raczej to, że ludzie zaczęli używać JSON do celów, które najwyraźniej nie były wystarczające, biorąc pod uwagę omawiane ograniczenia. Nie obwiniaj formatu JSON; obwiniajmy się za naleganie na użycie go tam, gdzie nie jest to szczególnie dobre dopasowanie.
stakx - nie wnosi już
802

Dołącz komentarze, jeśli wybierzesz; usuń je za pomocą minifikatora przed parsowaniem lub przesyłaniem.

Właśnie wydałem JSON.minify (), która usuwa komentarze i białe znaki z bloku JSON i sprawia, że ​​jest to poprawny JSON, który można analizować. Możesz więc użyć go w następujący sposób:

JSON.parse(JSON.minify(my_str));

Kiedy ją wydałem, spotkałem się z ogromną reakcją ludzi, którzy nie zgadzają się nawet z tym pomysłem, więc postanowiłem napisać obszerny post na blogu o tym, dlaczego komentarze mają sens w JSON . Zawiera ten znaczący komentarz twórcy JSON:

Załóżmy, że używasz JSON do przechowywania plików konfiguracyjnych, które chcesz opatrzyć adnotacjami. Śmiało i wstaw wszystkie komentarze, które lubisz. Następnie potokuj go przez JSMin przed przekazaniem go do analizatora składni JSON. - Douglas Crockford, 2012

Mam nadzieję, że jest to pomocne dla tych, którzy nie zgadzają się z tym, dlaczego JSON.minify () może być przydatny.

Kyle Simpson
źródło
153
Jedyny problem, jaki mam z JSON.minify (), to to, że jest naprawdę bardzo wolny. Zrobiłem więc własną implementację, która robi to samo: gist.github.com/1170297 . W przypadku niektórych dużych plików testowych wdrożenie zajmuje 74 sekundy, a moje 0,06 sekundy.
WizKid,
56
byłoby świetnie, gdybyś mógł przesłać sugerowany alternatywny algorytm do repozytorium github dla JSON.minify (), aby można go było przenieść na wszystkie obsługiwane języki: github.com/getify/json.minify
Kyle Simpson
16
@MiniGod Wiele razy słyszałem przemyślenia Douga na ten temat. Zwróciłem się do
Kyle Simpson
18
@ MarnenLaibow-Koser nadal istnieją poprawne zastosowania komentarzy, nawet do strumieniowego przesyłania danych (lub nawet pakietów): włączenie metadanych diagnostycznych, takich jak czas tworzenia lub źródła, jest powszechne w przypadku XML i doskonale nadaje się również dla danych JSON. Argumenty przeciwko komentarzom są płytkie, a każdy format danych tekstowych powinien pozwalać na komentarze, niezależnie od dorozumianego zamierzonego użycia (nic nie wskazuje, że JSON nie może być używany gdzie indziej, fwiw)
StaxMan
18
Jeśli JSON ma mieć uniwersalną akceptację (co w zasadzie robi), powinien mieć uniwersalne zastosowanie. Przykład: JSON może służyć jako plik konfiguracyjny aplikacji. Ta aplikacja chciałaby komentarze.
eggmatters
441

Komentarze zostały usunięte z JSON zgodnie z projektem.

Usunąłem komentarze z JSON, ponieważ widziałem, jak ludzie używali ich do przechowywania parsujących dyrektyw, co zniszczyłoby interoperacyjność. Wiem, że brak komentarzy wywołuje u niektórych smutek, ale nie powinien.

Załóżmy, że używasz JSON do przechowywania plików konfiguracyjnych, które chcesz opatrzyć adnotacjami. Śmiało i wstaw wszystkie komentarze, które lubisz. Następnie potokuj go przez JSMin przed przekazaniem go do analizatora składni JSON.

Źródło: publiczne oświadczenie Douglasa Crockforda w sprawie G +

Artur Czajka
źródło
198
Myślałem, że JSON powinien być bardziej czytelny dla człowieka niż, powiedzmy, XML? Komentarze są dla czytelności.
intrepidis
25
W każdym razie możesz być niegrzeczny i dodać dyrektywy analizujące w JSON: {"__directives": {"# n #": "DateTime.Now"}, "validdate": "# n #"} ... Wygląda jak YAML jest więc droga naprzód ...
intrepidis
73
Osobista opinia: niedopuszczanie komentarzy jest kiepskie. Nie miałem innej opcji niż zbudowanie niestandardowego analizatora składni JSON, który ignoruje komentarze, aby zdekodować moje pliki konfiguracyjne.
caiosm1005,
17
@ArturCzajka Nadal nie podoba mi się fakt, że JSON nie obsługuje komentarzy, ale spróbowałem INI i muszę przyznać, że bardziej sensowne jest używanie ich w JSON do plików konfiguracyjnych. Dzięki za odpowiedź i mam nadzieję, że więcej osób zmieni zdanie podczas czytania tej rozmowy. (tworzenie parsera i tak było bardziej ćwiczeniem :)
caiosm1005
77
To tak, jakby wymagać od wszystkich rowerów posiadania kół treningowych, ponieważ niektórzy ludzie nie mogą jeździć na rowerach. Usunięcie ważnej funkcji, ponieważ głupie ludzie wykorzystują to zły projekt. Format danych powinien nadawać priorytet użyteczności, a nie być idiotycznym.
Phil Goetz
205

WYŁĄCZENIE ODPOWIEDZIALNOŚCI: TWOJA GWARANCJA JEST USUNIĘTA

Jak już wspomniano, ten hack wykorzystuje implementację specyfikacji. Nie wszystkie parsery JSON zrozumieją tego rodzaju JSON. Parsery przesyłania strumieniowego w szczególności będą się dusić.

To ciekawa ciekawość, ale tak naprawdę nie powinieneś jej używać do niczego . Poniżej znajduje się oryginalna odpowiedź.


Znalazłem mały hack, który pozwala umieszczać komentarze w pliku JSON, które nie wpłyną na parsowanie, ani nie będą w żaden sposób zmieniać reprezentowanych danych.

Wygląda na to, że deklarując literał obiektu, możesz podać dwie wartości za pomocą tego samego klucza, a ostatnia ma pierwszeństwo. Wierzcie lub nie, okazuje się, że parsery JSON działają w ten sam sposób. Możemy więc użyć tego do stworzenia komentarzy w źródłowym JSON, które nie będą obecne w reprezentacji parsowanego obiektu.

({a: 1, a: 2});
// => Object {a: 2}
Object.keys(JSON.parse('{"a": 1, "a": 2}')).length; 
// => 1

Jeśli zastosujemy tę technikę, skomentowany plik JSON może wyglądać następująco:

{
  "api_host" : "The hostname of your API server. You may also specify the port.",
  "api_host" : "hodorhodor.com",

  "retry_interval" : "The interval in seconds between retrying failed API calls",
  "retry_interval" : 10,

  "auth_token" : "The authentication token. It is available in your developer dashboard under 'Settings'",
  "auth_token" : "5ad0eb93697215bc0d48a7b69aa6fb8b",

  "favorite_numbers": "An array containing my all-time favorite numbers",
  "favorite_numbers": [19, 13, 53]
}

Powyższy kod jest prawidłowym JSON . Jeśli go przeanalizujesz, otrzymasz taki obiekt:

{
    "api_host": "hodorhodor.com",
    "retry_interval": 10,
    "auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
    "favorite_numbers": [19,13,53]
}

Co oznacza, że ​​nie ma śladu komentarzy i nie będą miały dziwnych skutków ubocznych.

Miłego hakowania!

p3drosola
źródło
150
Ze specyfikacji : Nazwy w obiekcie POWINNY być unikalne.
Quentin
113
„wszystkie implementacje radzą sobie tak samo” - trudno to udowodnić.
Quentin,
91
Kolejność elementów w JSON nie jest gwarantowana. Oznacza to, że „ostatni” element może się zmienić!
sep332
66
To wyraźnie narusza specyfikację (patrz powyższe komentarze), nie rób tego. ietf.org/rfc/rfc4627.txt?number=4627
voidlogic
333
NIE - co jeśli parser przesyła strumieniowo? Co jeśli parser wczyta go do słownika, w którym kolejność klawiszy jest niezdefiniowana? zabij to ogniem .
deanWombourne,
183

JSON nie obsługuje komentarzy. Nigdy nie był przeznaczony do użycia w plikach konfiguracyjnych, w których potrzebne byłyby komentarze.

Hjson to format pliku konfiguracyjnego dla ludzi. Zrelaksowana składnia, mniej błędów, więcej komentarzy.

Wprowadzenie do Hjsona

Zobacz hjson.org dla bibliotek JavaScript, Java, Python, PHP, Rust, Go, Ruby i C #.

laktak
źródło
13
Pozytywne. To oczywiście dobra odmiana, nieokreśleni konserwatywni ludzie po prostu chcieliby nienawidzić. Mam nadzieję, że twoja implementacja stanie się bardziej znana - a może nawet stanie się bardziej popularna niż oryginalna;) Mam nadzieję, że ktoś też ją wdroży wraz z Ruby. @adelphus Dobrze zdefiniowany język to twoja własna perspektywa lub opinia. Bycie konserwatywnym „deweloperem”, jeśli nim jesteś, nie świadczy o tym, że jesteś lepszy, a może być jeszcze gorzej, jeśli jesteś zamknięty w ograniczonej przestrzeni. Nie idź łatwo osądzać ludzi jako okropnych programistów.
konsolebox
7
Przepraszam za to, @konsolebox. Być może po ponownym przeczytaniu ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf możesz ponownie rozważyć swój „dobrze zdefiniowany JSON to Twoja opinia”. Jest to prawdziwy standard i deweloperzy wdrażający własne „specjalne” wersje prowadzi do fragmentacji, zamieszania i dużej ilości zmarnowanego czasu. Spójrz na bałagan, który pozostawia twórcom stron internetowych podczas pisania kodu tylko dlatego, że każda przeglądarka implementuje nieco inne wersje standardów. Język JSON może nie być idealny, ale fragmentacja jest gorsza. I tak, to tylko opinia i możesz się nie zgodzić.
adelphus
22
Podziwiam twoją żądzę, ale na nowo wymyślasz YAML. Jeśli chcesz dużo elastyczności i czytelności dla ludzi, użyj YAML (w rzeczywistości: stackoverflow.com/questions/450399/... ) lub trzymaj się curmudgeony, ale jednoznacznego JSON.
toolbear
4
Uważam, że najbardziej przyjaznym dla użytkownika formatem konfiguracji jest nadal INI. Jest prosty i niezbyt ciężki pod względem składni. To sprawia, że ​​jest mniej onieśmielające dla użytkowników po prostu zanurzających palce w stawie konfiguracji.
Matt
14
Ilekroć potrzebujesz json jako config (tam, gdzie potrzebne komentarze ) - nazwij swój plik „.js” zamiast „.json” .. js może oczywiście obsłużyć dowolny prawidłowy obiekt json i dodatkowo może obsługiwać komentarze. To dlatego jest to „webpack.config.js”, a nie „webpack.config.json” (no cóż, jest o wiele więcej powodów w webpack: P)
jebiebie
122

Rozważ użycie YAML. Jest to prawie nadzbiór JSON (praktycznie wszystkie poprawne JSON to poprawne YAML) i pozwala na komentarze.

Marnen Laibow-Koser
źródło
12
@ g33kz0r Prawidłowo, stąd mój opis YAML jako prawie superset JSON.
Marnen Laibow-Koser
12
@NateS Wiele osób już zauważyło, że odpowiedź brzmi „nie”. Zasugerowałem lepszy sposób na osiągnięcie celu PO. To jest odpowiedź.
Marnen Laibow-Koser
5
Wada: yamlbiblioteka nie jest dostarczana z Pythonem.
Krwawiące palce
6
@ marnen-laibow-koser: tak, używanie dostępnych bibliotek YAML dla Javy i Perla musiało być niekompetencją i oczekiwać, że YAML wyprodukowane przez każdą z nich zostanie zużyte przez drugą osobę bez błędów. To, że interakcja YAML była problemem, ale interakcja JSON nie była, jest całkowicie wyjaśnione moim brakiem wiedzy.
toolbear
3
@ marnen-laibow-koser, format, który osiąga to samo z prostszą specyfikacją, jest lepszy. Pragmatyczny format z doskonałymi implementacjami jest lepszy niż idealny format z niedoskonałymi implementacjami. Nie cała wina za wadliwe biblioteki spoczywa na barkach implementatorów; specyfikacja YAML jest długa, gęsta i tępa. Wpis w Wikipedii przytacza dwa przykłady dwuznaczności; jeśli trzeba umieścić emiter między człowiekiem a formatem, aby chronić go przed dwuznacznościami, format traci swoje przyjazne dla człowieka twierdzenie. JSON twierdzi mniej i przeważnie odnosi sukcesy tam, gdzie YAML twierdzi więcej, a nie spełnia.
toolbear
108

Nie możesz Przynajmniej takie jest moje doświadczenie na pierwszy rzut oka na json.org .

JSON ma swoją wizualizację na tej stronie. Nie ma żadnych uwag na temat komentarzy.

Wesoły
źródło
67

Komentarze nie są oficjalnym standardem, chociaż niektóre parsery obsługują komentarze w stylu C ++. Jednym z nich jest JsonCpp . W przykładach jest ten:

// Configuration options
{
    // Default encoding for text
    "encoding" : "UTF-8",

    // Plug-ins loaded at start-up
    "plug-ins" : [
        "python",
        "c++",
        "ruby"
        ],

    // Tab indent size
    "indent" : { "length" : 3, "use_space": true }
}

jsonlint tego nie sprawdza. Tak więc komentarze są rozszerzeniem specyficznym dla parsera, a nie standardem.

Kolejnym parserem jest JSON5 .

Alternatywa dla JSON TOML .

Kolejną alternatywą jest jsonc .

schoetbi
źródło
Groovy ma wbudowane klasy do obsługi JSON . JsonSlurper może obsługiwać komentarze. Oczywiście komentarze nie są dozwolone w oficjalnej specyfikacji, więc takie zachowanie w dowolnym parserze jest niestandardowe i nieprzenośne.
izrik
Newsonoft Json.NET obsługuje również komentarze w stylu C bez problemów
Max
66

Zamiast tego powinieneś napisać schemat JSON . Schemat JSON jest obecnie proponowaną internetową specyfikacją wersji roboczej. Oprócz dokumentacji schematu można także użyć do sprawdzania poprawności danych JSON.

Przykład:

{
    "description":"A person",
    "type":"object",
    "properties":
        {
            "name":
                {
                    "type":"string"
                },
            "age":
                {
                    "type":"integer",
                    "maximum":125
                }
        }
}

Możesz dostarczyć dokumentację, używając atrybutu schematu opisu .

loteria
źródło
5
Czy schemat JSON jest żywy? Istnieje, ale czy jest obsługiwany przez jakąkolwiek znaną bibliotekę?
Munhitsu
1
tak, grupa google json-schema jest dość aktywna i poleciłbym JSV dla dobrej implementacji JavaScript walidatora schematu JSON.
raffel
5
Pomaga to tylko w tworzeniu dokumentacji strukturalnej, a nie dokumentacji ad hoc
Juan Mendes
Jeśli używasz clojure (i jestem pewien, że nie), można znaleźć tutaj parser schematów JSON o otwartym kodzie źródłowym: github.com/bigmlcom/closchema
charleslparker
@Munhitsu Manatee.Json (.Net) intensywnie obsługuje schemat JSON.
gregsdennis
64

Jeśli używasz Jacksona jako parsera JSON, włącz tę opcję, aby umożliwić komentarze:

ObjectMapper mapper = new ObjectMapper().configure(Feature.ALLOW_COMMENTS, true);

Następnie możesz mieć takie komentarze:

{
  key: "value" // Comment
}

Możesz także dodawać komentarze, zaczynając #od:

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);

Ale ogólnie (jak wcześniej odpowiedziano) specyfikacja nie pozwala na komentarze.

Andrejs
źródło
50

Oto, co znalazłem w dokumentacji Google Firebase, która pozwala na umieszczanie komentarzy w JSON:

{
  "//": "Some browsers will use this to enable push notifications.",
  "//": "It is the same for all projects, this is not your project's sender ID",
  "gcm_sender_id": "1234567890"
}
mana
źródło
Do Twojej wiadomości, Firebase Realtime Database nie pozwala na użycie „/” w kluczu. więc może to być fajna konwencja na własny użytek, ale nie możesz tego zrobić w
Firebase
5
Ta metoda psuje niektóre biblioteki, które wymagają, aby klucz był unikalny. Pracuję nad tym problemem, numerując komentarze.
MovGP0,
dobry komentarz, znalazłem to pytanie na SO ... ta część wydaje się nie być objęta specyfikacją stackoverflow.com/questions/21832701/...
mana
4
Obecnie używam go w ten sposób: {„// foo”: „komentarz foo”, „foo”: „wartość foo”, „// bar”: „komentarz do paska”, „bar”: „wartość paska”} Możesz użyć tablicy dla wielu komentarzy: {„// foo”: [„foo comment 1”, „foo comment 2”], „foo”: „'foo value”}
MovGP0
47

NO . JSON wspierał komentarze, ale były one nadużywane i usuwane ze standardu.

Od twórcy JSON:

Usunąłem komentarze z JSON, ponieważ widziałem, jak ludzie używali ich do przechowywania parsujących dyrektyw, co zniszczyłoby interoperacyjność. Wiem, że brak komentarzy wywołuje u niektórych smutek, ale nie powinien. - Douglas Crockford, 2012

Oficjalna strona JSON znajduje się na JSON.org . JSON jest zdefiniowany jako standard przez ECMA International. Zawsze istnieje proces składania petycji w celu zmiany standardów. Jest mało prawdopodobne, że adnotacje zostaną dodane do standardu JSON z kilku powodów.

JSON z założenia jest łatwą do inżynierii wstecznej (analizowaną przez człowieka) alternatywą dla XML. Uproszczono nawet do tego stopnia, że ​​adnotacje są niepotrzebne. To nawet nie jest język znaczników. Celem jest stabilność i interoperacyjność.

Każdy, kto rozumie relację orientacji obiektowej „ma-a”, może zrozumieć każdą strukturę JSON - o to właśnie chodzi. Jest to po prostu ukierunkowany wykres acykliczny (DAG) ze znacznikami węzłów (pary klucz / wartość), który jest prawie uniwersalną strukturą danych.

Wymagana jest tylko adnotacja „// To są tagi DAG”. Kluczowe nazwy mogą być tak pouczające, jak to konieczne, pozwalając na dowolne arant semantyczny.

Każda platforma może analizować JSON za pomocą zaledwie kilku wierszy kodu. XML wymaga złożonych bibliotek OO, które nie są wykonalne na wielu platformach.

Adnotacje sprawią, że JSON sprawi, że będzie mniej interoperacyjny. Po prostu nie ma nic więcej do dodania, chyba że tak naprawdę potrzebujesz języka znaczników (XML) i nie przejmuj się, czy utrwalone dane można łatwo przeanalizować.

ALE, jak zauważył również twórca JSON, zawsze istniało wsparcie potoku JS dla komentarzy:

Śmiało i wstaw wszystkie komentarze, które lubisz. Następnie potokuj go przez JSMin przed przekazaniem go do analizatora składni JSON. - Douglas Crockford, 2012

Dominic Cerisano
źródło
37

Jeśli Twój plik tekstowy, który jest łańcuchem JSON, zostanie odczytany przez jakiś program, jak trudno byłoby usunąć komentarze w stylu C lub C ++ przed jego użyciem?

Odpowiedź: Byłby to jeden liniowiec. Jeśli to zrobisz, pliki JSON mogą zostać użyte jako pliki konfiguracyjne.

John T. Vonachen
źródło
1
Prawdopodobnie najlepsza jak dotąd sugestia, choć nadal jest to problem dotyczący przechowywania plików jako formatu wymiany, ponieważ wymagają one wstępnego przetwarzania przed użyciem.
Orbling
Zgadzam się i napisałem parser JSON w Javie, dostępny na www.SoftwareMonkey.org, który właśnie to robi.
Lawrence Dol
2
Mimo że myślę, że nie jest dobrym pomysłem rozszerzenie JSON (bez nazywania go innym formatem wymiany): pamiętaj o ignorowaniu „komentarzy” w łańcuchach. {"foo": "/ * To nie jest komentarz. * /"}
stofl
27
„... byłoby jednym linerem” umm, nie, w rzeczywistości JSON nie jest zwykłą gramatyką, w której wyrażenie regularne może po prostu znaleźć pasujące pary / *. Musisz przeanalizować plik, aby sprawdzić, czy / * pojawia się w ciągu (i zignoruj ​​go), czy też jest poprzedzony (i zignoruj) itp. Odpowiedź jest również nieprzydatna, ponieważ po prostu spekulujesz (niepoprawnie), a nie podajesz dowolne rozwiązanie.
Kyle Simpson,
1
Co powiedział @ Kyle-Simpson. Jest też zbyt skromny, aby kierować czytelników do własnej odpowiedzi na temat używania JSON.minify jako alternatywy dla wyrażeń ad hoc. Zrób to, nie to.
toolbear
36

Jeśli używasz biblioteki Newtonsoft.Json z ASP.NET do odczytu / deserializacji, możesz użyć komentarzy w treści JSON:

// „name”: „string”

// "id": int

lub

/* To jest

przykład komentarza * /

PS: Komentarze jednowierszowe są obsługiwane tylko w ponad 6 wersjach Newtonsoft Json.

Dodatkowa uwaga dla osób, które nie potrafią myśleć nieszablonowo: używam formatu JSON do podstawowych ustawień w aplikacji internetowej ASP.NET, którą stworzyłem. Czytam plik, przekształcam go w obiekt ustawień za pomocą biblioteki Newtonsoft i używam go w razie potrzeby.

Wolę pisać komentarze o poszczególnych ustawieniach w samym pliku JSON i naprawdę nie dbam o integralność formatu JSON, o ile biblioteka, której używam, jest w porządku.

Myślę, że jest to „łatwiejszy w użyciu / zrozumieniu” niż tworzenie osobnego pliku „settings.README” i objaśnianie zawartych w nim ustawień.

Jeśli masz problem z tego rodzaju użytkowaniem; przepraszam, dżin wyszedł z lampy. Ludzie znajdą inne zastosowania dla formatu JSON i nic nie możesz na to poradzić.

dvdmn
źródło
Trudno zrozumieć, dlaczego ktoś miałby problem ze stwierdzeniem faktu.
dvdmn
Zakładam, że ktoś wziął wyjątek, ponieważ powyższe nie jest już JSON lub jest niepoprawnym JSON. Być może dodanie krótkiego zrzeczenia się uspokoiłoby.
toolbear
5
Całkowicie się z tobą zgadzam, a jednak do tej pory istnieje 883 głosujących za brakiem odpowiedzi, który stanowi tylko oczywistość. Ideologiczna czystość ceniona powyżej pomocnych informacji, to dla Ciebie TAK.
Jan
Chodzi o to, że plik z komentarzami nie jest JSON i nie może zostać przeanalizowany przez wiele bibliotek JSON. Rób co chcesz we własnym programie, ale plik z komentarzami to nie JSON. Jeśli twierdzisz, że tak, ludzie będą próbowali parsować go z wybranym językiem / biblioteką, a to się nie powiedzie. To tak, jakby zapytać, czy w XML można użyć nawiasów kwadratowych zamiast nawiasów kątowych. Możesz robić, co chcesz, ale nie będzie to już XML.
gman
32

Ideą JSON jest zapewnienie prostej wymiany danych między aplikacjami. Zazwyczaj są one oparte na Internecie, a językiem jest JavaScript.

Tak naprawdę nie pozwala na komentarze jako takie, jednak przekazanie komentarza jako jednej z par nazwa / wartość w danych z pewnością zadziałałoby, chociaż te dane oczywiście musiałyby zostać zignorowane lub przetworzone specjalnie przez kod parsujący.

To powiedziawszy, nie jest intencją, aby plik JSON zawierał komentarze w tradycyjnym znaczeniu. To powinny być tylko dane.

Zajrzyj na stronę JSON, aby uzyskać więcej szczegółów.

Neil Albrock
źródło
17
To prawda, że ​​format JSON nie ma komentarzy. Osobiście uważam, że to poważny błąd - możliwość dodawania komentarzy jako metadanych (a nie danych) jest bardzo przydatną rzeczą w xml. Wcześniejsze wersje robocze specyfikacji JSON zawierały komentarze, ale z jakiegoś powodu zostały usunięte. : - /
StaxMan,
4
@StaxMan zostały usunięte dokładnie dlatego, że ludzie zaczęli używać ich jako metadanych. Crockford powiedział, że złamał kompatybilność z tym, co został zaprojektowany format, i zgadzam się: jeśli chcesz metadanych, dlaczego nie uwzględnić ich jako rzeczywistych danych? Jeszcze łatwiej jest sparsować w ten sposób.
Camilo Martin,
6
Metadane należą do konstrukcji metadanych (np. Znaczniki HTML <meta>), a nie do komentarzy. Nadużywanie komentarzy do metadanych to tylko hack używany, gdy nie istnieje prawdziwa konstrukcja metadanych.
Marnen Laibow-Koser
To jest dokładnie powód, dla którego został usunięty: komentarze użyte jako metadane mogłyby zepsuć interoperacyjność. Powinieneś po prostu przechowywać swoje metadane jako JSON.
gaboryczny
1
Ta odpowiedź jest zbędna z lepiej napisanymi, wyżej ocenionymi odpowiedziami, które mówią w zasadzie to samo, nawet jeśli zostało to napisane wcześniej. Cest la vie.
toolbear
29

Właśnie napotkałem to w przypadku plików konfiguracyjnych. Nie chcę używać formatu XML (pełny, graficzny, brzydki, trudny do odczytania) ani formatu „ini” (bez hierarchii, żadnego prawdziwego standardu itp.) Ani formatu Java „Właściwości” (jak .ini).

JSON może zrobić wszystko, co w ich mocy, ale jest to mniej szczegółowe i bardziej czytelne dla ludzi - a parsery są łatwe i wszechobecne w wielu językach. To tylko drzewo danych. Ale komentarze spoza pasma często wymagają udokumentowania „domyślnych” konfiguracji i tym podobnych. Konfiguracje nigdy nie powinny być „pełnymi dokumentami”, ale drzewami zapisanych danych, które w razie potrzeby mogą być czytelne dla człowieka.

Wydaje mi się, że można użyć "#": "comment"do „prawidłowego” JSON.

peterk
źródło
4
W przypadku plików konfiguracyjnych sugerowałbym YAML, a nie JSON. Jest (prawie) potężniejszym nadzbiorem JSON, ale obsługuje również bardziej czytelne konstrukcje, w tym komentarze.
Marnen Laibow-Koser
1
jak myślisz, w ilu językach obsługuje YAML od razu po wyjęciu z pudełka w porównaniu z json?
mmm
@Hamidam Ponad tuzin języków obsługuje yaml: yaml.org - ale masz rację, pytając, ile z nich ma wbudowane wsparcie, bez potrzeby zależnego od bibliotek oprogramowania zewnętrznego. Wygląda jak Ruby 1.9.2. Czy ktoś wie o innych? A które języki domyślnie oferują obsługę Json?
nealmcb
5
YAML współdziałanie jest kłamstwem: stackoverflow.com/questions/450399/... . Jeśli instynkt ma używać JSON do plików konfiguracyjnych, postępuj zgodnie z nim.
toolbear
To stare, ale uważam, że użycie # nie jest dobrym pomysłem. Json jest zbliżony do składni literatury Javascript. JavaScript obsługuje 2 typy komentarzy: // i / * ... * / Gdybym był na twoim miejscu, trzymałbym się jednego lub obu tych typów komentarzy.
Pascal Ganaye,
28

JSON nie obsługuje komentarzy natywnie, ale możesz stworzyć własny dekoder lub przynajmniej preprocesor do usuwania komentarzy, to jest w porządku (pod warunkiem, że po prostu zignorujesz komentarze i nie użyjesz ich do wskazania, jak aplikacja powinna przetwarzać dane JSON ).

JSON nie ma komentarzy. Koder JSON NIE MOŻE wyprowadzać komentarzy. Dekoder JSON MOŻE akceptować i ignorować komentarze.

Komentarze nigdy nie powinny być wykorzystywane do przekazywania czegokolwiek znaczącego. Po to jest JSON.

Por .: Douglas Crockford, autor specyfikacji JSON .

gaboryczny
źródło
4
Crockford napisał później: „Załóżmy, że używasz JSON do przechowywania plików konfiguracyjnych, które chciałbyś opatrzyć adnotacjami. Śmiało i wstaw wszystkie komentarze, które ci się podobają. Następnie prześlij je przez JSMin przed przekazaniem go do parsera JSON.” Aby uzyskać więcej informacji, zobacz odpowiedź @ kyle-simpson na temat JSON.minify.
toolbear
27

JSON ma sens w przypadku plików konfiguracyjnych i innych lokalnych zastosowań, ponieważ jest wszechobecny i ponieważ jest znacznie prostszy niż XML.

Jeśli ludzie mają poważne powody, by nie komentować w JSON komentarzy podczas przekazywania danych (bez względu na to, czy są ważne, czy nie), prawdopodobnie JSON można podzielić na dwa:

  • JSON-COM: JSON w sieci lub reguły obowiązujące podczas przesyłania danych JSON.
  • JSON-DOC: dokument JSON lub JSON w plikach lub lokalnie. Reguły definiujące prawidłowy dokument JSON.

JSON-DOC zezwala na komentarze i mogą występować inne drobne różnice, takie jak obsługa białych znaków. Parsery można łatwo konwertować z jednej specyfikacji na drugą.

W odniesieniu do uwagi Douglasa Crockforda na ten temat (powołanej przez @Artur Czajka)

Załóżmy, że używasz JSON do przechowywania plików konfiguracyjnych, które chcesz opatrzyć adnotacjami. Śmiało i wstaw wszystkie komentarze, które lubisz. Następnie potokuj go przez JSMin przed przekazaniem go do analizatora składni JSON.

Mówimy o ogólnym problemie z plikiem konfiguracyjnym (między językami / platformą), a on odpowiada za pomocą narzędzia JS!

Pewnie, że minify specyficzne dla JSON może być zaimplementowane w dowolnym języku, ale standaryzuj to, aby stało się wszechobecne w parserach we wszystkich językach i platformach, aby ludzie przestali tracić czas na brak tej funkcji, ponieważ mają dobre przypadki użycia, szukając problemu w forach internetowych i zachęcanie ludzi do mówienia, że ​​to zły pomysł lub sugerowanie, że łatwo jest zaimplementować usuwanie komentarzy z plików tekstowych.

Inną kwestią jest interoperacyjność. Załóżmy, że masz bibliotekę, interfejs API lub dowolny podsystem, z którym powiązane są pewne pliki konfiguracyjne lub pliki danych. Dostęp do tego podsystemu można uzyskać z różnych języków. Czy możesz powiedzieć innym: przy okazji nie zapomnij usunąć komentarzy z plików JSON przed przekazaniem ich do parsera!

Basel Shishani
źródło
Nie trzeba fragmentować JSON. JSON z komentarzami nie jest już JSON. Ale dopuszczalne jest dodawanie adnotacji do JSON komentarzami, pod warunkiem, że usuniesz je przed analizą lub przesłaniem. W tym celu odbiorca nigdy nie powinien ponosić odpowiedzialności.
toolbear
json5.org to rozwiązanie dla json-doc
Michael Freidgeim
24

Jeśli używasz JSON5 , możesz dołączyć komentarze.


JSON5 to proponowane rozszerzenie JSON, którego celem jest ułatwienie ludziom pisania i utrzymywania ręcznie. Robi to poprzez dodanie minimalnych funkcji składniowych bezpośrednio z ECMAScript 5.

Smit Johnth
źródło
5
Czy możesz dodać przykład? Wtedy możesz potrzebować dodatkowych znaków.
dgilperez
6
W wytycznych SO wymagane jest podanie rzeczywistej odpowiedzi. Odpowiedzi tylko z łączem nie są pożądane. Możesz sprawdzić wytyczne stackoverflow.com/help/how-to-answer
dgilperez
2
SO jest moderowane przez użytkowników. Oznacza to, że mogę udzielić odpowiedzi, jeśli ją otrzymam, w ten sam sposób, w jaki mogę skomentować Twoją, jeśli nie będzie zgodna z wytycznymi. W ten sposób SO staje się świetnym zasobem.
dgilperez
22

Pakiet JavaScript Dojo Toolkit (przynajmniej od wersji 1.4) pozwala na dołączanie komentarzy do JSON. Komentarze mogą mieć /* */format. Dojo Toolkit zużywa JSON za pośrednictwem dojo.xhrGet()połączenia.

Inne zestawy narzędzi JavaScript mogą działać podobnie.

Może to być pomocne podczas eksperymentowania z alternatywnymi strukturami danych (lub nawet listami danych) przed wybraniem ostatecznej opcji.

David
źródło
4
Nie. Nie to. JSON nie ma komentarzy. Jeśli zdecydujesz się dodać adnotację do JSON za pomocą komentarzy, zminimalizuj go przed analizą lub przesłaniem. Nie powinien to być obowiązek odbiorcy.
toolbear
2
Nie powiedziałem, że JSON ma komentarze. Nie chciałem też sugerować, że właściwe jest uwzględnienie ich w JSON, szczególnie w systemie produkcyjnym. Powiedziałem, że zestaw narzędzi Dojo pozwala je dodawać, co jest (lub przynajmniej było) prawdą. Istnieją bardzo pomocne przypadki użycia, aby to zrobić na etapie testowania.
David
1
Słabym voodoo jest podawanie komentowanych, a tym samym niepoprawnych JSON, które dojo.xhrGet()domyślnie zachęcają poprzez akceptację.
toolbear
Nadal głosuję za aktualizacją specyfikacji JSON, aby umożliwić komentarze. Jestem za minimalizowaniem i usuwaniem komentarzy przed przesłaniem JSON, ale nie mam możliwości komentowania twojego JSON w żaden standardowy sposób, bez konieczności przekazywania go przez osobne narzędzie przed parsowaniem go, po prostu wydaje się głupie. Uniemożliwiam także użycie edytora JSON w plikach konfiguracyjnych JSON, ponieważ pliki nie są poprawne JSON.
Craig
20

JSON nie jest protokołem ramkowym . Jest to format bez języka . Dlatego format komentarza nie jest zdefiniowany dla JSON.

Jak wiele osób sugerowało, istnieją pewne sztuczki, na przykład duplikaty kluczy lub określony klucz _comment, którego można użyć. To zależy od Ciebie.

Manish Shrivastava
źródło
18

Ty można mieć uwag w jsonp , ale nie w czystej JSON. Właśnie spędziłem godzinę próbując zmusić mój program do pracy z tym przykładem z Highcharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?

Jeśli klikniesz ten link, zobaczysz

?(/* AAPL historical OHLC data from the Google Finance API */
[
/* May 2006 */
[1147651200000,67.79],
[1147737600000,64.98],
...
[1368057600000,456.77],
[1368144000000,452.97]
]);

Ponieważ miałem podobny plik w folderze lokalnym, nie było żadnych problemów z polityką tego samego pochodzenia , więc zdecydowałem się użyć czystego JSON ... i oczywiście $.getJSONzawiodłem z powodu komentarzy.

W końcu właśnie wysłałem ręczne żądanie HTTP na powyższy adres i zdałem sobie sprawę, że typ zawartości był, text/javascriptponieważ JSONP zwraca czysty JavaScript. W takim przypadku komentarze są dozwolone . Ale moja aplikacja zwróciła treść application/json, więc musiałem usunąć komentarze.

osa
źródło
17

To jest pytanie „czy możesz” . A oto odpowiedź „tak” .

Nie, nie powinieneś używać duplikatywnych elementów obiektu do umieszczania danych kanału bocznego w kodowaniu JSON. (Patrz „Nazwy w obiekcie POWINNY być unikalne” w RFC ).

I tak, można wstawiać komentarze około JSON , które można przetworzyć na zewnątrz.

Ale jeśli chcesz wprowadzić i wyodrębnić dowolne dane kanału bocznego do prawidłowego JSON, oto odpowiedź. Korzystamy z nieunikalnej reprezentacji danych w kodowaniu JSON. Jest to dozwolone * w sekcji drugiej dokumentu RFC w części „białe znaki są dozwolone przed lub po którymkolwiek z sześciu znaków strukturalnych”.

* RFC stwierdza tylko, że „spacja jest dozwolona przed lub po którymkolwiek z sześciu znaków strukturalnych”, nie mówiąc wprost o ciągach, liczbach, „fałszu”, „prawdzie” i „null”. To pominięcie jest ignorowane we WSZYSTKICH implementacjach.


Najpierw kanonizuj JSON, minimalizując go:

$jsonMin = json_encode(json_decode($json));

Następnie zakoduj swój komentarz w formacie binarnym:

$hex = unpack('H*', $comment);
$commentBinary = base_convert($hex[1], 16, 2);

Następnie ustal swój plik binarny:

$steg = str_replace('0', ' ', $commentBinary);
$steg = str_replace('1', "\t", $steg);

Oto twój wynik:

$jsonWithComment = $steg . $jsonMin;
William Entriken
źródło
1
RFC stwierdza tylko, że „spacja jest dozwolona przed lub po którymkolwiek z sześciu znaków strukturalnych”, nie mówiąc wprost o ciągach, liczbach, „fałszu”, „prawdzie”, „null”. To pominięcie jest ignorowane we WSZYSTKICH implementacjach.
William Entriken
1
Aby uzyskać większą gęstość komentarzy, czy nie można zakodować komentarza w trójce i użyć spacji, tabulacji i nowej linii, aby go zablokować?
Claire Nielsen,
POWINIEN NIE MUSI. Zobacz wyraźnie dołączony RFC 2119: MUSI: To słowo lub określenia „WYMAGANE” lub „MUSZĄ” oznaczają, że definicja jest bezwzględnym wymogiem specyfikacji. ... POWINIEN: To słowo lub przymiotnik „ZALECANE” oznaczają, że mogą istnieć uzasadnione powody, aby w określonych okolicznościach zignorować dany element, ale pełne implikacje należy zrozumieć i dokładnie rozważyć przed wyborem innego kursu.
Jeff K
Dobre referencje. Lepszym argumentem przeciwko używaniu zduplikowanych kluczy jest cytat standardu „Gdy nazwy w obiekcie nie są unikalne, zachowanie oprogramowania, które odbiera taki obiekt, jest nieprzewidywalne”. Teraz też rozumiem, dlaczego standard nie był „MUSI być unikalny”, dzięki czemu walidator jest prostszy, wystarczy jedynie śledzić [i {, nie trzeba wiedzieć, które klucze były już używane.
William Entriken
16

WYŁĄCZENIE ODPOWIEDZIALNOŚCI: TO GŁOS

Istnieje sposób dodawania komentarzy i pozostawania w ramach specyfikacji (nie jest wymagany żaden dodatkowy analizator składni). Nie spowoduje to jednak czytelnych dla człowieka komentarzy bez jakiejkolwiek analizy.

Możesz nadużywać następujących elementów:

Nieznaczne białe znaki są dozwolone przed dowolnym tokenem lub po nim. Biała spacja to dowolna sekwencja jednego lub więcej następujących punktów kodowych: tabulacja znaków (U + 0009), przesunięcie wiersza (U + 000A), powrót karetki (U + 000D) i spacja (U + 0020).

W hacky sposób możesz nadużyć tego, aby dodać komentarz. Na przykład: rozpocznij i zakończ komentarz za pomocą karty. Zakoduj komentarz w base3 i użyj innych białych znaków, aby je przedstawić. Na przykład.

010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202

( hello base threew ASCII) Zamiast 0 użyj spacji, dla 1 użyj przesunięcia wiersza i dla 2 użyj powrotu karetki.

To po prostu pozostawi wiele nieczytelnych białych znaków (chyba że stworzysz wtyczkę IDE do kodowania / dekodowania w locie).

Nigdy nawet tego nie próbowałem, z oczywistych powodów i ty też nie powinieneś.

Roy Prins
źródło
12

Używamy strip-json-commentsdo naszego projektu. Obsługuje coś takiego:

/*
 * Description 
*/
{
    // rainbows
    "unicorn": /* ❤ */ "cake"
}

Wystarczy npm install --save strip-json-commentszainstalować i używać go w następujący sposób:

var strip_json_comments = require('strip-json-comments')
var json = '{/*rainbows*/"unicorn":"cake"}';
JSON.parse(strip_json_comments(json));
//=> {unicorn: 'cake'}
Radość
źródło
Zauważ, że jsonnie jest już prawidłowym JSON, jeśli zawiera te komentarze dotyczące poprawności.
Roy Prins,
12

W moim przypadku potrzebuję użyć komentarzy do celów debugowania, przed wyjściem struktury JSON. Dlatego postanowiłem użyć informacji debugowania w nagłówku HTTP, aby uniknąć uszkodzenia klienta:

header("My-Json-Comment: Yes, I know it's a workaround ;-) ");

Wpisz opis zdjęcia tutaj

WilliamK
źródło
12

JSON nie zezwala na komentarze jako takie. Rozumowanie jest całkowicie głupie, ponieważ można użyć samego JSON do tworzenia komentarzy, co całkowicie eliminuje rozumowanie i ładuje przestrzeń danych analizatora składni bez żadnego uzasadnionego powodu dla dokładnie tego samego wyniku i potencjalnych problemów, takich jak: JSON plik z komentarzami.

Jeśli spróbujesz wstawić komentarze ( na przykład przy użyciu //lub /* */lub #), niektóre analizatory składni zakończą się niepowodzeniem, ponieważ nie jest to ściśle zgodne ze specyfikacją JSON. Więc nigdy nie powinieneś tego robić.

Oto na przykład, gdy mój system manipulacji obrazem zapisał notacje obrazu i niektóre podstawowe sformatowane (komentarz) informacje na ich temat (na dole):

{
    "Notations": [
        {
            "anchorX": 333,
            "anchorY": 265,
            "areaMode": "Ellipse",
            "extentX": 356,
            "extentY": 294,
            "opacity": 0.5,
            "text": "Elliptical area on top",
            "textX": 333,
            "textY": 265,
            "title": "Notation 1"
        },
        {
            "anchorX": 87,
            "anchorY": 385,
            "areaMode": "Rectangle",
            "extentX": 109,
            "extentY": 412,
            "opacity": 0.5,
            "text": "Rect area\non bottom",
            "textX": 98,
            "textY": 385,
            "title": "Notation 2"
        },
        {
            "anchorX": 69,
            "anchorY": 104,
            "areaMode": "Polygon",
            "extentX": 102,
            "extentY": 136,
            "opacity": 0.5,
            "pointList": [
                {
                    "i": 0,
                    "x": 83,
                    "y": 104
                },
                {
                    "i": 1,
                    "x": 69,
                    "y": 136
                },
                {
                    "i": 2,
                    "x": 102,
                    "y": 132
                },
                {
                    "i": 3,
                    "x": 83,
                    "y": 104
                }
            ],
            "text": "Simple polygon",
            "textX": 85,
            "textY": 104,
            "title": "Notation 3"
        }
    ],
    "imageXW": 512,
    "imageYW": 512,
    "imageName": "lena_std.ato",
    "tinyDocs": {
        "c01": "JSON image notation data:",
        "c02": "-------------------------",
        "c03": "",
        "c04": "This data contains image notations and related area",
        "c05": "selection information that provides a means for an",
        "c06": "image gallery to display notations with elliptical,",
        "c07": "rectangular, polygonal or freehand area indications",
        "c08": "over an image displayed to a gallery visitor.",
        "c09": "",
        "c10": "X and Y positions are all in image space. The image",
        "c11": "resolution is given as imageXW and imageYW, which",
        "c12": "you use to scale the notation areas to their proper",
        "c13": "locations and sizes for your display of the image,",
        "c14": "regardless of scale.",
        "c15": "",
        "c16": "For Ellipses, anchor is the  center of the ellipse,",
        "c17": "and the extents are the X and Y radii respectively.",
        "c18": "",
        "c19": "For Rectangles, the anchor is the top left and the",
        "c20": "extents are the bottom right.",
        "c21": "",
        "c22": "For Freehand and Polygon area modes, the pointList",
        "c23": "contains a series of numbered XY points. If the area",
        "c24": "is closed, the last point will be the same as the",
        "c25": "first, so all you have to be concerned with is drawing",
        "c26": "lines between the points in the list. Anchor and extent",
        "c27": "are set to the top left and bottom right of the indicated",
        "c28": "region, and can be used as a simplistic rectangular",
        "c29": "detect for the mouse hover position over these types",
        "c30": "of areas.",
        "c31": "",
        "c32": "The textx and texty positions provide basic positioning",
        "c33": "information to help you locate the text information",
        "c34": "in a reasonable location associated with the area",
        "c35": "indication.",
        "c36": "",
        "c37": "Opacity is a value between 0 and 1, where .5 represents",
        "c38": "a 50% opaque backdrop and 1.0 represents a fully opaque",
        "c39": "backdrop. Recommendation is that regions be drawn",
        "c40": "only if the user hovers the pointer over the image,",
        "c41": "and that the text associated with the regions be drawn",
        "c42": "only if the user hovers the pointer over the indicated",
        "c43": "region."
    }
}
Fyngyrz
źródło
Link do „rozumowania” jest zepsuty. Czy jest szansa na znalezienie aktualnego linku do niego?
Don Hatch,
Don niestety Google zabił system mediów społecznościowych, który zawierał post; Nie mam pojęcia, dokąd poszedł oryginalny plakat, jeśli gdziekolwiek. Zabiję link w powyższych informacjach, aby usunąć niejednoznaczność. Dzięki.
fyngyrz
Rozumowanie nie jest głupie i właśnie to udowodniłeś. Implementowanie komentarzy jako tagów pozwala zachować interoperacyjność . To jest dokładnie to, dlaczego chciał Crockforda komentarzy być analizowany jako znaczniki. Teraz wszystko jest tylko tagiem i parsowane w ten sam sposób .
Dominic Cerisano,
Jeśli specyfikacja mówi, że „linia zaczynająca się od # jest komentarzem”, to byłaby to w pełni interoperacyjna. Na obecnym etapie, oba komentarze ładują przestrzeń analizatora składni, ponieważ są one ważnymi przeanalizowanymi elementami, a nie rozumiane jako komentarze, i mogą być różne dla każdego istniejącego pliku .json. Podczas gdy (na przykład) specyfikacja mówi „wiersze zaczynające się od # są komentarzami”, to parsery mogą pomijać te wiersze bez parsowania (szybciej) i nie ładować przestrzeni parsera (lepsze wykorzystanie pamięci.) Brak korzyści w ogóle z braku komentarzy w .json, tylko minusy.
fyngyrz
11

Aby pociąć element JSON na części, dodaję linie „obojętnego komentarza”:

{

"#############################" : "Part1",

"data1"             : "value1",
"data2"             : "value2",

"#############################" : "Part2",

"data4"             : "value3",
"data3"             : "value4"

}
Chris
źródło
15
Emulowałeś strukturę pliku INI w JSON. Proszę, odłóż swój Złoty Młot.
Artur Czajka
4
RFC mówi „Nazwy w obiekcie POWINNY być unikalne”. Zobacz także osobę, która ma błąd podczas analizowania JSON, jak wyżej: stackoverflow.com/questions/4912386/…
William Entriken
Jeśli używasz schematu do sprawdzania poprawności JSON, może się nie powieść z powodu dodatkowych pól.
gregsdennis
1
Jeśli jesteś naprawdę zdeterminowany, aby dodać komentarze do JSON, sensowniejsze byłoby zrobienie czegoś takiego: { "comment-001":"This is where you do abc...", "comment-002":"This is where you do xyz..." } Dzięki temu nazwa będzie unikalna i możesz dodać dowolną wartość ciągu. To wciąż kludge, ponieważ komentarze nie powinny być częścią twojego JSON. Jako kolejną alternatywę, dlaczego nie dodać komentarzy przed lub po JSON, ale nie w jego obrębie?
Jazimov,