JSON formatieren

Die vier Fehler, die 90 Prozent ausmachen

JSON ist eine strenge Sprache mit sehr wenigen Regeln — deshalb wiederholen sich die Fehler:

1. Komma nach dem letzten Element. Der häufigste Fall, weil JavaScript es erlaubt und JSON nicht:

{ "a": 1, "b": 2, }   ← das letzte Komma ist ungültig

2. Einfache statt doppelte Anführungszeichen. JSON kennt nur ". {'a': 1} ist gültiges JavaScript, aber kein JSON.

3. Schlüssel ohne Anführungszeichen. {a: 1} funktioniert in JavaScript und scheitert in JSON — jeder Schlüssel braucht sie.

4. Fehlendes Komma zwischen zwei Einträgen. Passiert vor allem beim Zusammenkopieren aus mehreren Quellen.

Dazu kommen zwei Werte, die viele überraschen: NaN und Infinity sind kein gültiges JSON, und einfache Zeilenumbrüche innerhalb einer Zeichenkette müssen als \n geschrieben werden.

Die Fehlerposition richtig lesen

Der Browser meldet die Stelle, an der das Parsen abgebrochen ist — und die liegt fast immer hinter dem eigentlichen Fehler. Ein fehlendes Komma in Zeile 12 fällt erst auf, wenn in Zeile 13 etwas steht, das dort nicht stehen dürfte.

Praktisch heißt das: Springt die Meldung auf Zeile 13, sieh dir Zeile 12 an. Und wenn die Position ganz am Ende der Datei liegt, fehlt meist eine schließende Klammer irgendwo weiter oben.

Einrückung: zwei oder vier?

Beides ist üblich, und die Wahl gehört zum Projekt, nicht zum Geschmack. Zwei Leerzeichen sind im JavaScript- und Web-Umfeld verbreitet, vier in vielen Backend- und Konfigurationswelten. Wichtig ist nur Einheitlichkeit — gemischte Einrückung in einer Datei erzeugt in der Versionsverwaltung Änderungen, die keine sind.

Für Dateien, die im Git liegen, lohnt sich außerdem: formatiert speichern, nicht verkleinert. Eine einzeilige JSON-Datei erzeugt bei jeder Änderung einen unlesbaren Diff über die gesamte Zeile.

Wofür Verkleinern gut ist

Verkleinern lohnt sich dort, wo JSON übertragen und nicht gelesen wird: API-Antworten, in HTML eingebettete Konfiguration, Daten in einer URL. Bei größeren Strukturen sind 20 bis 30 Prozent weniger Bytes realistisch, weil Einrückung bei tief verschachtelten Objekten erstaunlich viel Platz einnimmt.

Umgekehrt gilt: Alles, was ein Mensch anfassen soll — Konfigurationsdateien, Beispieldaten, Fixtures — bleibt formatiert.

Was viele übersehen

• Reihenfolge von Schlüsseln ist nicht garantiert. Die Spezifikation sichert sie nicht zu. In der Praxis behalten die meisten Umgebungen sie bei, aber Programme sollten sich nicht darauf verlassen.
• Zahlen sind Fließkommazahlen. Sehr große Ganzzahlen — etwa IDs jenseits von etwa 9 Billiarden — verlieren beim Einlesen Genauigkeit. Deshalb schicken viele APIs solche IDs bewusst als Zeichenkette.
• JSON kennt kein Datum. Was aussieht wie ein Datum, ist eine Zeichenkette. Verlass dich auf ISO-8601 mit Zeitzone, sonst rätselt der Empfänger.
• Doppelte Schlüssel sind formal erlaubt. Die meisten Parser nehmen den letzten. Verlassen sollte man sich darauf nicht — es ist fast immer ein Fehler in der erzeugenden Stelle.

Passt dazu

Wenn du prüfen willst, wie viele Zeichen eine verkleinerte Ausgabe hat — etwa gegen ein Feldlimit —, zählt der Zeichenzähler mit und ohne Leerzeichen. Den vollständigen deutschen Werkzeugkasten findest du unter alle Tools.