JSON vs. JSON5 vs. JSONC: Welches und wann

Wer genugsam Zeit mit dem Schreiben von Konfigurationsdateien verbringt, bemerkt etwas: Was die Leute “JSON” nennen, ist kein einziges Format. Es sind drei, und sie sind nicht austauschbar. Eine Konfiguration, die in VS Code sauber geladen wird, kann einen Syntaxfehler erzeugen, wenn man sie in JSON.parse einfüttert. Eine Webpack-Konfiguration, die in einem Repository funktioniert, stürzt in einem anderen ab. Alle Dateien enden auf .json, sie sehen alle wie JSON aus, aber der darunterliegende Parser macht unterschiedliche Arbeit.

Das ist eine schnelle Tour durch das, was jedes Format tatsächlich erlaubt, wo jedes in der Wildnis vorkommt und wie man aufhört zu raten, mit welchem Parser man spricht.

Einfaches JSON, nach der Spezifikation

JSON, wie von RFC 8259 definiert, ist eine abgespeckte Teilmenge von JavaScript-Objektliteralen. Die Grammatik passt auf eine Serviette:

• Objekte: {} mit String-Schlüsseln und beliebigen JSON-Werten
• Arrays: [] mit beliebigen JSON-Werten
• Strings: in doppelten Anführungszeichen, mit einem spezifischen Escape-Satz
• Zahlen: dezimal, optional vorzeichenbehaftet, mit . für Dezimalstellen und e für Exponenten
• true, false, null

Das ist die gesamte Sprache. Ein paar Konsequenzen aus “das ist die gesamte Sprache” erwischen Menschen:

• Keine Kommentare. Nicht //, nicht /* */. Douglas Crockford hat sie bewusst entfernt, weil Menschen sie als Pragma-Syntax verwendet haben (// @charset: utf-8) und das jeden Parser zu einem Praprozessor machte.
• Keine Trailing Commas. [1, 2, 3,] ist ungültig. Das verbrennt Menschen ständig, wenn sie eine Liste bearbeiten und vergessen, das letzte Komma zu löschen.
• Schlüssel müssen in Anführungszeichen stehende Strings sein. {foo: 1} ist JavaScript, nicht JSON. {"foo": 1} ist JSON.
• Kein Hex, kein NaN, kein Infinity, kein undefined. Zahlenliterale müssen in die Grammatik der Spezifikation passen. {"ratio": NaN} ist kein gültiges JSON-Dokument, auch wenn JavaScript es mit JSON.stringify in manchen Implementierungen gerne produziert.
• Doppelte Schlüssel sind implementierungsdefiniert. Die meisten Parser nehmen das letzte Vorkommen. Einige erzeugen Fehler. Die Spezifikation sagt “unvorhersehbar.”

Die Strenge ist der Punkt. Wenn alle Parser über die Grammatik einig sind, werden Dateien zuverlässig über Sprachen hinweg übertragen. Man kann JSON in Python schreiben, in Go lesen, und die Bytes bedeuten dasselbe.

Unser JSON Formatter läuft gegen die strikte Grammatik - wenn er einen Fehler in einer Datei meldet, die im Editor gut aussieht, ist die Datei wahrscheinlich JSON5 oder JSONC, nicht JSON.

JSONC: JSON mit Kommentaren

JSONC ist das, was Microsoft für VS-Code-Konfigurationsdateien verwendet - settings.json, tsconfig.json, launch.json, alles im .vscode/-Verzeichnis. Es ist einfaches JSON plus zwei Dinge:

• // einzeilige Kommentare
• /* */ Blockkommentare

Das ist alles. Alles andere ist striktes JSON. Keine Trailing Commas, keine nicht in Anführungszeichen stehenden Schlüssel, kein Hex.

JSONC existiert, weil Konfigurationsdateien davon profitieren, selbst dokumentierend zu sein, und die Erklärung zu verlieren, warum ein Flag gesetzt ist, wenn man Kommentare entfernt, ist ein echter Kostenfaktor. Das VS-Code-Team hat seinen eigenen Parser ausgeliefert (jsonc-parser, npm-Paket), der das verarbeitet.

Eine tückische Falle: tsconfig.json ist JSONC. Wenn man versucht, es mit normalem JSON.parse zu parsen, nachdem ein Nutzer einen hilfreichen Kommentar wie // disable strict mode for now hinzugefügt hat, bekommt man einen Parse-Fehler. jsonc-parser verwenden oder zuerst Kommentare entfernen.

JSON5

JSON5 ist ein anderes Tier. Während JSONC zwei Features auf JSON aufbaut, erweitert JSON5 die Grammatik erheblich:

• // und /* */ Kommentare
• Trailing Commas in Objekten und Arrays
• Nicht in Anführungszeichen stehende Schlüssel (müssen gültige JavaScript-Bezeichner sein)
• Strings in einfachen Anführungszeichen
• Mehrzeilige Strings über Zeilenfortsetzung (\<newline>)
• Hexadezimalzahlen (0xdeadbeef)
• Führende oder abschließende Dezimalpunkte (.5, 5.)
• +Infinity, -Infinity, NaN als gültige Zahlenliterale
• Explizites Pluszeichen bei Zahlen (+42)

Das JSON5-Ziel ist es, eine Obermenge von JSON zu sein, die auch eine strikte Teilmenge von ES5 ist - was bedeutet, dass gültiges JSON5 gültiges JavaScript ist, das man in eine .js-Datei einfügen könnte. Die Attraktivität ist Ergonomie: manuell bearbeitete Konfigurationsdateien profitieren von jedem dieser Features.

Wo man JSON5 in der Praxis trifft: Babels .babelrc.json5 (wenn so konfiguriert), einige ESLint-Konfigurationen und mehrere Build-Tools, die die Auswahl der Konfigurationssyntax erlauben. Man braucht einen spezifischen Parser wie das json5-npm-Paket; JSON.parse lehnt es ab.

Eine Schnellreferenz

Feature	JSON	JSONC	JSON5
Kommentare (//, /* */)	nein	ja	ja
Trailing Commas	nein	nein	ja
Nicht in Anführungszeichen stehende Schlüssel	nein	nein	ja
Strings in einfachen Anführungszeichen	nein	nein	ja
Hex-Zahlen	nein	nein	ja
NaN / Infinity	nein	nein	ja
Wird von JSON.parse geparst	ja	nein (Kommentare ablehnen)	nein
Dateiendung	.json	.json, .jsonc	.json5, .json

Welches verwenden

Die Entscheidung hängt davon ab, wer die Datei liest.

Einfaches JSON verwenden, wenn die Datei maschinell generiert oder maschinell gelesen wird. API-Antworten, Datenexporte, Logs, Analytics-Payloads, Schema-Dateien, die Tools konsumieren. Jede Sprache der Welt hat einen schnellen, strikten JSON-Parser. An der Spezifikation zu bleiben bedeutet, dass niemand darüber nachdenken muss, welchen Dialekt die eigene API verwendet.

JSONC verwenden, wenn die Datei manuell bearbeitete Konfiguration für ein Tool ist, das es nativ unterstützt. VS-Code-Einstellungen, tsconfig.json, alles im .vscode/-Verzeichnis. Kommentare machen eine Konfiguration, die sich selten ändert, aber bei Änderungen verstanden werden muss.

JSON5 verwenden, wenn man sich bewusst entschieden hat, Portabilität gegen Ergonomie zu tauschen. Die interne Build-Konfiguration eines Teams, Test-Fixtures mit viel wiederholter Struktur, alles, bei dem die Bequemlichkeit von Trailing Commas und nicht in Anführungszeichen stehenden Schlüsseln die Kosten eines nicht-standardkonformen Parsers überwiegt. Explizit sein: die Dateiendung sollte .json5 sein, damit Editoren die richtige Syntaxhervorhebung wählen.

Mischen vermeiden. Der hässliche Fall ist eine Datei namens config.json, die JSON5-Features verwendet. Jemand wird JSON.parse darauf versuchen und abstürzen. Der Datei einen Namen geben, der den Lesern mitteilt, welchen Dialekt sie ist.

Konvertierung zwischen Formaten

Wenn man eine JSONC-Datei empfängt und striktes JSON braucht (z. B. zum Einfügen in ein System, das es erfordert), Kommentare entfernen und alle streunenden Trailing Commas löschen:

import { stripJsonComments } from 'strip-json-comments';
const strict = stripJsonComments(jsoncSource).replace(/,(\s*[\]}])/g, '$1');
JSON.parse(strict); // sicher

Wenn man strukturiertes JSON in eine andere Serialisierung konvertieren muss, verarbeiten unsere JSON to YAML - und JSON to CSV -Konverter die gängigen. Für das Umgekehrte (TOML-Konfigurationen in JSON für eine JavaScript-Toolchain), den TOML to JSON -Konverter verwenden.

Das praktische Fazit

Die drei Formate stehen an verschiedenen Punkten auf der Achse “manuell bearbeitbar vs. maschinenlesbar”. Einfaches JSON ist das Einzige, auf das man über Sprachgrenzen hinweg zählen kann. JSONC und JSON5 sind Editor-Komforts - nützlich, wo sie zutreffen, nicht hilfreich, wo sie es nicht tun.

Wenn ein Parse-Fehler auftritt, ist die erste Frage nicht “Ist mein JSON falsch?” Es ist “Ist das tatsächlich JSON, oder füttere ich JSON5 in einen strikten Parser?” Dieser eine Rahmenbruch löst das meiste tägliche Reibung.