Czy komentarze mogą być używane w JSON?

Nie , komentarze formularza //… LUB {[1] } są niedozwolone w JSON. Odpowiedź jest oparta na:

• http://www.json.org
• RFC 4627 : Typ nośnika application/json dla JavaScript Object Notation (JSON)
• RFC 7159 format wymiany danych JavaScript Object Notation (JSON) - Obsoletes: 4627, 7158

Dołącz komentarze, jeśli wybierzesz; usuń je za pomocą minifier przed analizowaniem lub transmitowaniem.

Właśnie wypuściłem JSON.minify() który usuwa komentarze i spacje z bloku JSON i czyni go poprawnym JSON, który można przetwarzać. Więc możesz go użyć w następujący sposób:

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

Kiedy go opublikowałem, miałem ogromny zapał ludzi nie zgadzających się nawet z jego pomysłem, więc zdecydowałem, że napiszę obszerny wpis na blogu, dlaczego komentarze sprawiają, że sens w JSON . Zawiera ten znamienny komentarz od twórcy JSON:

Załóżmy, że używasz JSON do przechowywania plików konfiguracyjnych, które chcesz dodać do adnotacji. Śmiało i wstaw wszystkie komentarze, które lubisz. Następnie przeprowadź go przez JSMin przed przekazaniem go do parsera JSON. Douglas Crockford, 2012

Miejmy nadzieję, że to pomoże tym, którzy nie zgadzają się z tym, dlaczego JSON.minify () może się przydać.

Komentarze zostały usunięte z JSON by design.

Usunąłem komentarze z JSON, ponieważ widziałem, że ludzie używają ich do przechowywania dyrektyw parsujących, co zniszczyłoby interoperacyjność. Wiem, że Brak komentarzy niektórych zasmuca, ale nie powinien.

Załóżmy, że używasz JSON do przechowywania plików konfiguracyjnych, które chcesz dodać do adnotacji. Śmiało i wstaw wszystkie komentarze, które lubisz. Następnie przeprowadź go przez JSMin, zanim przekażesz go swojemu Parser JSON.

Source: Public statement by Douglas Crockford on G+

ZASTRZEŻENIE: GWARANCJA JEST NIEWAŻNA

Jak już wspomniano, ten hack wykorzystuje implementację spec. Nie wszystkie parsery JSON zrozumieją ten rodzaj JSON. Parsery strumieniowe w szczególności dławią.

Znalazłem mały hack, który pozwala na umieszczanie komentarzy w pliku JSON, który nie wpłynie na analizowanie lub modyfikowanie w jakikolwiek sposób reprezentowanych danych.

Wygląda na to, że deklarując obiekt literalnie, można podać dwie wartości tym samym kluczem, a ostatnia ma pierwszeństwo. Wierz lub nie, ale okazuje się, że parsery JSON działają w ten sam sposób. Możemy więc użyć tego do tworzenia komentarzy w źródłowym JSON, które nie będą obecne w przetworzonej reprezentacji obiektu.

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

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

{
  "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 to valid JSON . Jeśli to przeanalizujesz, otrzymasz obiekt w ten sposób:

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

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

JSON nie obsługuje komentarzy. Nigdy też nie zamierzano go używać do plików konfiguracyjnych, w których potrzebne byłyby komentarze.

Hjson jest formatem pliku konfiguracyjnego dla ludzi. Luźna składnia, mniej błędów, więcej komentarzy.

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

Nie możesz. przynajmniej to moje doświadczenie z szybkiego spojrzenia na json.org .

JSON ma swoją składnię zwizualizowaną na tej stronie. Nie ma żadnych uwag o komentarzach.

Rozważ użycie YAML. Jest to prawie superset JSON (praktycznie wszystkie poprawne JSON jest poprawne YAML) i pozwala na komentarze.

Powinieneś zamiast tego napisać Schemat JSON . Schemat JSON jest obecnie proponowanym projektem specyfikacji internetowej. Oprócz dokumentacji, schemat może być również używany do walidacji 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 description .

Jeśli używasz Jackson jako parser JSON, to w ten sposób włączasz go, aby zezwalał na komentarze:

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

Wtedy możesz mieć komentarze takie jak:

{
  key: "value" // comment
}

I możesz również mieć komentarze zaczynające się od # poprzez ustawienie:

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);    

Ale ogólnie (tak jak wcześniej) spec nie zezwala na komentarze.

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

// 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 nie sprawdza tego. Komentarze są więc rozszerzeniem specyficznym dla parsera, a nie standardem.

Kolejnym parserem jest JSON5 .

Alternatywa dla JSON TOML .

Oto co znalazłem w dokumentacji Google Firebase , która pozwala umieszczać komentarze 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"
}

Sorry, we can ' t use comments in JSON... Zobacz diagram składni dla JSON on JSON.org .

Douglas Crockford mówi " Dlaczego usunął komentarze w JSON i zapewnia alternatywny sposób, aby to zrobić":

Usunąłem komentarze z JSON, bo widziałem, że ludzie używają ich do posiadać dyrektywy parsujące. praktyka, która zniszczyłaby interoperacyjność. Wiem, że Brak komentarzy sprawia, że niektórzy smutne, ale nie powinno.

Przypuśćmy używasz JSON do przechowywania plików konfiguracyjnych, które chciałbym dodać adnotację. Śmiało i wstaw wszystkie komentarze, które lubisz. Następnie przeprowadź go przez JSMin przed przekazaniem go do parsera JSON.

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

Odpowiedź: to byłby jeden liner. Jeśli to zrobisz, pliki JSON mogą być używane jako pliki konfiguracyjne.

Jeśli używasz Newtonsoft.Biblioteka Json z ASP.NET aby przeczytać / deserializować możesz użyć komentarzy w treści JSON:

/ / "name": "string"

/ / "id": int

LUB

/* to jest

Komentarz przykład * /

PS: Komentarze jednoliniowe są obsługiwane tylko z 6 + wersjami Newtonsoft Json.

Dodatkowa uwaga dla osób, które nie potrafią myśleć po wyjęciu z pudełka: używam formatu JSON dla podstawowe ustawienia w ASP.NET zrobiłem aplikację internetową. Odczytałem plik, przekonwertowałem go do obiektu Ustawienia za pomocą biblioteki Newtonsoft i używałem go w razie potrzeby.

Wolę pisać komentarze o każdym indywidualnym ustawieniu w samym pliku JSON i naprawdę nie obchodzi mnie integralność formatu JSON, o ile biblioteka, której używam, jest z nią w porządku.

Myślę ,że jest to "łatwiejszy w użyciu/zrozumieniu" sposób niż tworzenie oddzielnych " ustawień.Plik README i objaśnienie ustawień w nim.

Jeśli masz problem z tego rodzaju użytkowaniem; przykro mi, genie nie ma lampy. Ludzie znajdą inne zastosowania dla formatu JSON i nic na to nie poradzisz.

Ideą JSON jest zapewnienie prostej wymiany danych między aplikacjami. Są one zazwyczaj oparte na sieci web, 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, chociaż dane te muszą być oczywiście ignorowane lub przetwarzane przez kod parsujący.

To wszystko powiedziane, nie jest intencją, aby plik JSON zawierał komentarze w tradycyjny sens. To powinny być tylko dane.

Właśnie natknąłem się na to dla plików konfiguracyjnych. Nie chcę używać XML (wyrazisty, graficznie, brzydki, trudny do odczytania), ani formatu "ini" (bez hierarchii, bez prawdziwego standardu itp.) lub w formacie Java "Properties" (np.ini).

JSON może zrobić wszystko, co może, ale jest o wiele mniej gadatliwy i bardziej czytelny dla człowieka - a parsery są łatwe i wszechobecne w wielu językach. To tylko drzewo danych. Ale komentarze poza pasmem są często koniecznością dokumentowania" domyślnych " konfiguracji i na przykład. Konfiguracje nigdy nie mają być "pełnymi dokumentami", ale drzewami zapisanych danych, które mogą być czytelne dla człowieka w razie potrzeby.

Myślę, że można użyć "#": "comment", dla "poprawnego" JSONA.

JSON nie obsługuje komentarzy natywnie, ale możesz stworzyć własny dekoder lub przynajmniej preprocesor, aby usunąć komentarze ,to jest całkowicie w porządku(tak długo, jak po prostu ignorujesz komentarze i nie używasz ich do kierowania, jak aplikacja powinna przetwarzać dane JSON).

JSON nie posiada komentarzy Koder JSON nie może wysyłać komentarzy. Dekoder JSON może akceptować i ignorować komentarze.

Komentarzy nigdy nie należy używać do przekazywania czegokolwiek sensownego. To jest do czego służy JSON.

Cf: Douglas Crockford, autor JSON spec .

To zależy od twojej Biblioteki JSON. Json.NET obsługuje komentarze w stylu JavaScript, /* commment */.

Zobacz kolejne pytanie o przepełnienie stosu .

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

Jeśli ludzie mają silne powody, aby mieć komentarze w JSON podczas przekazywania danych (czy ważne, czy nie), to prawdopodobnie JSON można podzielić na dwa:

• JSON-COM: JSON on the wire, lub zasady, które mają zastosowanie podczas przesyłania danych JSON.
• JSON - DOC: dokument JSON, lub JSON w plikach lub lokalnie. Reguły określające poprawny JSON dokument.

JSON-DOC będzie zezwalał na komentarze i mogą istnieć inne drobne różnice, takie jak obsługa białych znaków. Parsery mogą łatwo konwertować z jednej specyfikacji do drugiej.

W odniesieniu do uwagi dokonanej przez Douglasa Crockforda w tej kwestii (do której odwołuje się @Artur Czajka)

Załóżmy, że używasz JSON do przechowywania plików konfiguracyjnych, które chcesz dodać do adnotacji. Śmiało i wstaw wszystkie komentarze, które lubisz. Następnie przełącz go przez JSMin przed przekazuję to parserowi JSON.

Mówimy o ogólnym problemie z plikiem konfiguracyjnym (cross language/platform), a on odpowiada za pomocą specyficznego narzędzia JS!

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

Druga kwestia to interoperacyjność. Załóżmy, że masz bibliotekę, API lub jakikolwiek podsystem, który ma powiązane z nim pliki konfiguracyjne lub dane. A ten podsystem jest dostęp z różnych języków. Więc mówisz ludziom: przy okazji nie zapomnij usunąć komentarzy z plików JSON przed przekazaniem ich do parsera!

Dojo Toolkit JavaScript Toolkit (przynajmniej od wersji 1.4), pozwala na dołączanie komentarzy do JSON. Komentarze mogą mieć format /* */. Dojo Toolkit zużywa JSON poprzez wywołanie dojo.xhrGet().

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 wyborem ostatecznej opcji.

Jeśli używasz JSON5 {[2] } możesz dodawać komentarze.

JSON5 jest proponowanym rozszerzeniem do JSON , które ma na celu ułatwienie ludziom pisania i utrzymywania ręcznie. Robi to poprzez dodanie kilku minimalnych funkcji składni bezpośrednio z ECMAScript 5.

Ty możesz mieć komentarze w JSONP , ale nie w czystym JSON. Właśnie spędziłem godzinę starając się, aby mój program działał na tym przykładzie 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 moim folderze lokalnym, nie było żadnych problemów z Polityką samego pochodzenia , więc zdecydowałem się użyć czystego JSON... i oczywiście $.getJSON był bezgłośnie z powodu komentarzy.

W końcu wysłałem ręczne żądanie HTTP na powyższy adres i zdałem sobie sprawę, że content-type to text/javascript ponieważ, cóż, JSONP zwraca czysty JavaScript. W tym przypadku komentarze są dozwolone. Ale moja aplikacja zwróciła content-type application/json, więc musiałem usunąć komentarze.

JSON nie jest protokołem ramkowym . Jest to format wolny od języka . Tak więc format komentarza nie jest zdefiniowany dla JSON.

Jak Wiele osób zasugerowało, istnieją pewne sztuczki, na przykład zduplikowane klucze lub określony klucz _comment, których możesz użyć. To zależy od Ciebie.

To jest"czy możesz" pytanie. A oto "Tak" odpowiedź.

Nie, nie powinieneś używać duplikatywnych elementów obiektu do umieszczania danych kanału bocznego w kodowaniu JSON. (Zobacz "nazwy wewnątrz obiektu powinny być unikalne" w RFC ).

I tak, możesz wstawić komentarze wokół JSON , który możesz przeanalizować.

Ale jeśli chcesz sposób wstawiania i wyodrębniania dowolnych danych kanału bocznego do poprawnego JSON, oto odpowiedź. Korzystamy z niepowtarzalnej reprezentacji danych w kodowaniu JSON. Jest to dozwolone^* w sekcji drugiej RFC pod "białe znaki są dozwolone przed lub po którymkolwiek z sześciu znaków strukturalnych".

^*RFC stwierdza tylko "białe znaki są dozwolone przed lub po którymkolwiek z sześciu znaków strukturalnych" , nie wspominając wyraźnie o łańcuchach, liczbach," false"," true "I"null". Pominięcie to jest ignorowane we wszystkich wdrożenia.

Najpierw canonicalize swój JSON przez minifikację go:

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

Następnie Zakoduj swój komentarz w binarnym:

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

Następnie przeciągnij swój binarny:

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

Oto twoje wyjście:

$jsonWithComment = $steg . $jsonMin;

Używamy strip-json-comments do naszego projektu. Obsługuje coś w rodzaju:

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

Po Prostu npm install --save strip-json-comments aby zainstalować i używać go jak:

var strip_json_comments = require('strip-json-comments')
var json = '{/*rainbows*/"unicorn":"cake"}';
JSON.parse(strip_json_comments(json));
//=> {unicorn: 'cake'}

Aby wyciąć element JSON na części dodaję linie "dummy comment":

{

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

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

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

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

}

Jest dobre rozwiązanie (hack), które jest poprawne JSON. Wystarczy zrobić ten sam klucz dwa razy (lub więcej). Na przykład:

{
  "param" : "This is the comment place",
  "param" : "This is value place",
}

Więc JSON zrozumie to jako:

{
  "param" : "This is value place",
}

Westchnienie. Dlaczego po prostu nie dodawać pól, np.

{
    "note1" : "This demonstrates the provision of annotations within a JSON file",
    "field1" : 12,
    "field2" : "some text",

    "note2" : "Add more annotations as necessary"
}

Upewnij się, że Twoje nazwy "notex" nie są sprzeczne z żadnymi prawdziwymi polami.

Autor JSON chce, abyśmy umieścili komentarze w JSON, ale usunęli je przed ich analizą (Zobacz link dostarczony przez Michaela Burra.) Jeśli JSON powinien mieć komentarze, dlaczego nie ujednolicić ich i pozwolić parserowi JSON wykonać zadanie? Nie zgadzam się z logiką, ale niestety taki jest standard. Używanie rozwiązania YAML zgodnie z sugestiami innych jest dobre, ale wymaga zależności od biblioteki.

Jeśli chcesz usunąć komentarze, ale nie chcesz mieć zależności od biblioteki, tutaj jest to rozwiązanie dwuliniowe, które działa dla komentarzy W Stylu C++, ale może być dostosowane do innych:

var comments=new RegExp("//.*", 'mg');
data = JSON.parse(fs.readFileSync(sample_file, 'utf8').replace(comments, ''));

Zauważ, że to rozwiązanie może być używane tylko wtedy, gdy możesz być pewien, że dane JSON nie zawierają inicjatora komentarza, np. ('//').

Innym sposobem osiągnięcia parsowania JSON, usuwania komentarzy i braku dodatkowej biblioteki, jest ocena JSON w interpreterze JS. Zastrzeżenie z tym podejściem, oczywiście, jest to, że chcesz tylko ocenić nieskażone dane (nie niezaufane wejście użytkownika.) Oto przykład takiego podejścia w node.js -- kolejne zastrzeżenie, poniższy przykład odczyta dane tylko raz, a następnie zostaną zbuforowane:

data = require(fs.realpathSync(doctree_fp));