JSON: Formatieren, Validieren und Reparieren von Kaputtem
Fügen Sie eine API-Antwort, eine Konfiguration oder ein Log-Fragment ein — und Sie erhalten eine lesbare Ansicht, einen Baum und eine Liste von allem, was nicht dem Standard entspricht, mit genauer Zeile und Position. Alles wird in Ihrem Browser geparst: Die Daten werden nirgendwohin gesendet und nirgends gespeichert.
.json hierher — die Datei wird lokal gelesen. Einfügen können Sie auch, was noch kein gültiges JSON ist: ein Log, eine API-Antwort mit Kommentaren, ein Fragment mit abschließenden Kommas.
Schlüssel und Reihenfolge bleiben erhalten, die Zahlenschreibweise ist unverändert.
Fügen Sie oben JSON ein und drücken Sie «Verarbeiten».
Fügen Sie oben JSON ein und drücken Sie «Verarbeiten».
Die Daten verlassen Ihren Browser nicht — Parsen und Formatieren laufen lokal, ohne Versand an einen Server.
Vier Fassungen des Standards und worin sie sich unterscheiden
JSON wird von mehreren Dokumenten beschrieben, und sie sind nicht deckungsgleich. Die Wahl der Spezifikation verändert, was das Werkzeug als Fehler wertet. RFC 4627 (2006) — die ursprüngliche. Ein Dokument der obersten Ebene darf nur ein Objekt oder ein Array sein; eine einzelne Zahl oder Zeichenkette ist unzulässig. Genau auf diese Fassung stützen sich manche alten Bibliotheken bis heute. RFC 7159 (2014) — erlaubte jeden Wert auf oberster Ebene. Seither sind 42 und "Text" eigenständige JSON-Dokumente. RFC 8259 (2017) — die geltende. Sie ergänzte die UTF-8-Pflicht für den Austausch zwischen Systemen und legte fest, dass Namen innerhalb eines Objekts eindeutig sein müssen. ECMA-404 — beschreibt nur die Syntax. Doppelte Schlüssel verbietet sie nicht, einzelne Surrogate erwähnt sie nicht, daher ist der Satz an Warnungen hier am kürzesten. Im Zweifel bei RFC 8259 bleiben: Es ist das strengste der geltenden Regelwerke, und was es besteht, wird überall angenommen.
Warum ein eigener Parser statt JSON.parse des Browsers
Der eingebaute Parser ist auf Geschwindigkeit ausgelegt, nicht auf Diagnose. Bei denselben Daten schweigt er dort, wo ein Werkzeug sprechen sollte: Eine Meldung ohne Koordinaten. Der Browser sagt «Unexpected token» und einen Offset in Zeichen; hier bekommen Sie Zeile, Position und was genau erwartet wurde. Ein Fehler für das ganze Dokument. Nach dem ersten Fehlschlag erholt sich das Parsen und zeigt die übrigen, statt Sie einzeln nachbessern zu lassen. Doppelte Schlüssel gehen stillschweigend durch. JSON.parse behält den letzten Wert, und der Verlust fällt erst in der Produktion auf. Die Zahlenschreibweise geht verloren. 1.0 wird zu 1, und eine Ganzzahl über neun Billiarden ändert ihre letzten Ziffern — genau so gehen Bezeichner aus der Datenbank kaputt. Die Reihenfolge der Schlüssel in der Ausgabe bleibt wie in der Quelle, bis Sie selbst nach Sortierung fragen. Zahlen werden hier standardmäßig so ausgegeben, wie sie geschrieben wurden: Das Werkzeug zeigt das Dokument, nicht das Ergebnis seiner Interpretation.
Was der Reparaturmodus genau in Ordnung bringt
Echte Daten sind selten sauberes JSON. Der Reparaturmodus bringt das, was aus Konfigurationen, Logs und fremden APIs kommt, auf den Standard: Kommentare // und /* */ werden entfernt; Kommas vor einer schließenden Klammer werden gelöscht; einfache und typografische Anführungszeichen werden auf doppelte vereinheitlicht; Schlüssel ohne Anführungszeichen und numerische Schlüssel werden in Anführungszeichen gesetzt; True, NULL, None, undefined werden zu true, false, null; NaN und Infinity werden zu null, denn Zahlen ohne endlichen Wert gibt es in JSON nicht; die Zahlenschreibweise — überflüssiges Plus, Punkt am Rand, führende Nullen; Steuerzeichen in Zeichenketten werden maskiert; BOM am Dateianfang und die JSONP-Hülle werden entfernt. Keine Korrektur geschieht stillschweigend: Jede landet mit der Anzahl der Fälle in der Liste. Passt Ihnen das Ergebnis nicht, schalten Sie das Häkchen ab, und das Dokument wird geprüft, wie es ist.