JSON-Formatierer

JSON ist eine strikte Untermenge dessen, was JavaScript-Objektliterale erlauben, und die Lücke zwischen beiden ist genau, wo die meisten „ungültiges JSON"-Fehler herkommen. Ein abschließendes Komma nach dem letzten Element in einem Array oder Objekt ist in modernem JavaScript legal, aber ein Syntaxfehler in JSON. Zeichenketten mit einfachen Anführungszeichen funktionieren in JavaScript einwandfrei und werden von JSON direkt abgelehnt, das doppelte Anführungszeichen verlangt. Nicht in Anführungszeichen gesetzte Objektschlüssel — `{name: "value"}` statt `{"name": "value"}` zu schreiben — sind eine gültige JavaScript-Abkürzung und in JSON ungültig. Keines davon sind obskure Randfälle; es sind genau die beim Schreiben von JavaScript erworbenen Gewohnheiten, die still ein Dokument erzeugen, das wie JSON aussieht, aber keines ist.

Kommentare sind die andere häufige Verwirrungsquelle, weil ziemlich viele JSON-ähnliche Konfigurationsdateiformate — und sogar manche bewusst genutzten von JSON abgeleiteten Formate — `//`- oder `/* */`-Kommentare erlauben, während die JSON-Spezifikation selbst überhaupt keine Kommentarsyntax hat. Eine „JSON"-Konfigurationsdatei, die tatsächlich Kommentare enthält, in einen strikten Parser einzufügen scheitert sofort, und die Lösung ist entweder die Kommentare zu entfernen oder anzuerkennen, dass die Datei von Anfang an nie standardmäßiges JSON verwendete.

Ein Parser, der nur „ungültiges JSON" meldet, ohne zu sagen wo, lässt Sie das gesamte Dokument mit bloßem Auge nach einem einzelnen fehlenden Komma oder einem nicht escapten Anführungszeichen absuchen, was nach ein paar Dutzend Zeilen wirklich mühsam wird. Die exakte Zeile und Spalte des ersten Problems zu melden verwandelt diese Suche in eine direkte Lokalisierung — der Fehler beschreibt ein bestimmtes Zeichen, kein vages allgemeines Versagen — was den Unterschied zwischen dem Reparieren einer großen API-Antwort in Sekunden statt Minuten manuellen Absuchens ausmacht.

Es lohnt sich zu beachten, dass der Fehler immer das *erste* Problem zeigt, das der Parser antrifft, nicht notwendigerweise jedes Problem im Dokument: Ein Dokument mit zwei Syntaxfehlern meldet den ersten, und ihn zu beheben kann den zweiten erst beim nächsten Versuch aufdecken, da ein Parser, der bereits gescheitert ist, die Struktur zu verstehen, nicht zuverlässig weiter nach weiteren Problemen über den ersten Verwirrungspunkt hinaus suchen kann.

Verschönertes JSON mit konsistenter Einrückung und Zeilenumbrüchen existiert für die Person, die es liest — eine API-Antwort debuggend, eine Konfigurationsdatei überprüfend, eine Datenstruktur auf einen Blick verstehend. Nichts von dieser Struktur ist für ein Programm wichtig, das dasselbe JSON analysiert, weshalb minifizierte Ausgabe jedes rein der menschlichen Lesbarkeit dienende Zeichen entfernt: Einrückung, Zeilenumbrüche, und jedes zwischen Tokens nicht zur Trennung nötige Leerzeichen. Die dargestellten Daten sind in beiden Formen identisch; nur die Anzahl der Bytes, die zur Übertragung oder Speicherung nötig sind, unterscheidet sich, oft erheblich bei tief verschachtelten Strukturen.

Die praktische Regel ist einfach: Formatieren Sie JSON, während Sie damit arbeiten — lesen, debuggen, von Hand bearbeiten — und minifizieren Sie es, bevor es irgendwohin geht, das für seine Größe zahlt, wie der Body einer HTTP-Anfrage, ein URL-Query-Parameter, oder ein in einer längenbeschränkten Umgebungsvariable gespeicherter Wert.