JSON prüfen

Füge JSON ein und finde heraus, ob es sich parsen lässt — und wenn nicht, wo genau. Die Antwort ist eine Zeilennummer, eine Spalte und die Zeile selbst, mit einem Zeiger unter dem Zeichen, an dem der Parser aufgegeben hat. „Unerwartetes Token“ sagt dir nämlich nichts, was du nicht schon wusstest.

Ergebnis

Die Antwort erscheint hier, während du tippst.

  • Wo es läuft

    Es wird nichts hochgeladen, weil es keine Datei gibt — gerechnet wird in dieser Seite.

  • Keine Warteschlange, kein Konto

    Es antwortet so schnell, wie dein Rechner es hergibt, und fragt nie, wer du bist.

  • So oft du willst

    Nichts wird gezählt und nichts begrenzt — noch einmal zu antworten kostet uns nichts.

So funktioniert es

  1. Füge das Dokument in das Feld ein.
  2. Lässt es sich parsen, bekommst du seine Form, die Anzahl der Schlüssel und die Verschachtelungstiefe.
  3. Lässt es sich nicht parsen, bekommst du Zeile, Spalte und einen Zeiger unter dem Zeichen.

Die Fehlermeldung ist das eigentliche Produkt

Dass JSON ungültig ist, sagt einem alles Mögliche — die Konsole eines Browsers erledigt das in einer Zeile. Wertvoll ist das Wo, und darin ist jeder Parser schlecht, jedenfalls auf eine Art, mit der man arbeiten könnte. „Unerwartetes Token }“ in einer vierhundert Zeilen langen Datei ist eine Feststellung des Offensichtlichen ohne Adresse.

Diese Seite nennt deshalb Zeile und Spalte, druckt diese Zeile ab und setzt einen Zeiger unter das Zeichen. In der Praxis reicht das fast immer, um das Problem zu sehen, ohne die Datei zu öffnen: Ein fehlendes Komma erkennt man, sobald man die Zeile darüber sieht, und der Zeiger steht fast immer auf dem Token, das nach dem Vergessenen kam.

Der Parser hält nach dem Fehler an, nicht auf ihm

Das ist das Nützlichste, was man über JSON-Fehlermeldungen wissen kann. Ein Parser ist zufrieden, bis etwas auf das Vorangegangene nicht mehr folgen kann — ein fehlendes Komma am Ende von Zeile 12 wird also am Anfang von Zeile 13 gemeldet, wo der nächste Schlüssel auftaucht und dort nicht stehen darf.

Also nach oben schauen. Der Zeiger markiert das erste Zeichen, das nicht mehr angenommen werden konnte; falsch ist meist das Ende der vorherigen Zeile oder der vorherige Wert. Der Extremfall ist eine fehlende schließende Klammer: Die wird am Dateiende gemeldet, wie weit weg das auch sein mag.

Jede Engine formuliert es anders, deshalb wird die Zeile gerechnet

Für JSON-Parse-Fehler gibt es keinen Standard. Chrome und Node sagen „at position 42“ und hängen in neueren Versionen Zeile und Spalte an. Firefox nennt Zeile und Spalte und keine Position. Safari nennt bei manchen Fehlern beides nicht.

Diese Seite nimmt den Zeichen-Offset, wo es einen gibt, und rechnet Zeile und Spalte selbst aus — die Antwort ist damit in jedem Browser dieselbe statt der jeweiligen lokalen Formulierung. Wo eine Meldung weder das eine noch das andere trägt, sagt sie das, statt zu raten: Eine falsche Zeilennummer in einer langen Datei kostet mehr Zeit als gar keine.

Was „gültig“ hier heißt und was nicht

Es heißt, dass das Dokument syntaktisch JSON ist: Die Klammern gehen auf und zu, die Zeichenketten sind korrekt in Anführungszeichen und maskiert, die Zahlen sind Zahlen. Das prüft ein Parser, und das ist es, was scheitert, wenn irgendetwas deine Datei mit einer nichtssagenden Meldung ablehnt.

Es heißt nicht, dass das Dokument die richtige Form hat. Ob es die Felder enthält, die eine API erwartet, ob ein Wert im zulässigen Bereich liegt, ob ein Datum ein Datum ist — das ist Schema-Validierung und braucht ein Schema. Wenn dein JSON hier durchgeht und trotzdem abgelehnt wird, ist das Problem von der Syntax zur Bedeutung gewandert und der Fehler, den du suchst, ein anderer.

Vier Fehler machen fast alle aus

Ein Komma vor einer schließenden Klammer — in JavaScript erlaubt, in JSON5 erlaubt, in JSON nicht, und der Grund, aus dem die meisten hier landen. Ein einfaches Anführungszeichen, wo JSON ein doppeltes verlangt. Ein nicht maskiertes Anführungszeichen oder ein Backslash innerhalb einer Zeichenkette, was meist von einem eingefügten Windows-Pfad kommt. Und ein Kommentar, den es in JSON gar nicht gibt.

Der fünfte ist seltener und schwerer zu sehen: ein nicht maskiertes Steuerzeichen in einer Zeichenkette, also ein echter Zeilenumbruch oder Tabulator, der hineinkopiert statt als Maskierung geschrieben wurde. In den meisten Editoren ist er unsichtbar, und man sollte ihn vermuten, wenn der Zeiger auf etwas zeigt, das völlig in Ordnung aussieht.

Was die Zahlen unter einem gültigen Dokument sagen

Der Typ der obersten Ebene, die Anzahl der Schlüssel über das ganze Dokument, die Verschachtelungstiefe und die Größe in Bytes. Sie stehen dort, weil „gültig“ allein ein Ja ohne Inhalt ist — und weil jede der vier Zahlen eine Frage beantwortet, die tatsächlich jemand hat.

Auf die Verschachtelungstiefe lohnt sich der Blick am meisten. Alles jenseits von etwa sechs Ebenen ist meist ein Datenmodell, das gewachsen statt entworfen ist, und ein verlässlicher Hinweis darauf, dass der Code, der das Dokument verarbeitet, unangenehm werden wird. Schlüssel werden nach Vorkommen und nicht nach verschiedenen Namen gezählt: Die Frage lautet, wie viel drinsteckt, nicht wie viele Feldnamen es gibt.

Der Tabulator und der Zeiger

Ein Tabulator ist für die Spaltenzählung ein Zeichen und für das Auge acht Spalten. Ein in Zeichen gezählter Zeiger landet in einer mit Tabulatoren eingerückten Datei also nirgendwo in der Nähe des Problems — und mit Tabulatoren eingerückt sind sehr viele JSON-Dateien.

Deshalb werden Tabulatoren in der abgedruckten Zeile durch je ein Leerzeichen ersetzt, bevor der Zeiger gesetzt wird. Die Zeile sieht dadurch schmaler aus als in deinem Editor; der Zeiger steht dafür unter dem richtigen Zeichen, und das ist die nützlichere von beiden Eigenschaften.

Warum auch das Prüfen lokal passiert

Ein Dokument, das geprüft wird, ist fast immer eines, das gerade irgendwo in der Produktion scheitert — und genau das sind die Dokumente, die man keinem Fremden geben sollte. Es ist dieselbe Kategorie wie die Tokens auf der Base64-Seite und verdient dieselbe Behandlung.

Das Parsen erledigt der eingebaute Parser deines Browsers in dieser Seite. Es wird nichts gesendet, und das Netzwerk-Panel ist die Art, das zu prüfen, statt einem Satz auf einer Marketingseite zu glauben.

BOM und unsichtbare Zeichen

Ein UTF-8-Byte-Order-Mark am Dateianfang ist unsichtbar und für einen strengen JSON-Parser ein Fehler an Position null. Wer eine Datei aus einem Windows-Editor exportiert oder aus einer Tabellenkalkulation gespeichert hat, hat gute Chancen auf eines — und die Meldung „unerwartetes Zeichen“ ganz am Anfang eines Dokuments, das offensichtlich mit einer Klammer beginnt, ist fast immer genau das.

Verwandt und ebenso unsichtbar: ein geschütztes Leerzeichen aus einer Textverarbeitung, ein Zero-Width-Space aus einer Webseite, ein Zeilenumbruch mitten in einer Zeichenkette. Alle drei sehen im Editor aus wie nichts und sind für den Parser etwas. Wenn der Zeiger auf eine völlig unauffällige Stelle zeigt, ist das die Spur, der man folgen sollte.

Prüfen ist nicht dasselbe wie formatieren

Die Formatierseite lehnt ungültiges JSON ebenfalls ab, sagt aber nur, dass es ungültig ist — und das ist Absicht: Wer formatieren wollte, will sein Dokument zurück und keine Diagnose. Ein Zeiger mitten in einer Ausgabe, die eigentlich das eingerückte Dokument sein sollte, wäre eine Antwort auf eine nicht gestellte Frage.

Diese Seite ist die andere Hälfte davon. Sie gibt kein formatiertes Dokument zurück, weil das hier niemand sucht — sie beantwortet ausschließlich das Warum. Zwei Seiten für zwei Fragen, statt einer, die beides halb macht.

JSON prüfen: häufige Fragen

Warum zeigt es auf eine Zeile, die richtig aussieht?

Weil ein Parser nach dem Fehler anhält und nicht auf ihm. Ein fehlendes Komma am Ende von Zeile 12 wird am Anfang von Zeile 13 gemeldet, wo der nächste Schlüssel steht und auf das Vorangegangene nicht folgen kann. Sieh dir die Zeile über dem Zeiger an oder den vorherigen Wert.

Es sagt, mein Dokument sei gültig, aber meine API lehnt es trotzdem ab. Warum?

Dann liegt es an der Form und nicht an der Syntax. Hier wird geprüft, ob sich das Dokument parsen lässt — Klammern ausgeglichen, Zeichenketten korrekt, Zahlen numerisch. Ob es die erwarteten Felder hat und die Werte im zulässigen Bereich liegen, ist Schema-Validierung und braucht ein Schema.

Warum gibt es manchmal keine Zeilennummer?

Weil der Browser keine geliefert hat. Für JSON-Parse-Fehler gibt es keinen Standard, und manche Engines nennen bei bestimmten Fehlern weder Position noch Zeile. Statt zu raten, sagt die Seite das — eine falsche Zeilennummer in einer langen Datei kostet mehr Zeit als gar keine.

Sind Kommentare oder ein Komma am Ende erlaubt?

Beides nicht, und das ist keine Strenge dieser Seite. JSON hat keine Kommentare und kein Komma vor der schließenden Klammer; JSON5 und JSONC haben beides und sind andere Sprachen. Wenn deine Datei das braucht, ist sie kein JSON, und ein strenger Parser wird sie überall ablehnen.

Wird mein Dokument zum Prüfen hochgeladen?

Nein. Das Parsen passiert in dieser Seite, und es wird nichts gesendet — das Netzwerk-Panel bestätigt es. Ein Dokument, das geprüft wird, ist fast immer eines, das gerade irgendwo in der Produktion scheitert, und genau die sollte man keinem Fremden geben.

Weitere Werkzeuge