JSON-Parse-Fehler beheben: Unexpected token Schritt für Schritt prüfen

Kurz gesagt: Bei einem Parse-Fehler die gemeldete Zeile und Spalte lesen, um das erste unzulässige Zeichen zu finden, und dann entscheiden, ob ein fehlendes Anführungszeichen, ein fehlendes Komma, ein nachfolgendes Komma, ein BOM oder eine Kürzung vorliegt – das ganze Dokument nicht von vorn neu lesen.

Eine Fehlermeldung sagt nie, „was falsch ist“; sie sagt nur, „wo der Parser nicht mehr weiterkam“. Diese beiden Positionen sind oft nicht dieselbe Stelle.

1. Zuerst den Fehler in Koordinaten übersetzen

Dasselbe fehlerhafte JSON erzeugt in verschiedenen Sprachen völlig unterschiedliche Fehler, aber alle lassen sich in „welche Zeile, welches Zeichen“ umrechnen:

Sobald Sie die Position haben, fügen Sie das JSON in den JSON-Online-Parser ein; das Werkzeug setzt den Cursor an die Fehlerstelle und hebt Zeilen- und Spaltennummer hervor – dieser Schritt spart 90 % des Zeichenabzählens mit bloßem Auge.

2. Sechs häufige Fehler

1. Nachfolgendes Komma

复制{
  "name": "json",
  "version": 1,
}

Vor } steht ein überzähliges Komma. Die JSON-Spezifikation erlaubt keine nachfolgenden Kommas, JavaScript-Objektliterale dagegen schon, deshalb tragen Konfigurationen, die aus Code kopiert wurden, am häufigsten eines. Behebung: das letzte Komma löschen; wenn diese Daten ohnehin in einer JS-Datei leben, stattdessen auf JSON5-Konvertierung umstellen, statt sie in JSON zu zwingen.

2. Einfache Anführungszeichen und unquotierte Schlüssel

复制{ 'name': 'json' }
{ name: "json" }

JSON-Strings dürfen nur doppelte Anführungszeichen verwenden, und Schlüssel müssen ebenfalls doppelt quotierte Strings sein. Diese beiden sind gelockerte Syntax von JSON5 / JavaScript, nicht JSON. Ein doppeltes Anführungszeichen innerhalb eines Strings muss als \" geschrieben werden, ein Backslash als \\.

3. Kommentare

复制{
  // Timeout in milliseconds
  "timeout": 3000
}

Die Grammatik von RFC 8259 kennt keinen Platz für Kommentare. Entweder die Kommentare löschen oder als .jsonc / .json5 speichern und einen Parser verwenden, der Kommentare unterstützt. Zu den Abwägungen zwischen den verschiedenen „Kommentarformen“ siehe Kommentare in JSON schreiben.

4. Rohe Zeilenumbrüche und Steuerzeichen in Strings

复制{"sql": "SELECT *
FROM t"}

JSON-Strings dürfen keine rohen Zeilenvorschübe, Tabulatoren oder Steuerzeichen U+0000–U+001F enthalten; sie müssen als \n, \t, \u0009 geschrieben werden. Wenn Sie mehrzeiligen Text in JSON stopfen, escapen Sie ihn zuerst in einem Editor oder behandeln Sie ihn einheitlich mit JSON minifizieren und escapen.

5. BOM-Kopf

Von Windows Notepad gespeichertes UTF-8 trägt die drei Bytes EF BB BF. JSON.parse meldet Unexpected token, wenn es auf ein BOM stößt, und das Auge kann es überhaupt nicht sehen. Erkennung: den Dateikopf hexadezimal ansehen oder den Inhalt in ein Online-Werkzeug kopieren und prüfen, ob das erste Zeichen als  erscheint. Behebung: als „UTF-8 ohne BOM“ speichern.

6. Abgeschnittener Inhalt

Ein Log, das nur die ersten 4096 Zeichen ausgegeben hat, eine API-Antwort, die ein Gateway abgeschnitten hat, ein unterbrochener Download – das Kennzeichen dieser Klasse ist „der Fehler liegt am Ende“ und die Klammerzahlen passen nicht. Zählen Sie zuerst die Klammern: Wenn die Schließungen von { und [ nicht übereinstimmen, ist es eine Kürzung, kein Syntaxfehler. In diesem Fall nichts reparieren – holen Sie die vollständigen Daten.

3. Zwei Fehlalarme bei chinesischem Text und Escaping

Chinesisch wird zu \u4e2d\u6587: Das ist gültiges JSON-Escaping, kein Kauderwelsch. Nach dem Parsen ist der Wert wieder chinesisch; die \u-Form zeigt sich nur, wenn man den Rohstring direkt ansieht. Wenn Sie ihn Menschen zeigen müssen, geben Sie ihn einfach mit dem Formatierungswerkzeug aus; um die Escaping-Strategie müssen Sie sich nur kümmern, wenn Chinesisch in einer URL oder einem Log überleben muss.

Chinesisch wird zu Kauderwelsch wie 涓枃: Das ist ein Kodierungsproblem, kein JSON-Problem. Es entsteht, wenn UTF-8-Bytes als GBK dekodiert werden, was dieses regelmäßige Muster „drei Zeichen stehen für ein chinesisches Zeichen“ erzeugt. Prüfen Sie den Content-Type: application/json; charset=utf-8 des Response-Headers und ob beim Lesen der Datei ausdrücklich encoding='utf-8' angegeben ist.

4. Ein Reparaturablauf in fünf Minuten

1. In das Werkzeug einfügen: Zuerst mit dem Online-Parser den ersten Fehler lokalisieren und nur einen nach dem anderen beheben;
2. Nach jeder Behebung validieren: nach jeder Änderung erneut parsen, damit gleichzeitige Reparaturen an mehreren Stellen nicht neue Fehler den alten verdecken lassen;
3. Einmal minifizieren: mit Minify Whitespace entfernen und erneut parsen; das unterscheidet „strukturelle Fehler“ von „Whitespace- oder Zeilenumbruchproblemen“;
4. Struktur vergleichen: wenn nach einer Änderung plötzlich ein Fehler auftaucht, mit JSON-Diff gegen die vorherige Version vergleichen; die Differenz ist meist genau ein Komma;
5. Feldvalidierung: wenn die Syntax durchgeht, aber die Geschäftslogik ablehnt (fehlendes Feld, falscher Typ), fällt das unter JSON-Schema-Validierung, nicht unter ein Syntaxproblem.

5. Warum von zwei „identisch aussehenden“ JSON-Schnipseln eines parst und das andere nicht

Die häufigste Ursache sind unsichtbare Zeichen: das vollbreite Komma ，, vollbreite Anführungszeichen “”, das geschützte Leerzeichen U+00A0, das Zero-Width-Leerzeichen U+200B. Auf dem Bildschirm sind sie kaum von ihren halbbreiten Gegenstücken zu unterscheiden, aber keines davon gehört zur JSON-Grammatik.

Es gibt nur einen Weg, das festzustellen: den Inhalt um das verdächtige Zeichen kopieren und die Codepoints Byte für Byte prüfen. Folgendes in einer Browser-Konsole ausgeführt listet jedes Zeichen auf, das nicht ASCII und außerhalb der chinesischen Bereiche liegt:

复制[...text].filter((ch) => {
  const code = ch.codePointAt(0);
  return code > 127 && !(code >= 0x4e00 && code <= 0x9fff);
});

Wenn 0x201c (linkes doppeltes Anführungszeichen), 0xff0c (vollbreites Komma) oder 0x00a0 in der Ausgabe erscheint, sind sie der Übeltäter.

6. Vorbeugen ist billiger als Reparieren

• Bei Konfigurationsdateien vor dem Commit eine Parse-Prüfung ausführen; eine Zeile in CI genügt: node -e "JSON.parse(require('fs').readFileSync('config.json','utf8'))";
• API-Antworten mit einer Serialisierungsbibliothek erzeugen; niemals Strings von Hand zusammenkleben – von Hand gebaute Strings sind die einzige Quelle nachfolgender Kommas und fehlender Anführungszeichen;
• Beim Loggen von JSON zuerst JSON.stringify aufrufen, statt es in ein Template zu interpolieren, damit eine halb geschriebene Payload nicht für eine vollständige Meldung gehalten wird.

FAQ

Wie lokalisiere ich die Position eines JSON-Syntaxfehlers schnell?

Nehmen Sie die Position oder Zeile/Spalte, die der Parser meldet; position ist ein zeichenbasierter Offset ab 0, keine Zeilennummer, während Java Jackson und Python Zeile und Spalte direkt liefern. Fügen Sie das JSON in den JSON-Online-Parser ein, und das Werkzeug setzt den Cursor an die Fehlerstelle und hebt Zeile und Spalte hervor. Liegt der Fehler am Anfang, prüfen Sie den Dateikopf auf ein BOM und suchen Sie unsichtbare Zeichen.

Warum tragen aus Code kopierte Konfigurationen so häufig ein nachfolgendes Komma?

Die JSON-Spezifikation verbietet nachfolgende Kommas, JavaScript-Objektliterale erlauben sie, deshalb bringt aus JS-Code kopierte Konfiguration leicht eines mit. Die Behebung ist einfach das Löschen des letzten Kommas; wenn die Daten ohnehin in eine JS-Datei gehören, passt eine Umstellung auf JSON5-Konvertierung besser, als sie in JSON zu zwingen.

Kann ich eine Konfigurationsdatei mit Kommentaren als normales JSON parsen?

Nein – die Grammatik von RFC 8259 kennt keinen Platz für Kommentare, direktes Parsen wirft also einen Fehler. Entweder die Kommentare löschen oder als .jsonc / .json5 speichern und einen Parser verwenden, der Kommentare unterstützt. Zu den Abwägungen der Kommentarformen siehe Kommentare in JSON schreiben.