JSON5 vs. JSON
Die Strenge von JSON ist das eigentliche Feature: RFC 8259 ist der Grund, warum sich alle Parser der Welt einig sind. JSON5 tauscht einen Teil dieser Universalität gegen Komfort ein – Kommentare, Schlüssel ohne Anführungszeichen, einfache Anführungszeichen, nachgestellte Kommas, Hexadezimalzahlen. Behalten Sie JSON für alles, was ein Programm liest; erlauben Sie JSON5 nur in Konfigurationsdateien, die jeder Consumer mit derselben Bibliothek parst.
JSON5 vs. JSON erklärt
Jede JSON-Datei, die schon einmal einen Menschen genervt hat, ärgert auf dieselbe Weise: Sie können nicht erklären, wozu ein Feld dient, Sie können einen Block nicht vorübergehend deaktivieren, und das Entfernen des letzten Kommas ist eine Fleißarbeit, die der Parser eigentlich problemlos verzeihen könnte. JSON5 ist die Antwort der Community – eine echte Obermenge von JSON, angelehnt an die ECMAScript-5-Syntax, die Kommentare ergänzt, die Anführungszeichen lockert und nachgestellte Kommas sowie ein paar numerische Annehmlichkeiten toleriert. Gültiges JSON ist immer gültiges JSON5; umgekehrt gilt das nie.
Die Spezifikation lebt auf json5.org statt in einem IETF-Dokument, und genau diese Verortung ist die ehrliche Zusammenfassung des Kompromisses. Die Grammatik von RFC 8259 garantiert, dass ein Payload, der in Tokio geschrieben wurde, in Toronto identisch geparst wird – eine Seite voller Regeln, keine Dialekte. JSON5 stellt die Frage neu, die striktes JSON nie stellt: welcher Parser, und in welcher Version? Browser liefern JSON.parse aus und sonst nichts, daher bedeutet JSON5 immer eine Abhängigkeit.
Deshalb verläuft die Trennung in der Praxis klar: JSON für den Datentransfer und alles Gespeicherte, JSON5 für von Menschen gepflegte Konfiguration, bei der eine Parser-Abhängigkeit eine einmalige Kostenfrage ist und Kommentare sich auszahlen. Diese Seite geht Schritt für Schritt durch, was JSON5 ergänzt, was es kostet und wo die Grenze verläuft – mit den lokalen JSON-Tools der Website, die beide Seiten prüfen können.
Sie möchten wissen, wo Ihre Datei in Sachen Strenge steht? Der JSON-Validator parst RFC 8259 lokal und markiert das erste Konstrukt, das ein strikter Parser zurückweist.
Für Dateien, die bereits im strikten Subset liegen, normalisiert der JSON-Formatter Anführungszeichen, Schlüssel und Einrückung in Ihrem Browser – ganz ohne Upload.
Was JSON5 tatsächlich hinzufügt
Die Erweiterungen von JSON5 stammen alle aus der ES5-Objektliteral-Syntax – dem Ursprungsort von JSON. Kommentare kehren zurück, als // bis zum Zeilenende und /* block */. Schlüssel dürfen ohne Anführungszeichen stehen, wenn sie gültige Bezeichner sind. Strings dürfen einfache Anführungszeichen und mehr Escape-Sequenzen verwenden. Zahlen bekommen Hexadezimalnotation, einen führenden oder nachgestellten Dezimalpunkt, ein führendes Pluszeichen sowie die Sonderwerte Infinity, -Infinity und NaN. Nachgestellte Kommas sind in beiden Containern erlaubt.
| Feature | JSON (RFC 8259) | JSON5 |
|---|---|---|
| Kommentare | Keine – bewusst entfernt | // und /* */ erlaubt |
| Objektschlüssel | Nur Strings in doppelten Anführungszeichen | Unzitierte, gültige Bezeichner |
| Anführungszeichen bei Strings | Nur doppelte | Einfache oder doppelte |
| Nachgestellte Kommas | Syntaxfehler | Erlaubt |
| Zahlen | Nur Dezimal, kein führendes + | Hexadezimal, +.5, 5., Infinity, NaN |
| Standard | RFC 8259 / ECMA-404 | Spezifikation auf json5.org, bibliotheksdefiniert |
Der Preis: wer die Datei lesen kann
JSON.parse lehnt den ersten Kommentar, das erste einfache Anführungszeichen oder den ersten nackten Schlüssel ab, auf den es trifft – JSON5 gibt es nicht nativ im Browser, und keine Server-Plattform liefert einen mit. Jeder Consumer braucht daher dieselbe Bibliothek, mit fester, kompatibler Version. Sobald ein Dokument aufhört, striktes JSON zu sein, gilt „jeder Parser funktioniert“ nicht mehr – und genau diese Garantie ist der Hauptgewinn von RFC 8259.
Ein subtilerer Preis ist der Zoo an Dialekten, der in der Lücke entsteht: JSONC – nur Kommentare und nachgestellte Kommas – ist das, was tsconfig und VS Code tatsächlich akzeptieren, und es ist nicht JSON5, denn JSONC behält strikte Anführungszeichen und Zahlen bei. Dateien driften zwischen Dialekten, Editoren sind sich beim Syntax-Highlighting uneins, und ein Toolchain-Upgrade kann aus einem tolerierten Konstrukt einen Fehler machen. Striktes JSON hat keine solche Mehrdeutigkeit zu verwalten.
Wo jedes Format hingehört
Die Trennung folgt dem Leser. Konfiguration, die von Menschen geschrieben und geprüft wird, profitiert von Kommentaren, die ein Feld erklären, von auskommentierten Schaltern beim Debuggen und von unzitierten Schlüsseln, die Rauschen reduzieren – das ist JSON5-Territorium, überall dort, wo die Toolchain es bereits unterstützt. Alles, was ein Programm erzeugt oder verarbeitet – API-Payloads, gespeicherte Zustände, strukturierte Logs, Queue-Nachrichten – bleibt striktes JSON, denn dort ist Universalität der ganze Punkt.
- Wire-Format: immer JSON – jeder Consumer muss es ganz ohne gemeinsame Konfiguration parsen können.
- Von Menschen gepflegte Konfiguration: JSON5 oder JSONC, wenn Ihre Tools es ohnehin nativ sprechen.
- Schema und Dokumentation: striktes JSON verlagert die Erklärung in Schemas, weil Kommentare nirgends Platz finden.
- Persistente Daten: JSON – ihre künftigen Leser schließen Tools ein, die noch gar nicht ausgewählt wurden.
Konvertieren zwischen beiden
Von JSON nach JSON5 ist verlustfrei: Striktes JSON parst bereits als JSON5, „Konvertieren“ ist also eine Frage des Stils, nicht der Struktur. Von JSON5 nach JSON ist auf genau die Weise verlustbehaftet, die Sie erwarten: Kommentare haben kein Ziel und verschwinden, und Infinity, -Infinity und NaN haben keinen JSON-Wert, sodass sie zu null oder Strings werden. Alles andere überlebt: Schlüssel bekommen Anführungszeichen, Anführungszeichen werden vereinheitlicht, Hexadezimalzahlen kommen als derselbe Wert in Dezimalnotation an.
Die Grenze können Sie selbst beobachten: Fügen Sie eine JSON5-Datei in einen strikten Validator ein, und der erste Fehler zeigt auf das Konstrukt, das sie überschritten hat – ein Kommentar, ein Anführungszeichen, ein nachgestelltes Komma. Die Diagnose funktioniert auch in die andere Richtung: Muss eine Konfigurationsdatei eines Tages von strikter Tooling-Software gelesen werden, halten Sie sie von Anfang an im strikten Subset, denn das Herabstufen ist der verlustbehaftete Weg.
Wann Sie was wählen
Bleiben Sie standardmäßig bei JSON und greifen Sie nur mit gutem Grund zu JSON5. Der Grund ist eine Datei, die Menschen pflegen und Maschinen lediglich verarbeiten – Build-Konfiguration, Feature-Flags, Umgebungsdefinitionen – in Kombination mit einer Toolchain, die JSON5 bereits nativ parst. Wenn Ihre Consumer unbekannt, extern oder langlebig sind, ist Strenge keine Bürokratie; sie ist der Schnittstellenvertrag.
Die Empfehlung kehrt sich sauber um: Eine Konfigurationsdatei, die nie auch nur einen Kommentar nötig hatte, braucht auch kein JSON5, und eine JSON5-Datei, die ein Dienst plötzlich zur Laufzeit parst, ist still und heimlich zu einem Wire-Format geworden – das heißt, sie will wieder JSON sein.
Häufig gestellte Fragen
Kann ich JSON hier formatieren oder prüfen, ohne die Datei hochzuladen?
Ja. Formatter und Validator laufen vollständig in Ihrem Browser-Tab – das Parsen nutzt die eigene JSON-Engine des Browsers gegen RFC 8259, kein Request verlässt die Seite, die Content-Security-Policy der Website blockiert ausgehende Aufrufe, und der Netzwerk-Tab der DevTools bleibt still. Konfigurationsdateien verlassen Ihren Rechner nie. Striktes JSON validiert; JSON5-Erweiterungen erscheinen als Syntaxfehler, die das exakte Konstrukt benennen.
Ist JSON5 ein offizieller Standard?
Nicht im RFC-Sinne. Es ist auf json5.org spezifiziert und stützt sich auf seine Referenzimplementierung und Community, während JSON RFC 8259 und ECMA-404 hat. In der Praxis bedeutet das: keine Konformitätssprache, keine Registry, und Interoperabilität nur durch dieselbe Parser-Bibliothek garantiert – das Gegenteil von JSONs Versprechen, dass jeder Parser funktioniert.
Warum unterstützt JSON keine Kommentare?
Douglas Crockford hat sie beim Standardisieren des Formats bewusst entfernt: Hersteller hatten begonnen, Parsing-Direktiven in Kommentare einzubetten, was die Interoperabilität zwischen Implementierungen zerstörte. Ein Datenaustauschformat muss für jeden Leser dasselbe bedeuten, also blieb die Grammatik minimal. Üblich geblieben sind Schlüssel wie "_comment" auf Geschwister-Ebene, oder JSONC, wo die Toolchain es erlaubt.
Kann JSON.parse mit JSON5 umgehen?
Nein – es wirft beim ersten Kommentar, beim ersten einfachen Anführungszeichen, beim ersten unzitierten Schlüssel oder beim ersten nachgestellten Komma einen Fehler, was die meisten echten JSON5-Dateien sofort erwischt. Sie brauchen die JSON5-Bibliothek oder zunächst eine Umformung in striktes JSON. Achten Sie auch auf die JSONC-Falle: Ein Parser, der Kommentare und nachgestellte Kommas akzeptiert, ist noch lange kein JSON5-Parser, und er wird einfache Anführungszeichen und Hexadezimalzahlen zurückweisen.
Geht beim Konvertieren von JSON5 nach JSON Daten verloren?
Kommentare – sie haben keine legale JSON-Darstellung, daher verwirft jeder Konverter sie absichtlich. Infinity, -Infinity und NaN verlieren ihren Wert und werden je nach Konverter zu null oder Strings. Alles andere überlebt: unzitierte Schlüssel bekommen Anführungszeichen, einfache werden zu doppelten, Hexadezimalzahlen kommen als derselbe Wert in Dezimalnotation an. Wenn die Kommentare wichtig sind, sollte die Datei dort bleiben, wo Kommentare erlaubt sind.
Sollte meine Konfiguration JSON5 oder YAML sein?
Wenn Ihre Toolchain bereits JSON5 spricht, bleiben Sie dabei – eine Migration kostet mehr, als die Kommentare wert sind. Bei einem Neuanfang ist YAML das erprobtere Format für Konfiguration durch Menschen, mit Block-Scalaren, Ankern zur Wiederverwendung und einem Jahrzehnt Tooling – um den Preis von Einrückungsempfindlichkeit und Typinferenz. Der Vorteil von JSON5: Es bleibt einen kleinen Schritt vom strikten JSON entfernt, daher ist es trivial, eine Konfiguration zu Maschinendaten zu befördern.
Wo kann ich die hier zitierten Standards nachlesen?
Welche verwandten Tools sollten Sie als Nächstes nutzen?
- JSON formatierenEinrückung und Sortierung einstellen, Kommentare entfernenÖffnen
- JSON validierenSyntax prüfen mit exakter Zeile und Spalte, per Klick reparierenÖffnen
- Was ist JSONLeitfaden in verständlicher SpracheÖffnen
- JSON vs. YAMLDirekter VergleichÖffnen
- Wie funktioniert Base64Leitfaden in verständlicher SpracheÖffnen
- JSON-ToolsJSON-Dokumente vergleichen, formatieren, validieren und erkunden.Öffnen