JSON-Formatierer

Was dieser JSON-Formatierer macht

JSON (JavaScript Object Notation) ist das gängigste Format, um strukturierte Daten zwischen Programmen zu bewegen – API-Antworten, Konfigurationsdateien, Log-Zeilen und mehr. Es ist auf Kompaktheit ausgelegt, was es auch schwer lesbar macht, sobald Objekte einige Ebenen tief verschachtelt sind oder in einer einzigen Zeile ankommen. Dieses Werkzeug nimmt beliebiges JSON, das du einfügst, und schreibt es auf zwei Arten neu: verschönert, mit einheitlicher Einrückung, damit die Struktur auf einen Blick erkennbar ist, oder minimiert, von jedem optionalen Leerzeichen befreit, um beim Senden so klein wie möglich zu sein.

Es validiert außerdem beim Formatieren. Da es den Text vor dem erneuten Serialisieren parst, erzeugt ungültiges JSON nie eine irreführende Ausgabe – stattdessen erhältst du Zeile und Spalte, an der das Parsen fehlschlug, soweit es sie ermitteln kann, und springst direkt zum Problem.

Verschönern vs. Minimieren – wann was

Die beiden Modi verfolgen entgegengesetzte Ziele, und die meisten Arbeitsabläufe nutzen beide in verschiedenen Phasen:

• Verschönere, wenn du liest oder debuggst: eine API-Antwort inspizieren, zwei Payloads vergleichen oder eine Konfigurationsdatei in einem Pull Request prüfen. Einrückung macht aus einer Textwand einen durchsuchbaren Baum.
• Minimiere, wenn du auslieferst: JSON in HTML einbetten, in einem Cookie oder Cache speichern oder im Rumpf einer Anfrage senden, wo jedes Byte zählt. Minimiertes JSON sind byte-genau dieselben Daten, nur ohne die Leerzeichen.

Die Einrückungsauswahl (2 Leerzeichen, 4 Leerzeichen oder Tab) betrifft nur die verschönerte Ausgabe. Zwei Leerzeichen ist die häufigste Konvention in JavaScript und im Web-Tooling; vier Leerzeichen oder Tabs passen zu Teams, die sie bevorzugen. Was du auch wählst, das Ergebnis bleibt gültiges JSON – die Einrückung ist rein kosmetisch.

Validierungsfehler lesen

Wenn das JSON ungültig ist, meldet das Werkzeug Zeile und Spalte des ersten Problems statt eines bloßen „ungültig“ – außer in dem einen Fall, den der Abschnitt darüber beschreibt, wohin Zeile und Spalte zeigen. Fehlermeldungen der Engines unterscheiden sich zwischen Browsern und lassen oft eine Position weg, deshalb wird der Ort unabhängig berechnet und zeigt auf eine sinnvolle Stelle zum Anfangen. Behebe den ersten Fehler und prüfe erneut – ein einzelnes verirrtes Zeichen wird oft zu mehreren scheinbaren Problemen.

Häufige JSON-Fehler

JSON ist strenger als die JavaScript-Objektliterale, denen es ähnelt. Das sind die Fehler, die am häufigsten auftreten:

• Abschließende Kommas: ein Komma nach dem letzten Element eines Objekts oder Arrays ist in JavaScript gültig, aber nicht in JSON.
• Einfache Anführungszeichen: JSON-Zeichenketten und -Schlüssel müssen doppelte Anführungszeichen verwenden. 'Wert' ist ungültig; "Wert" ist korrekt.
• Schlüssel ohne Anführungszeichen: jeder Objektschlüssel muss eine Zeichenkette in Anführungszeichen sein, daher muss { name: "x" } zu { "name": "x" } werden.
• Kommentare: JSON hat keine Kommentarsyntax. // und /* */ führen zu einem Parse-Fehler.
• Spezielle Zahlen: NaN, Infinity und -Infinity sind keine gültigen JSON-Zahlen.
• Falsche Anführungszeichen: „typografische Anführungszeichen“, die aus einer Textverarbeitung eingefügt wurden, sehen wie Anführungszeichen aus, sind aber andere Zeichen und werden nicht geparst.

Wohin die gemeldete Zeile und Spalte zeigen

Die Position ist nicht dort, wo du etwas weggelassen hast. Sie ist dort, wo der Parser zum ersten Mal auf etwas trifft, das dort nicht stehen darf, und das sind meist zwei verschiedene Stellen. Im Objekt unten fehlt Zeile 3 das Komma, das sie abschließen sollte – und das Werkzeug meldet Zeile 4, Spalte 3: das öffnende Anführungszeichen des nächsten Schlüssels. Bis zu diesem Anführungszeichen war nichts falsch, denn das Dokument hätte nach Zeile 3 gültig enden können; der Parser erfährt von dem Versäumnis also erst, wenn er auf etwas trifft, das weder ein Komma noch eine schließende Klammer ist.

{
  "id": 42,
  "name": "widget"
  "price": 9.99
}

• Ein fehlendes Komma wird am ersten Zeichen dessen gemeldet, was danach kommt – in eingerücktem JSON wie oben ist das die folgende Zeile, also lies die genannte Zeile zusammen mit der darüber.
• Ein überzähliges Komma wird an der schließenden Klammer gemeldet: Zeile 3, Spalte 1 für ein Objekt, dessen letztes Paar in Zeile 2 steht. Das Komma verspricht ein weiteres Paar, und die Klammer bricht dieses Versprechen.
• Eine nicht geschlossene Zeichenkette wird meist am Ende der Zeile gemeldet, in der sie begann, und nicht am öffnenden Anführungszeichen – denn das nächste Anführungszeichen in einer späteren Zeile kann sie woanders schließen. Ein Zeilenumbruch darf in einer JSON-Zeichenkette nicht vorkommen, also ist der Umbruch das erste Zeichen, das dort nicht stehen darf.
• Zeile 1, Spalte 1 bei einem Dokument, das perfekt aussieht, bedeutet meist eine Bytereihenfolge-Markierung. Manche Editoren schreiben eine, wenn sie als UTF-8 speichern; sie ist unsichtbar, sie steht vor der öffnenden Klammer, und JSON hat keinen Platz für sie.

Und wo das Werkzeug überhaupt keine Position ermitteln kann, meldet es den Fehlschlag ohne sie, statt eine geratene Koordinate zu nennen. Eine selbstsicher genannte Zeile und Spalte, die auf völlig korrekte Syntax zeigt, würde dich an der falschen Stelle suchen lassen, und das ist schlechter als nur zu wissen, dass das Dokument nicht parst.

Was das Formatieren verändert und was es bewahrt

Für fast jedes Dokument lautet die Antwort: Leerraum und nichts weiter. Aber das Werkzeug bearbeitet deinen Text nicht, sondern parst ihn in echte Werte und schreibt diese Werte neu aus – und fünf Dinge überleben diesen Rundweg nicht. Keines davon ist ein Fehler des Werkzeugs; jedes ist das, was die JSON-Spezifikation über eine Zahl oder ein Objekt sagt, und jedes ist zu kennen, bevor du die Ausgabe über dein Original klebst.

• Derselbe Schlüssel zweimal geschrieben: nur der letzte der beiden überlebt, denn ein Objekt kann einen Schlüssel nicht zweimal tragen. RFC 8259 sagt, Software, die ein Objekt mit doppelten Namen empfängt, verhalte sich unvorhersehbar, und ein anderer Parser behält vielleicht den ersten – also ist auch nicht verlässlich, welcher der beiden dir bleibt.
• Eine ganze Zahl mit mehr als fünfzehn Stellen: JSON-Zahlen werden als Gleitkommazahl doppelter Genauigkeit gelesen, die jede ganze Zahl bis zwei hoch dreiundfünfzig exakt hält – eine sechzehnstellige Zahl – also überlebt eine fünfzehnstellige Zahl immer und eine längere möglicherweise nicht. Füge 12345678901234567890 ein, und 12345678901234567000 kommt heraus. Lange Datenbank-Kennungen sind das üblichste Opfer: behalte sie als Zeichenketten, wenn du kannst.
• Exponent- und Nachnull-Formen werden normalisiert: 1e3 kommt als 1000 zurück und 1.50 als 1.5. Das ist dieselbe Zahl, auf die Standardweise geschrieben.
• Eine Größe außerhalb dessen, was dieses Format tragen kann, kommt als etwas anderes zurück: 1e400 hat keinen Wert in doppelter Genauigkeit und kommt als null zurück, und 1e-400 als 0. Ein langer Dezimalbruch wird auf die Genauigkeit gerundet, die das Format hat – genau wie eine lange ganze Zahl.
• Eine Escape-Sequenz wird zu dem Zeichen, das sie bezeichnet: \u00e9 kommt als é zurück, und ein maskiertes Surrogatpaar als das Emoji, das es buchstabiert. Für jeden Parser sind das dieselbe Zeichenkette; eine der beiden Schreibweisen ist einfach kürzer.

Die Schlüsselreihenfolge bleibt so, wie du sie geschrieben hast, mit einer Ausnahme, die zu kennen sich lohnt: ein Schlüssel, der nur aus Ziffern besteht und sich als schlichte nicht negative ganze Zahl unter etwa vier Milliarden liest, wird als Array-Index behandelt und kommt an den Anfang seines Objekts zurück, in numerischer Ordnung, wo auch immer du ihn hingeschrieben hast. Sonst bewegt sich nichts: kein anderer Schlüssel wird umgeordnet, und keiner wird hinzugefügt oder umbenannt. Wenn dir irgendetwas davon wichtig ist, minimiere statt zu verschönern und vergleiche das Ergebnis Zeichen für Zeichen mit deinem Original. Das ist der kürzeste Weg, zu sehen, was der Rundweg getan hat.

Wenn das gesuchte JSON in einer Zeichenkette steckt

Webhook-Protokolle, Nachrichten-Warteschlangen und Datenbankspalten tragen sehr oft ein ganzes JSON-Dokument als einen einzigen Zeichenketten-Wert, mit jedem Anführungszeichen darin maskiert. Das äußere Dokument ist völlig gültig, also verschönert das Werkzeug es und meldet es als gültig – und der Teil, für den du gekommen bist, bleibt eine lange Zeile Rückstriche. Nichts ist schiefgegangen: es sind zwei Dokumente, das eine in eine Zeichenkette des anderen gewickelt.

{
  "event": "order.created",
  "payload": "{\"id\":42,\"total\":19.99}"
}

Es zu lesen braucht daher zwei Durchgänge. Formatiere hier das äußere Dokument, kopiere, was zwischen den Anführungszeichen der gewünschten Zeichenkette steht, hebe die Maskierung auf und füge das Ergebnis erneut ein. Das Werkzeug JSON-String maskieren / demaskieren übernimmt diesen Zwischenschritt: seine Demaskierungsrichtung macht aus \" wieder " und aus der Zeile ein Dokument, das diese Seite formatieren kann. Wenn du kontrollierst, was die Datei erzeugt hat, liegt die bessere Lösung weiter oben: sende die Nutzlast als verschachteltes Objekt statt als Zeichenkette, dann ist kein Durchgang nötig.

Ein Objekt pro Zeile ist kein Dokument

Protokolldateien, API-Exporte und Streaming-Endpunkte enthalten häufig ein vollständiges JSON-Objekt pro Zeile; das Format heißt JSON Lines oder NDJSON. Jede Zeile ist für sich gültiges JSON, aber die Datei ist kein JSON-Dokument, denn ein JSON-Dokument enthält genau einen Wert oberster Ebene, und diese enthält mehrere, einen nach dem anderen und ohne etwas, das sie verbindet.

{"level":"info","msg":"started"}
{"level":"warn","msg":"retrying"}
{"level":"error","msg":"gave up"}

Füge das hier ein, und das Werkzeug meldet Zeile 2, Spalte 1: das erste Objekt endete sauber, und dann begann ein zweites da, wo das Dokument hätte fertig sein sollen. Von dort gibt es zwei Wege. Formatiere eine Zeile auf einmal – das willst du, wenn du einen einzelnen Protokolleintrag liest. Oder mach aus der Datei ein Dokument: setze die Zeilen in eckige Klammern und ein Komma an das Ende jeder Zeile außer der letzten – das willst du, wenn du das Ganze gleich in etwas laden willst, das ein Array erwartet.