Können Kommentare in JSON verwendet werden?

7608

Kann ich Kommentare in einer JSON-Datei verwenden? Wenn das so ist, wie?

Michael Gundlach
quelle
153
@StingyJack: Um Dinge zu erklären, die möglicherweise nicht offensichtlich sind oder was auch immer man sonst mit Kommentaren tun könnte. Ich jedenfalls habe oft Kommentare in Datendateien. XML, INI-Dateien und viele andere Formate enthalten Bestimmungen für Kommentare.
Michael Burr
24
Wenn Sie sich wie ich gefragt haben, ob //commentsder spezifische Anwendungsfall einer Sublime Text-Konfigurationsdatei in Ordnung ist, lautet die Antwort Ja (ab Version 2). Sublime Text wird sich zumindest nicht darüber beschweren, während es sich {"__comment": ...}in der Konsole beschweren wird , da es sich um ein unerwartetes Feld handelt.
Driftcatcher
8
und vielleicht ist dies ein Grund, warum TOML erstellt wurde ..
Alex Nolasco
10
Etwas noobisch, aber ich habe auch versucht, // für Kommentare in JSON zu verwenden. Jetzt ist mir klar, dass es ausschließlich für den Austausch / Austausch verwendet wird. Seufzer! Ich kann nicht mehr kommentieren :(. Das Leben ist zum Scheitern verurteilt!
Sid
12
JSON5 unterstützt Kommentare: stackoverflow.com/a/7901053/108238
schoetbi

Antworten:

5593

Nein.

Der JSON sollte alle Daten sein, und wenn Sie einen Kommentar einfügen, sind es auch Daten.

Möglicherweise haben Sie ein bestimmtes Datenelement namens "_comment"(oder etwas anderes), das von Apps, die die JSON-Daten verwenden, ignoriert wird.

Sie sollten den Kommentar wahrscheinlich besser in den Prozessen haben, die den JSON generieren / empfangen, da sie im Voraus wissen sollen, wie die JSON-Daten aussehen werden, oder zumindest deren Struktur.

Aber wenn Sie sich entschieden haben:

{
   "_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
quelle
232
Es könnte sich lohnen, eine Art Präfix für den tatsächlichen Kommentar zu haben, falls es jemals ein gültiges Feld mit dem Namen Kommentar gibt:"__comment":"comment text goes here...",
Rob Fonseca-Ensor
19
Übrigens unterstützt die JSON- Bibliothek für Java google-gson Kommentare.
Centic
11
Was ist, wenn ich einen separaten Kommentar zu den Accronymund AbbrevEigenschaften haben möchte ? Ich habe dieses Muster schon einmal verwendet, aber aufgehört, da es mir das nicht erlaubt. Es ist ein Hack. Vielleicht, wenn ich __comment__stattdessen einen Eigenschaftsnamen voranstelle . Das ist "__comment__Abbrev", immer noch ein Hack, aber ich möchte alle Eigenschaften kommentieren
Juan Mendes
41
Sie könnten auch "//" verwenden: Dies sieht nativer aus und ist immer noch im selben Elternteil wiederholbar
smnbbrv
4
Wenn JSON für vom Menschen beabsichtigte Konfigurationsdateien verwendet wird, sollten diese mit Anmerkungen versehen werden, damit der Mensch sie besser versteht. Kommentiert, eine solche Datei ist nicht mehr gültig JSON, aber es gibt Lösungen. Zum Beispiel unterstützt Googles GYP Kommentare im # -Stil. Mit JSON.Minify können Sie Kommentare im C / C ++ - Stil aus Ihrer Eingabedatei verwerfen.
27етър Петров
1841

Nein , Kommentare des Formulars //…oder /*…*/sind in JSON nicht zulässig. Diese Antwort basiert auf:

  • http://www.json.org
  • RFC 4627 : Der application/jsonMedientyp für die JavaScript-Objektnotation (JSON)
  • RFC 8259 Das JSON-Datenaustauschformat (JavaScript Object Notation) (ersetzt die RFCs 4627, 7158, 7159)
stakx - nicht mehr beitragen
quelle
67
Wenn Sie Ihren JSON mit Kommentaren versehen möchten (wodurch JSON ungültig wird), minimieren Sie ihn, bevor Sie ihn analysieren oder übertragen. Crockford selbst hat dies 2012 im Zusammenhang mit Konfigurationsdateien anerkannt.
Toolbear
25
@alkuzad: Wenn es um die formalen Grammatiken kommt, muss es etwas sein , das ausdrücklich sagt , dass sie sind erlaubt, nicht umgekehrt. Nehmen Sie zum Beispiel die Programmiersprache Ihrer Wahl: Nur weil eine gewünschte (aber fehlende) Funktion nicht explizit verboten ist, bedeutet dies nicht, dass Ihr Compiler sie auf magische Weise erkennt.
stakx - nicht mehr beitragen
5
Ja. Das JSON-Format hat viel Totraum zwischen Elementen und ist in diesen Regionen raumunempfindlich. Es gibt also keinen Grund, warum Sie dort keine ein- oder mehrzeiligen Kommentare haben können. Viele Parser und Minifier unterstützen auch JSON-Kommentare. Stellen Sie daher sicher, dass Ihr Parser sie unterstützt. JSON wird häufig für Anwendungsdaten und Konfigurationseinstellungen verwendet, daher sind jetzt Kommentare erforderlich. Die "offizielle Spezifikation" ist eine nette Idee, aber sie ist unzureichend und veraltet, also schade. Minimieren Sie Ihren JSON, wenn Sie Bedenken hinsichtlich der Größe oder Leistung der Nutzdaten haben.
Triynko
58
Obwohl Ihre Antwort absolut richtig ist, sollte gesagt werden, dass dies BS ist. Bei so vielen Endbenutzern, die auf die Notwendigkeit einer JSON-Konfiguration stoßen, sind Kommentare äußerst hilfreich. Nur weil einige Zinnfolienhüte entschieden haben, dass JSON maschinenlesbar ist und immer maschinenlesbar sein muss und die Tatsache ignoriert, dass Menschen es lesen müssen, ist dies imho eine Travestie von Kleinmut.
cmroanirgo
18
@cmroanirgo: Sie sind offensichtlich nicht die Ersten, die sich über diese Einschränkung von JSON beschweren. Deshalb haben wir Parser, die stillschweigend Kommentare zulassen, und andere Formate wie YAML und JSON5. Dies ändert jedoch nichts an der Tatsache, dass JSON das ist, was es ist. Ich finde es eher interessant, dass Leute JSON für Zwecke verwendet haben, bei denen es angesichts der fraglichen Einschränkung offensichtlich überhaupt nicht ausreichte. Beschuldigen Sie nicht das JSON-Format. beschuldigen wir uns, darauf zu bestehen, es dort zu verwenden, wo es nicht besonders gut passt.
stakx - nicht mehr beitragen
802

Fügen Sie Kommentare hinzu, wenn Sie möchten. Entfernen Sie sie mit einem Minifier, bevor Sie sie analysieren oder senden.

Ich habe gerade JSON.minify () veröffentlicht, das Kommentare und Leerzeichen aus einem JSON-Block entfernt und es zu einem gültigen JSON macht, das analysiert werden kann. Sie können es also wie folgt verwenden:

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

Als ich es veröffentlichte, gab es eine große Gegenreaktion von Leuten, die nicht einmal mit der Idee einverstanden waren. Deshalb beschloss ich, einen umfassenden Blog-Beitrag darüber zu schreiben, warum Kommentare in JSON sinnvoll sind . Es enthält diesen bemerkenswerten Kommentar des Erstellers von JSON:

Angenommen, Sie verwenden JSON, um Konfigurationsdateien zu speichern, die Sie mit Anmerkungen versehen möchten. Fügen Sie alle gewünschten Kommentare ein. Führen Sie es dann durch JSMin, bevor Sie es an Ihren JSON-Parser übergeben. - Douglas Crockford, 2012

Hoffentlich ist das hilfreich für diejenigen, die nicht damit einverstanden sind, warum JSON.minify () nützlich sein könnte.

Kyle Simpson
quelle
153
Das einzige Problem, das ich mit JSON.minify () habe, ist, dass es wirklich sehr, sehr langsam ist. Also habe ich meine eigene Implementierung erstellt, die dasselbe tut: gist.github.com/1170297 . Bei einigen großen Testdateien dauert Ihre Implementierung 74 Sekunden und meine 0,06 Sekunden.
WizKid
56
Es wäre großartig, wenn Sie den vorgeschlagenen alternativen Algorithmus für JSON.minify () an das Github-Repo senden könnten, damit er auf alle unterstützten langs portiert werden kann: github.com/getify/json.minify
Kyle Simpson
16
@MiniGod Ich habe Dougs Gedanken zu diesem Thema schon oft gehört. Ich habe sie vor langer Zeit in meinem Blog-Beitrag angesprochen
Kyle Simpson
18
@ MarnenLaibow-Koser Es gibt immer noch gültige Verwendungen für Kommentare, selbst für die Verwendung von Datenströmen (oder sogar Paketen): Die Einbeziehung von Diagnosemetadaten wie Erstellungszeit oder Quellen ist bei XML üblich und auch für JSON-Daten durchaus sinnvoll. Die Argumente gegen Kommentare sind oberflächlich, und jedes Textdatenformat sollte Kommentare zulassen, unabhängig von der implizierten beabsichtigten Verwendung (keine Spezifikation deutet darauf hin, dass JSON nicht anderweitig verwendet werden kann, fwiw)
StaxMan
18
Wenn JSON eine universelle Akzeptanz haben soll (was im Grunde genommen der Fall ist), sollte es eine universelle Anwendung haben. Beispiel: JSON kann als Anwendungskonfigurationsdatei dienen. Diese Anwendung würde Kommentare wünschen.
Eggmatters
441

Kommentare wurden von Entwurf aus JSON entfernt.

Ich habe Kommentare aus JSON entfernt, weil ich gesehen habe, dass Leute sie zum Parsen von Anweisungen verwenden, eine Praxis, die die Interoperabilität zerstört hätte. Ich weiß, dass das Fehlen von Kommentaren einige Leute traurig macht, aber es sollte nicht.

Angenommen, Sie verwenden JSON, um Konfigurationsdateien zu speichern, die Sie mit Anmerkungen versehen möchten. Fügen Sie alle gewünschten Kommentare ein. Führen Sie es dann durch JSMin, bevor Sie es an Ihren JSON-Parser übergeben.

Quelle: Öffentliche Erklärung von Douglas Crockford zu G +

Artur Czajka
quelle
198
Ich dachte, JSON sollte besser lesbar sein als beispielsweise XML? Kommentare dienen der Lesbarkeit.
intrepidis
25
Wie auch immer, Sie könnten ungezogen sein und Parsing-Anweisungen in JSON hinzufügen: {"__directives": {"# n #": "DateTime.Now"}, "validdate": "# n #"} ... Es sieht aus wie YAML nach vorne ist der Weg , dann ...
intrepidis
73
Persönliche Meinung: Kommentare nicht zulassen ist lahm. Ich hatte keine andere Wahl, als einen nicht standardmäßigen JSON-Parser zu erstellen, der Kommentare ignoriert, um meine Konfigurationsdateien zu dekodieren.
caiosm1005
17
@ArturCzajka Ich mag die Tatsache immer noch nicht, dass JSON keine Kommentare unterstützt, aber ich habe INI ausprobiert und ich muss zugeben, dass es viel sinnvoller ist, sie über JSON für Konfigurationsdateien zu verwenden. Vielen Dank für die Antwort und hoffentlich ändern mehr Leute ihre Meinung, wenn sie dieses Gespräch lesen. (Einen Parser zu machen war sowieso eher eine Übung :)
caiosm1005
77
Das ist so, als müssten alle Fahrräder Stützräder haben, weil manche Leute nicht Fahrrad fahren können. Das Entfernen eines wichtigen Features, weil dumme Leute es missbrauchen, ist schlechtes Design. Ein Datenformat sollte der Benutzerfreundlichkeit Vorrang vor der Idiotensicherheit einräumen.
Phil Goetz
205

HAFTUNGSAUSSCHLUSS: IHRE GARANTIE IST NICHTIG

Wie bereits erwähnt, nutzt dieser Hack die Implementierung der Spezifikation. Nicht alle JSON-Parser werden diese Art von JSON verstehen. Insbesondere Streaming-Parser werden ersticken.

Es ist eine interessante Kuriosität, aber Sie sollten es wirklich für nichts verwenden . Unten ist die ursprüngliche Antwort.


Ich habe einen kleinen Hack gefunden, mit dem Sie Kommentare in eine JSON-Datei einfügen können, die sich nicht auf das Parsen auswirken oder die dargestellten Daten in irgendeiner Weise ändern.

Es scheint, dass Sie beim Deklarieren eines Objektliteral zwei Werte mit demselben Schlüssel angeben können, wobei der letzte Vorrang hat. Ob Sie es glauben oder nicht, es stellt sich heraus, dass JSON-Parser genauso funktionieren. Damit können wir Kommentare im Quell-JSON erstellen, die in einer analysierten Objektdarstellung nicht vorhanden sind.

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

Wenn wir diese Technik anwenden, sieht Ihre kommentierte JSON-Datei möglicherweise folgendermaßen aus:

{
  "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]
}

Der obige Code ist gültiger JSON . Wenn Sie es analysieren, erhalten Sie ein Objekt wie das folgende:

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

Das heißt, es gibt keine Spur von Kommentaren und sie werden keine seltsamen Nebenwirkungen haben.

Viel Spaß beim Hacken!

p3drosola
quelle
150
Aus der Spezifikation : Die Namen innerhalb eines Objekts sollten eindeutig sein.
Quentin
113
"Alle Implementierungen gehen gleich damit um" - Das ist schwer zu beweisen.
Quentin
91
Die Reihenfolge der Elemente in JSON kann nicht garantiert werden. Das heißt, der "letzte" Gegenstand könnte sich ändern!
September 332
66
Dies verstößt eindeutig gegen die Spezifikation (siehe obige Kommentare). Tun Sie dies nicht. ietf.org/rfc/rfc4627.txt?number=4627
voidlogic
334
NEIN - was ist, wenn der Parser Streaming ist? Was ist, wenn der Parser es in ein Wörterbuch einliest, in dem die Schlüsselreihenfolge nicht definiert ist? töte dies mit Feuer .
DeanWombourne
183

JSON unterstützt keine Kommentare. Es war auch nie für Konfigurationsdateien vorgesehen, bei denen Kommentare erforderlich wären.

Hjson ist ein Konfigurationsdateiformat für Menschen. Entspannte Syntax, weniger Fehler, mehr Kommentare.

Hjson Intro

Unter hjson.org finden Sie JavaScript-, Java-, Python-, PHP-, Rust- , Go-, Ruby- und C # -Bibliotheken.

Laktak
quelle
13
Upvoted. Es ist offensichtlich eine gute Variante, die nicht offene konservative Menschen gerne hassen würden. Ich hoffe, dass Ihre Implementierung weiter bekannt wird - und vielleicht sogar populärer wird als das Original;) ​​Ich hoffe, dass jemand sie auch mit Ruby implementieren kann. @adelphus Die Sprache, die gut definiert ist, ist Ihre eigene Perspektive oder Meinung. Ein konservativer "Entwickler" zu sein, wenn Sie einer sind, beweist nicht, dass Sie besser sind, und Sie könnten noch schlimmer sein, wenn Sie sich auf engstem Raum einsperren. Beurteilen Sie Menschen nicht so leicht als schreckliche Entwickler.
konsolebox
7
Entschuldigung, @konsolebox. Vielleicht überdenken Sie Ihre Ansicht "Gut definierte JSON ist Ihre Meinung", nachdem Sie ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf gelesen haben. Es ist ein echter Standard und Entwickler implementieren ihre eigenen "speziellen" Versionen führt zu Fragmentierung, Verwirrung und viel Zeitverschwendung. Schauen Sie sich das Chaos an, das Webentwickler beim Schreiben von Code haben, nur weil jeder Browser leicht unterschiedliche Versionen von Standards implementiert. Die JSON-Sprache ist möglicherweise nicht perfekt, aber die Fragmentierung ist schlimmer. Und ja, das ist nur eine Meinung und Sie können nicht zustimmen.
Adelphus
22
Ich bewundere Ihren Kaugummi, aber Sie erfinden YAML irgendwie neu. Wenn Sie viel Flexibilität und menschliche Lesbarkeit wünschen, verwenden Sie YAML (eigentlich nicht: stackoverflow.com/questions/450399/… ) oder bleiben Sie bei kuriosem, aber eindeutigem JSON.
Toolbear
4
Ich finde, das benutzerfreundlichste Konfigurationsformat ist immer noch INI. Es ist unkompliziert und nicht sehr syntaxlastig. Dies macht es weniger einschüchternd für Benutzer, die nur ihre Zehen in den Konfigurationsteich tauchen.
Matt
14
Jedes Mal , wenn Sie json als Config müssen (wo Kommentare sind erforderlich) - benennen Sie Ihre Datei „Js“ statt „.json“ .. js kann natürlich jede gültige Json Objekt handhaben und zusätzlich können Kommentare behandeln .. Das ist der Grund , warum es "webpack.config.js" und nicht "webpack.config.json" (nun, es gibt noch viel mehr Gründe dafür in webpack: P)
jebbie
122

Erwägen Sie die Verwendung von YAML. Es ist fast eine Obermenge von JSON (praktisch alle gültigen JSONs sind gültige YAML) und es erlaubt Kommentare.

Marnen Laibow-Koser
quelle
12
@ g33kz0r Richtig, daher meine Beschreibung von YAML als nahezu oberste Menge von JSON.
Marnen Laibow-Koser
12
@NateS Viele Leute hatten bereits darauf hingewiesen, dass die Antwort nein war. Ich schlug einen besseren Weg vor, um das Ziel des OP zu erreichen. Das ist eine Antwort.
Marnen Laibow-Koser
5
Nachteil: Die yamlBibliothek wird nicht mit Python ausgeliefert.
Blutende Finger
6
@ marnen-laibow-koser: yup, es muss inkompetent gewesen sein, die verfügbaren YAML-Bibliotheken für Java und Perl zu verwenden und zu erwarten, dass die von beiden erzeugte YAML fehlerfrei von den anderen verwendet wird. Dass YAML-Interop ein Problem war, JSON-Interop jedoch nicht, erklärt sich vollständig aus meinem Mangel an Wissen.
Toolbear
3
@ marnen-laibow-koser, ein Format, das dasselbe mit einer einfacheren Spezifikation erreicht, ist besser. Ein pragmatisches Format mit perfekten Implementierungen ist besser als ein ideales Format mit unvollständigen Implementierungen. Nicht alle Schuld an fehlerhaften Bibliotheken liegt bei den Implementierern. Die YAML-Spezifikation ist lang, dicht und stumpf. Der Wikipedia-Eintrag nennt zwei Beispiele für Mehrdeutigkeiten. Wenn man einen Emitter zwischen einen Menschen und das Format stellen muss, um ihn vor Unklarheiten zu schützen, verliert das Format seinen menschenfreundlichen Anspruch. JSON beansprucht weniger und ist meistens dort erfolgreich, wo YAML mehr beansprucht und zu kurz kommt.
Toolbear
108

Das kannst du nicht. Zumindest ist das meine Erfahrung aus einem kurzen Blick auf json.org .

Die Syntax von JSON wird auf dieser Seite visualisiert. Es gibt keinen Hinweis zu Kommentaren.

Heiter
quelle
67

Kommentare sind kein offizieller Standard, obwohl einige Parser Kommentare im C ++ - Stil unterstützen. Eine, die ich benutze, ist JsonCpp . In den Beispielen gibt es dieses:

// 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 validiert dies nicht. Kommentare sind also eine parser-spezifische Erweiterung und kein Standard.

Ein weiterer Parser ist JSON5 .

Eine Alternative zu JSON TOML .

Eine weitere Alternative ist jsonc .

schoetbi
quelle
Groovy verfügt über einige integrierte Klassen für den Umgang mit JSON . JsonSlurper kann Kommentare verarbeiten. Natürlich sind Kommentare in der offiziellen Spezifikation nicht erlaubt, daher ist dieses Verhalten in jedem Parser nicht Standard und nicht portierbar.
Izrik
Newtonsoft Json.NET unterstützt auch Kommentare im C-Stil ohne Probleme
Max
66

Sie sollten stattdessen ein JSON-Schema schreiben . Das JSON-Schema ist derzeit eine vorgeschlagene Internet-Entwurfsspezifikation. Neben der Dokumentation kann das Schema auch zur Validierung Ihrer JSON-Daten verwendet werden.

Beispiel:

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

Sie können die Dokumentation mithilfe des Beschreibungsschemaattributs bereitstellen .

Verlosung
quelle
5
Ist das JSON-Schema aktiv? Es existiert, aber wird es von einer bekannten Bibliothek unterstützt?
Munhitsu
1
Ja, die Google-Gruppe json-schema ist ziemlich aktiv und ich würde JSV für eine gute JavaScript-Implementierung eines JSON-Schema-Validators empfehlen .
Verlosung
5
Dies hilft nur bei strukturierter Dokumentation, nicht bei Ad-hoc-Dokumentation
Juan Mendes
Wenn Sie Clojure verwenden (und ich bin sicher, dass Sie dies nicht tun), gibt es hier einen Open-Source-JSON-Schema-Parser mit angemessenem Funktionsumfang: github.com/bigmlcom/closchema
charleslparker
@Munhitsu Manatee.Json (.Net) unterstützt das JSON-Schema umfassend.
Gregsdennis
64

Wenn Sie Jackson als JSON-Parser verwenden, können Sie auf folgende Weise Kommentare zulassen:

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

Dann können Sie Kommentare wie diese haben:

{
  key: "value" // Comment
}

Und Sie können auch Kommentare haben, #indem Sie Folgendes einstellen:

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);

Im Allgemeinen (wie zuvor beantwortet) erlaubt die Spezifikation jedoch keine Kommentare.

Andrejs
quelle
50

Folgendes habe ich in der Google Firebase-Dokumentation gefunden , mit der Sie Kommentare in JSON einfügen können:

{
  "//": "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
quelle
Zu Ihrer Information, die Firebase-Echtzeitdatenbank erlaubt nicht die Verwendung von '/' in einem Schlüssel. Dies kann also eine nette Konvention für Ihren eigenen Gebrauch sein, aber Sie können sie nicht in Firebase
gutte
5
Diese Methode unterbricht einige Bibliotheken, für die der Schlüssel eindeutig sein muss. Ich arbeite um dieses Problem herum, indem ich die Kommentare nummeriere.
MovGP0
Guter Kommentar, ich fand diese Frage auf SO ... dieser Teil scheint nicht durch die Spezifikation stackoverflow.com/questions/21832701/…
Mana
4
Ich benutze es heutzutage eher so: {"// foo": "foo comment", "foo": "foo value", "// bar": "bar comment", "bar": "bar value"} Sie können ein Array für mehrere Kommentare verwenden: {"// foo": ["foo comment 1", "foo comment 2"], "foo": '' foo value "}
MovGP0
47

NEIN . JSON unterstützte früher Kommentare, diese wurden jedoch missbraucht und aus dem Standard entfernt.

Vom Schöpfer von JSON:

Ich habe Kommentare aus JSON entfernt, weil ich gesehen habe, dass Leute sie zum Parsen von Direktiven verwenden, eine Praxis, die die Interoperabilität zerstört hätte. Ich weiß, dass das Fehlen von Kommentaren einige Leute traurig macht, aber es sollte nicht. - Douglas Crockford, 2012

Die offizielle JSON-Site befindet sich unter JSON.org . JSON wird von ECMA International als Standard definiert . Es gibt immer ein Petitionsverfahren, um Standards zu überarbeiten. Es ist aus mehreren Gründen unwahrscheinlich, dass dem JSON-Standard Anmerkungen hinzugefügt werden.

JSON ist von Natur aus eine einfach rückentwickelte (vom Menschen analysierte) Alternative zu XML. Es wird sogar so weit vereinfacht, dass Anmerkungen nicht erforderlich sind. Es ist nicht einmal eine Auszeichnungssprache. Das Ziel ist Stabilität und Interoperabilität.

Jeder, der die "has-a" -Beziehung der Objektorientierung versteht, kann jede JSON-Struktur verstehen - das ist der springende Punkt. Es ist nur ein gerichteter azyklischer Graph (DAG) mit Knoten-Tags (Schlüssel / Wert-Paare), der eine nahezu universelle Datenstruktur darstellt.

Diese einzige erforderliche Annotation könnte "// Dies sind DAG-Tags" sein. Die Schlüsselnamen können so informativ wie erforderlich sein und eine beliebige semantische Arität ermöglichen.

Jede Plattform kann JSON mit nur wenigen Codezeilen analysieren. XML erfordert komplexe OO-Bibliotheken, die auf vielen Plattformen nicht funktionsfähig sind.

Anmerkungen würden JSON nur weniger interoperabel machen. Es gibt einfach nichts anderes hinzuzufügen, es sei denn, Sie benötigen wirklich eine Auszeichnungssprache (XML), und es ist Ihnen egal, ob Ihre persistierten Daten leicht analysiert werden können.

ABER wie der Schöpfer von JSON auch bemerkte, gab es immer Unterstützung für JS-Pipelines für Kommentare:

Fügen Sie alle gewünschten Kommentare ein. Führen Sie es dann durch JSMin, bevor Sie es an Ihren JSON-Parser übergeben. - Douglas Crockford, 2012

Dominic Cerisano
quelle
37

Wenn Ihre Textdatei, bei der es sich um eine JSON-Zeichenfolge handelt, von einem Programm gelesen wird, wie schwierig wäre es dann, Kommentare im C- oder C ++ - Stil zu entfernen, bevor Sie sie verwenden?

Antwort: Es wäre ein Einzeiler. Wenn Sie dies tun, können JSON-Dateien als Konfigurationsdateien verwendet werden.

John T. Vonachen
quelle
1
Wahrscheinlich der bisher beste Vorschlag, obwohl es immer noch ein Problem ist, Dateien als Austauschformat beizubehalten, da sie vor der Verwendung vorverarbeitet werden müssen.
Orbling
Ich bin damit einverstanden und habe einen JSON-Parser in Java geschrieben, der unter www.SoftwareMonkey.org verfügbar ist und genau das tut.
Lawrence Dol
2
Obwohl ich denke, dass es keine gute Idee ist, JSON zu erweitern (ohne es als ein anderes Austauschformat zu bezeichnen): Achten Sie darauf, "Kommentare" innerhalb von Zeichenfolgen zu ignorieren. {"foo": "/ * Dies ist kein Kommentar. * /"}
stofl
27
"... wäre ein Einzeiler" ähm, nein, eigentlich ist JSON keine reguläre Grammatik, bei der ein regulärer Ausdruck einfach passende Paare von / * finden kann. Sie müssen die Datei analysieren, um festzustellen, ob ein / * in einer Zeichenfolge angezeigt wird (und es ignoriert) oder ob es maskiert ist (und es ignoriert) usw. Außerdem ist Ihre Antwort nicht hilfreich, da Sie einfach spekulieren (falsch) und nicht angeben irgendeine Lösungsmöglichkeit.
Kyle Simpson
1
Was @ kyle-simpson gesagt hat. Außerdem ist er zu bescheiden, um die Leser auf seine eigene Antwort zur Verwendung von JSON.minify als Alternative zu Ad-hoc-Regexps hinzuweisen. Tu das, nicht das.
Toolbear
36

Wenn Sie die Newtonsoft.Json-Bibliothek mit ASP.NET zum Lesen / Deserialisieren verwenden, können Sie Kommentare im JSON-Inhalt verwenden:

// "name": "string"

// "id": int

oder

/* Das ist ein

Kommentarbeispiel * /

PS: Einzeilige Kommentare werden nur mit mehr als 6 Versionen von Newtonsoft Json unterstützt.

Zusätzlicher Hinweis für Leute, die nicht über den Tellerrand hinaus denken können: Ich verwende das JSON-Format für Grundeinstellungen in einer von mir erstellten ASP.NET-Webanwendung. Ich lese die Datei, konvertiere sie in das Einstellungsobjekt mit der Newtonsoft-Bibliothek und verwende sie bei Bedarf.

Ich schreibe lieber Kommentare zu jeder einzelnen Einstellung in die JSON-Datei selbst und kümmere mich wirklich nicht um die Integrität des JSON-Formats, solange die von mir verwendete Bibliothek damit einverstanden ist.

Ich denke, dies ist eine "einfacher zu verwendende / zu verstehende" Methode, als eine separate "settings.README" -Datei zu erstellen und die darin enthaltenen Einstellungen zu erläutern.

Wenn Sie ein Problem mit dieser Art der Verwendung haben; Entschuldigung, der Geist ist aus der Lampe. Die Leute würden andere Verwendungen für das JSON-Format finden, und Sie können nichts dagegen tun.

dvdmn
quelle
Es ist schwer zu verstehen, warum jemand Probleme haben würde, eine Tatsache anzugeben.
DVD
Ich würde annehmen, dass jemand eine Ausnahme gemacht hat, da das oben genannte nicht mehr JSON oder ungültiges JSON ist. Vielleicht würde das Hinzufügen eines kurzen Haftungsausschlusses beschwichtigen.
Toolbear
5
Ich stimme Ihnen voll und ganz zu, und dennoch gibt es bisher 883 positive Stimmen für die Nichtantwort, die nur das Offensichtliche besagt. Ideologische Reinheit über hilfreichen Informationen, das ist SO für Sie.
John
Der Punkt ist, dass eine Datei mit Kommentaren nicht JSON ist und von vielen JSON-Bibliotheken nicht analysiert werden kann. Sie können in Ihrem eigenen Programm tun, was Sie wollen, aber eine Datei mit Kommentaren ist nicht JSON. Wenn Sie behaupten, dass dies der Fall ist, werden die Benutzer versuchen, es mit der Sprache / Bibliothek ihrer Wahl zu analysieren, und es wird fehlschlagen. Es ist so, als würden Sie fragen, ob Sie in XML eckige Klammern anstelle von spitzen Klammern verwenden können. Sie können tun, was Sie wollen, aber es wird kein XML mehr sein.
Gman
32

Die Idee hinter JSON ist es, einen einfachen Datenaustausch zwischen Anwendungen bereitzustellen. Diese sind normalerweise webbasiert und die Sprache ist JavaScript.

Kommentare als solche sind nicht wirklich zulässig. Das Übergeben eines Kommentars als eines der Name / Wert-Paare in den Daten würde jedoch sicherlich funktionieren, obwohl diese Daten offensichtlich vom Parsing-Code ignoriert oder speziell behandelt werden müssten.

Alles in allem ist es nicht beabsichtigt, dass die JSON-Datei Kommentare im herkömmlichen Sinne enthält. Es sollten nur die Daten sein.

Weitere Informationen finden Sie auf der JSON-Website .

Neil Albrock
quelle
17
Es ist wahr, dass das JSON-Format keine Kommentare enthält. Persönlich halte ich das für einen erheblichen Fehler - die Möglichkeit, Kommentare als Metadaten (nicht als Daten) zu haben, ist bei XML sehr nützlich. Frühere Entwurfsversionen der JSON-Spezifikation enthielten zwar Kommentare, wurden jedoch aus irgendeinem Grund gelöscht. : - /
StaxMan
4
@StaxMan wurden sie genau gelöscht, weil die Leute sie als Metadaten verwendeten. Crockford sagte, es habe die Kompatibilität für das entworfene Format verletzt, und ich stimme zu: Wenn Sie Metadaten möchten, warum nicht als tatsächliche Daten einschließen? Es ist noch einfacher, auf diese Weise zu analysieren.
Camilo Martin
6
Metadaten gehören in Metadatenkonstrukte (z. B. HTML <meta> -Tags), nicht in Kommentare. Der Missbrauch von Kommentaren für Metadaten ist nur ein Hack, bei dem kein echtes Metadatenkonstrukt vorhanden ist.
Marnen Laibow-Koser
Genau aus diesem Grund wurde es gelöscht: Kommentare, die als Metadaten verwendet werden, würden die Interoperabilität beeinträchtigen. Sie sollten Ihre Metadaten auch einfach als JSON speichern.
gaborous
1
Diese Antwort ist überflüssig mit besser geschriebenen, höher bewerteten Antworten, die im Wesentlichen dasselbe sagen, obwohl dies möglicherweise früher geschrieben wurde. So ist das Leben.
Toolbear
29

Ich habe dies nur für Konfigurationsdateien festgestellt. Ich möchte kein XML-Format (ausführlich, grafisch, hässlich, schwer lesbar), kein "ini" -Format (keine Hierarchie, kein realer Standard usw.) oder kein Java-Format "Properties" (wie .ini) verwenden.

JSON kann alles, was sie können, aber es ist viel weniger ausführlich und besser lesbar - und Parser sind in vielen Sprachen einfach und allgegenwärtig. Es ist nur ein Datenbaum. Out-of-Band-Kommentare sind jedoch häufig eine Notwendigkeit, um "Standard" -Konfigurationen und dergleichen zu dokumentieren. Konfigurationen dürfen niemals "vollständige Dokumente" sein, sondern Bäume gespeicherter Daten, die bei Bedarf von Menschen gelesen werden können.

Ich denke, man könnte "#": "comment"für "gültiges" JSON verwenden.

Peterk
quelle
4
Für Konfigurationsdateien würde ich YAML vorschlagen, nicht JSON. Es ist (fast) eine leistungsstärkere Obermenge von JSON, unterstützt aber auch besser lesbare Konstrukte, einschließlich Kommentare.
Marnen Laibow-Koser
1
Wie viele Sprachen unterstützen Ihrer Meinung nach YAML im Vergleich zu json?
mmm
@Hamidam Über ein Dutzend Sprachen unterstützen yaml: yaml.org - aber Sie können zu Recht fragen, wie viele Unterstützung integriert sind, ohne dass eine Bibliotheksabhängigkeit von Drittanbietern erforderlich ist. Sieht aus wie Ruby 1.9.2. Kennt jemand andere? Und welche Sprachen unterstützen standardmäßig json?
Nealmcb
5
YAML Interop ist eine Lüge: stackoverflow.com/questions/450399/… . Wenn Sie JSON für Konfigurationsdateien verwenden möchten, befolgen Sie diese Anweisungen.
Toolbear
Das ist alt, aber ich glaube, dass die Verwendung von # keine gute Idee ist. Json kommt der Syntax eines Javascript-Wurfs nahe. Javascript unterstützt zwei Arten von Kommentaren: // und / * ... * / Wenn ich Sie wäre, würde ich mich an eine oder beide dieser Arten von Kommentaren halten.
Pascal Ganaye
28

JSON unterstützt Kommentare nicht nativ, aber Sie können Ihren eigenen Decoder oder zumindest Präprozessor erstellen, um Kommentare zu entfernen. Das ist vollkommen in Ordnung (solange Sie Kommentare einfach ignorieren und sie nicht als Leitfaden für die Verarbeitung der JSON-Daten durch Ihre Anwendung verwenden ).

JSON hat keine Kommentare. Ein JSON-Encoder darf KEINE Kommentare ausgeben. Ein JSON-Decoder kann Kommentare akzeptieren und ignorieren.

Kommentare sollten niemals verwendet werden, um etwas Sinnvolles zu übermitteln. Dafür ist JSON da.

Vgl.: Douglas Crockford, Autor der JSON-Spezifikation .

gaborous
quelle
4
Crockford schrieb später weiter: "Angenommen, Sie verwenden JSON, um Konfigurationsdateien zu speichern, die Sie mit Anmerkungen versehen möchten. Fügen Sie alle gewünschten Kommentare ein. Führen Sie sie dann durch JSMin, bevor Sie sie an Ihren JSON-Parser übergeben." Weitere Informationen finden Sie in der Antwort von @ kyle-simpson zu JSON.minify.
Toolbear
27

JSON ist für Konfigurationsdateien und andere lokale Anwendungen sehr sinnvoll, da es allgegenwärtig und viel einfacher als XML ist.

Wenn Personen starke Gründe haben, bei der Übermittlung von Daten Kommentare in JSON zu haben (ob gültig oder nicht), kann JSON möglicherweise in zwei Teile geteilt werden:

  • JSON-COM: JSON auf dem Draht oder Regeln, die für die Kommunikation von JSON-Daten gelten.
  • JSON-DOC: JSON-Dokument oder JSON in Dateien oder lokal. Regeln, die ein gültiges JSON-Dokument definieren.

JSON-DOC erlaubt Kommentare, und es können andere geringfügige Unterschiede bestehen, z. B. die Behandlung von Leerzeichen. Parser können problemlos von einer Spezifikation in die andere konvertiert werden.

In Bezug auf die Bemerkung von Douglas Crockford zu diesem Thema (verwiesen von @Artur Czajka)

Angenommen, Sie verwenden JSON, um Konfigurationsdateien zu speichern, die Sie mit Anmerkungen versehen möchten. Fügen Sie alle gewünschten Kommentare ein. Führen Sie es dann durch JSMin, bevor Sie es an Ihren JSON-Parser übergeben.

Wir sprechen über ein generisches Problem mit Konfigurationsdateien (sprachübergreifend / plattformübergreifend) und er antwortet mit einem JS-spezifischen Dienstprogramm!

Sicher, ein JSON-spezifisches Minify kann in jeder Sprache implementiert werden, aber standardisieren Sie es so, dass es für Parser in allen Sprachen und Plattformen allgegenwärtig ist, sodass die Benutzer keine Zeit mehr damit verschwenden, die Funktion zu verpassen, weil sie gute Anwendungsfälle dafür haben und das Problem nachschlagen Online-Foren und die Leute dazu bringen, ihnen zu sagen, dass es eine schlechte Idee ist oder dass es einfach ist, das Entfernen von Kommentaren aus Textdateien zu implementieren.

Das andere Problem ist die Interoperabilität. Angenommen, Sie haben eine Bibliothek oder API oder ein Subsystem, dem Konfigurations- oder Datendateien zugeordnet sind. Auf dieses Subsystem soll aus verschiedenen Sprachen zugegriffen werden. Dann erzählst du es den Leuten: Vergiss übrigens nicht, die Kommentare aus den JSON-Dateien zu entfernen, bevor du sie an den Parser weitergibst!

Basel Shishani
quelle
JSON muss nicht fragmentiert werden. JSON mit Kommentaren ist nicht mehr JSON. Es ist jedoch durchaus akzeptabel, Ihren JSON mit Kommentaren zu versehen, sofern Sie sicherstellen, dass Sie diese entfernen, bevor Sie sie analysieren oder übertragen. Es sollte niemals in der Verantwortung des Empfängers liegen, dies zu tun.
Toolbear
json5.org ist eine Lösung für json-doc
Michael Freidgeim
24

Wenn Sie JSON5 verwenden , können Sie Kommentare einfügen .


JSON5 ist eine vorgeschlagene Erweiterung von JSON , die es dem Menschen erleichtern soll, von Hand zu schreiben und zu warten. Dazu werden einige minimale Syntaxfunktionen direkt aus ECMAScript 5 hinzugefügt.

Smit Johnth
quelle
5
Könnten Sie bitte ein Beispiel hinzufügen? Dann benötigen Sie möglicherweise tatsächlich diese zusätzlichen Zeichen.
Dgilperez
6
Nach den SO-Richtlinien ist es erforderlich, eine tatsächliche Antwort zu geben. Nur-Link-Antworten sind nicht erwünscht. Sie können die Richtlinien stackoverflow.com/help/how-to-answer
dgilperez
2
SO wird von seinen Benutzern moderiert. Das heißt, ich kann eine Antwort geben, wenn ich sie habe, genauso wie ich Ihre kommentieren kann, wenn sie nicht den Richtlinien entspricht. So wird SO zu einer großartigen Ressource.
Dgilperez
22

Mit dem Dojo Toolkit JavaScript Toolkit (mindestens ab Version 1.4) können Sie Kommentare in Ihren JSON aufnehmen. Die Kommentare können /* */formatiert sein. Das Dojo Toolkit verwendet den JSON über den dojo.xhrGet()Aufruf.

Andere JavaScript-Toolkits funktionieren möglicherweise ähnlich.

Dies kann hilfreich sein, wenn Sie mit alternativen Datenstrukturen (oder sogar Datenlisten) experimentieren, bevor Sie eine endgültige Option auswählen.

David
quelle
4
Nein, das nicht. JSON hat keine Kommentare. Wenn Sie Ihren JSON mit Kommentaren versehen möchten, minimieren Sie ihn, bevor Sie ihn analysieren oder übertragen. Dies sollte nicht in der Verantwortung des Empfängers liegen.
Toolbear
2
Ich habe nicht gesagt, dass JSON Kommentare hat. Ich wollte auch nicht implizieren, dass es angemessen ist, sie in Ihren JSON aufzunehmen, insbesondere in ein Produktionssystem. Ich sagte, dass Sie mit dem Dojo-Toolkit diese hinzufügen können, was sachlich wahr ist (oder zumindest war). Es gibt sehr hilfreiche Anwendungsfälle dafür in Ihrer Testphase.
David
1
Es ist schlechtes Voodoo, kommentierte und damit ungültige JSON zu servieren, was dojo.xhrGet()implizit durch Akzeptieren ermutigt.
Toolbear
Ich stimme immer noch für die Aktualisierung der JSON-Spezifikation, um Kommentare zuzulassen. Ich bin alle dafür, die Kommentare vor dem Übertragen des JSON zu minimieren und zu entfernen, aber nicht in der Lage zu sein, Ihren JSON auf standardmäßige Weise zu kommentieren, ohne ihn vor dem Parsen durch ein separates Dienstprogramm weiterleiten zu müssen, scheint einfach albern. Ich mache es auch unmöglich, einen JSON-Editor für Ihre JSON-Konfigurationsdateien zu verwenden, da Ihre Dateien kein gültiges JSON sind.
Craig
20

JSON ist kein gerahmtes Protokoll . Es ist ein sprachfreies Format . Das Format eines Kommentars ist daher für JSON nicht definiert.

Wie viele Leute vorgeschlagen haben, gibt es einige Tricks, zum Beispiel doppelte Schlüssel oder einen bestimmten Schlüssel _comment, den Sie verwenden können. Es liegt an dir.

Manish Shrivastava
quelle
18

Sie können Kommentare in JSONP haben , aber nicht in reinem JSON. Ich habe gerade eine Stunde damit verbracht, mein Programm mit diesem Beispiel aus Highcharts zum Laufen zu bringen: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?

Wenn Sie dem Link folgen, werden Sie sehen

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

Da ich eine ähnliche Datei in meinem lokalen Ordner hatte, gab es keine Probleme mit der Richtlinie für denselben Ursprung. Daher habe ich mich für die Verwendung von reinem JSON entschieden ... und bin natürlich $.getJSONaufgrund der Kommentare unbemerkt gescheitert.

Schließlich habe ich gerade eine manuelle HTTP-Anfrage an die oben angegebene Adresse gesendet und festgestellt, dass der Inhaltstyp war, text/javascriptda JSONP reines JavaScript zurückgibt. In diesem Fall sind Kommentare zulässig . Da meine Anwendung jedoch den Inhaltstyp zurückgab application/json, musste ich die Kommentare entfernen.

osa
quelle
17

Dies ist eine "Kannst du" -Frage. Und hier ist eine "Ja" Antwort.

Nein, Sie sollten keine doppelten Objektelemente verwenden, um Seitenkanaldaten in eine JSON-Codierung einzufügen. (Siehe "Die Namen innerhalb eines Objekts sollten eindeutig sein" im RFC ).

Und ja, Sie könnten Kommentare um den JSON einfügen , die Sie analysieren könnten.

Wenn Sie jedoch beliebige Seitenkanaldaten in einen gültigen JSON einfügen und extrahieren möchten, finden Sie hier eine Antwort. Wir nutzen die nicht eindeutige Darstellung von Daten in einer JSON-Codierung. Dies ist * in Abschnitt 2 des RFC unter "Leerzeichen sind vor oder nach einem der sechs Strukturzeichen zulässig" zulässig.

* Der RFC gibt nur an, dass "Leerzeichen vor oder nach einem der sechs Strukturzeichen zulässig sind", wobei Zeichenfolgen, Zahlen, "false", "true" und "null" nicht explizit erwähnt werden. Diese Auslassung wird in ALLEN Implementierungen ignoriert.


Kanonisieren Sie zunächst Ihren JSON, indem Sie ihn minimieren:

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

Codieren Sie dann Ihren Kommentar binär:

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

Dann steu deine Binärdatei:

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

Hier ist Ihre Ausgabe:

$jsonWithComment = $steg . $jsonMin;
William Entriken
quelle
1
Der RFC gibt nur an, dass "Leerzeichen vor oder nach einem der sechs Strukturzeichen zulässig sind", wobei Zeichenfolgen, Zahlen, "false", "true", "null" nicht explizit erwähnt werden. Diese Auslassung wird in ALLEN Implementierungen ignoriert.
William Entriken
1
Könnten Sie Ihren Kommentar für eine höhere Kommentardichte nicht ternär codieren und Leerzeichen, Tabulatoren und Zeilenumbrüche verwenden, um ihn zu speichern?
Claire Nielsen
SOLLTE nicht sein. Siehe den explizit enthaltenen RFC 2119: MUSS: Dieses Wort oder die Begriffe "ERFORDERLICH" oder "MUSS" bedeuten, dass die Definition eine absolute Anforderung der Spezifikation ist. ... SOLLTE: Dieses Wort oder das Adjektiv "EMPFOHLEN" bedeuten, dass es unter bestimmten Umständen gültige Gründe geben kann, einen bestimmten Gegenstand zu ignorieren, aber die vollständigen Auswirkungen müssen verstanden und sorgfältig abgewogen werden, bevor ein anderer Kurs gewählt wird.
Jeff K
Gute Referenz. Eine bessere Argumentation gegen die Verwendung doppelter Schlüssel ist das Zitat des Standards "Wenn die Namen innerhalb eines Objekts nicht eindeutig sind, ist das Verhalten von Software, die ein solches Objekt empfängt, unvorhersehbar." Auch jetzt verstehe ich, warum der Standard nicht "MUSS eindeutig sein" war, dies macht einen Validator einfacher, er muss nur verfolgen [und {, er muss nicht wissen, welche Schlüssel bereits verwendet wurden.
William Entriken
16

HAFTUNGSAUSSCHLUSS: DAS IST DUMM

Es gibt tatsächlich eine Möglichkeit, Kommentare hinzuzufügen und innerhalb der Spezifikation zu bleiben (kein zusätzlicher Parser erforderlich). Es wird jedoch nicht zu lesbaren Kommentaren führen, ohne dass eine Analyse durchgeführt wird.

Sie könnten Folgendes missbrauchen:

Vor oder nach einem Token ist ein unbedeutendes Leerzeichen zulässig. Leerzeichen sind beliebige Folgen eines oder mehrerer der folgenden Codepunkte: Zeichentabelle (U + 0009), Zeilenvorschub (U + 000A), Wagenrücklauf (U + 000D) und Leerzeichen (U + 0020).

Auf hackige Weise können Sie dies missbrauchen, um einen Kommentar hinzuzufügen. Zum Beispiel: Beginnen und beenden Sie Ihren Kommentar mit einem Tabulator. Codieren Sie den Kommentar in base3 und verwenden Sie die anderen Leerzeichen, um sie darzustellen. Zum Beispiel.

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

( hello base threein ASCII) Verwenden Sie jedoch anstelle von 0 Leerzeichen, für 1 Zeilenvorschub und für 2 Wagenrücklauf.

Dadurch bleiben Ihnen nur viele unlesbare Leerzeichen (es sei denn, Sie erstellen ein IDE-Plugin, um es im laufenden Betrieb zu codieren / decodieren).

Ich habe das aus offensichtlichen Gründen noch nie versucht und du auch nicht.

Roy Prins
quelle
12

Wir verwenden strip-json-commentsfür unser Projekt. Es unterstützt so etwas wie:

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

Einfach npm install --save strip-json-commentszu installieren und zu verwenden wie:

var strip_json_comments = require('strip-json-comments')
var json = '{/*rainbows*/"unicorn":"cake"}';
JSON.parse(strip_json_comments(json));
//=> {unicorn: 'cake'}
Freude
quelle
Beachten Sie, dass das jsonkein gültiger JSON mehr ist, wenn es diese Richtigkeitskommentare enthält.
Roy Prins
12

In meinem Fall muss ich Kommentare für Debug-Zwecke verwenden, bevor die JSON-Struktur ausgegeben wird. Deshalb habe ich mich entschlossen, Debug-Informationen im HTTP-Header zu verwenden, um eine Unterbrechung des Clients zu vermeiden:

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

Geben Sie hier die Bildbeschreibung ein

WilliamK
quelle
12

JSON erlaubt per se keine Kommentare. Die Argumentation ist absolut dumm, da Sie JSON selbst verwenden können , um Kommentare zu erstellen, wodurch die Argumentation vollständig entfällt und der Parser-Datenraum ohne triftigen Grund für genau das gleiche Ergebnis und potenzielle Probleme geladen wird, wie z. B .: Ein JSON Datei mit Kommentaren.

Wenn Sie versuchen, Kommentare einzufügen (mit //oder /* */oder #zum Beispiel), schlagen einige Parser fehl, da dies streng genommen nicht in der JSON-Spezifikation liegt. Das solltest du also niemals tun.

Hier ist zum Beispiel ein Beispiel, in dem mein Bildmanipulationssystem Bildnotationen und einige grundlegende formatierte (Kommentar-) Informationen dazu gespeichert hat (unten):

{
    "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
quelle
Der "Argumentations" -Link ist unterbrochen. Gibt es eine Chance, einen aktuellen Link dazu zu finden?
Don Hatch
Leider hat Google das Social-Media-System, in dem sich der Beitrag befand, getötet. Ich habe keine Ahnung, wo das Originalplakat von dort hingegangen ist, wenn überhaupt. Ich werde den Link in den obigen Informationen jedoch beenden, um die Mehrdeutigkeit zu beseitigen. Vielen Dank.
Fyngyrz
Die Argumentation ist nicht dumm, und Sie haben es gerade bewiesen. Durch das Implementieren von Kommentaren als Tags bleibt die Interoperabilität erhalten . Das ist genau , warum Crockford Kommentare wollte als Tags analysiert werden. Jetzt ist alles nur noch ein Tag und wird auf die gleiche Weise analysiert .
Dominic Cerisano
Wenn in der Spezifikation angegeben wird, dass "eine Zeile, die mit # beginnt, ein Kommentar ist", ist dies vollständig interoperabel. Kommentare laden derzeit den Parser-Bereich, da es sich um gültige analysierte Elemente handelt und nicht um Kommentare. Sie können für jede vorhandene JSON-Datei unterschiedlich sein. Wenn in der Spezifikation beispielsweise "Zeilen, die mit # beginnen, sind Kommentare" angegeben sind, können die Parser diese Zeilen überspringen, ohne sie zu analysieren (schneller) und den Parser-Speicherplatz nicht zu laden (bessere Speichernutzung). Der Mangel hat überhaupt keinen Vorteil von Kommentaren in .json, nur Nachteile.
Fyngyrz
11

Um ein JSON-Element in Teile zu schneiden, füge ich "Dummy-Kommentar" -Zeilen hinzu:

{

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

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

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

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

}
Chris
quelle
15
Sie haben eine INI-Dateistruktur in JSON emuliert. Bitte legen Sie Ihren goldenen Hammer ab.
Artur Czajka
4
RFC sagt "Die Namen innerhalb eines Objekts sollten eindeutig sein". Sehen Sie auch diese Person, die einen Fehler beim Parsen von JSON wie oben hat: stackoverflow.com/questions/4912386/…
William Entriken
Wenn Sie ein Schema zum Überprüfen des JSON verwenden, kann dies aufgrund der zusätzlichen Felder fehlschlagen.
Gregsdennis
1
Wenn Sie wirklich entschlossen sind, Ihrem JSON Kommentare hinzuzufügen, ist es viel sinnvoller, Folgendes zu tun: { "comment-001":"This is where you do abc...", "comment-002":"This is where you do xyz..." } Dadurch bleibt der Name eindeutig und Sie können einen beliebigen Zeichenfolgenwert hinzufügen. Es ist immer noch ein Problem, da Kommentare nicht Teil Ihres JSON sein sollten. Fügen Sie als weitere Alternative Kommentare vor oder nach Ihrem JSON hinzu, jedoch nicht darin.
Jazimov