Kann JSON Kommentare haben
Fazit: RFC 8259 hat keine Kommentarsyntax, `//`- und Blockkommentare lassen JSON.parse also werfen. Verwenden Sie stattdessen JSON5 oder JSONC, ein `_comment`-Feld, eine Schema-`description` oder YAML.
Kurz gesagt: Setzen Sie nie Kommentare in Standard-JSON; verwenden Sie JSONC oder JSON5 für lokale Konfiguration, die nur Menschen bearbeiten, verlegen Sie Erklärungen in eine JSON-Schema-description, wenn die Datei Systeme überschreitet, und wechseln Sie zu YAML oder TOML, sobald das Annotationsvolumen wächst.
Nein.
Jeder standardkonforme Parser lehnt das ab:
{
"port": 8080 // local development only
}
Chrome meldet SyntaxError: Unexpected token }. Der Parser stieß auf /, das keinen JSON-Wert beginnen kann, und stoppte.
Warum die Spezifikation Kommentare absichtlich weglässt
RFC 8259 definiert sechs Werte: Objekt, Array, Zahl, String, true/false, null. Es gibt keine Kommentarproduktion.
Kommentare wurden früh vorgeschlagen und aus einem konkreten Grund abgelehnt: Sind Kommentare erst legal, verwendet jemand sie, um Direktiven zu tragen – bedingte Includes, Template-Variablen –, und jeder Parser züchtet seinen eigenen Dialekt. Die Interoperabilität bricht beim ersten Hop. JSON ist bewusst reine Daten, mit nichts Ausführbarem darin.
Vier Wege, Ihre Notizen zu behalten
1. Eine Obermenge verwenden. JSON5 und JSONC akzeptieren beide Kommentarstile. VS Codes settings.json und tsconfig.json sind JSONC.
Der Preis ist real: JSON.parse lehnt sie weiterhin ab, und APIs, Log-Pipelines und Message Queues akzeptieren meist nur Standard-JSON. Ihr Kommentar wird stillschweigend verworfen oder wirft irgendwo stromabwärts.
2. Die Notiz in die Daten legen.
{
"_comment": "port assigned by ops, do not change",
"port": 8080
}
Funktioniert überall, verunreinigt aber das Modell: Jeder Konsument muss wissen, welche Schlüssel zu ignorieren sind, und Ihre Typdefinition wächst um ein Feld, das keine echten Daten sind.
3. Eine Schema-description verwenden. description ist für Menschen und Werkzeuge gedacht. Validatoren machen sie sichtbar, Editoren zeigen sie beim Hovern, und sie gelangt nie in die Payload. Das ist die einzige Option, die langfristige Wartung ohne Kompatibilitätsbruch übersteht.
4. Das Dateiformat ändern. Existiert die Datei, um von Hand bearbeitet zu werden, unterstützen YAML oder TOML Kommentare nativ. Gegen JSON zu kämpfen ist hier verschwendeter Aufwand.
Auswahl
| Situation | Antwort |
|---|---|
| An ein anderes System gesendet, über eine API oder Queue | Keine Kommentare; in Schema oder externer Doku dokumentieren |
| Konfiguration, die nur von Menschen und Editoren gelesen wird | JSONC, mit .jsonc-Endung |
| Braucht universelle Werkzeuge und Inline-Erklärung | Standard-JSON plus Schema-description |
| Lange Konfiguration mit viel Annotation | Zu YAML wechseln |
FAQ
Warum verunreinigt ein _comment-Feld das Modell?
Weil es Teil der Daten wird. Jeder Konsument muss wissen, welche Schlüssel zu ignorieren sind, und die Typdefinition gewinnt ein Feld, das keine echten Geschäftsdaten sind.
Sollte die Erklärung in einer JSON-Schema-description leben?
Ja. description bleibt aus der Payload heraus, während Validatoren sie sichtbar machen und Editoren sie beim Hovern zeigen, es ist also die einzige Option, die langfristige Wartung ohne Kompatibilitätsbruch übersteht.
Können JSONC oder JSON5 von JSON.parse geparst werden?
Nein. JSON.parse lehnt Kommentare weiterhin ab, und APIs, Log-Pipelines und Message Queues akzeptieren meist nur Standard-JSON, der Kommentar wird also verworfen oder wirft irgendwo stromabwärts.
Werkzeuge
- JSON5-Parser — eine kommentierte Konfiguration einfügen und die aufgelöste Struktur sehen
- JSON-Formatter und -Validator — illegales JSON wird mit Zeile und Spalte gemeldet, sodass der fehlerhafte Kommentar offensichtlich ist