JSON-Fehlermeldungen nachschlagen: vom Fehlertext direkt zur Lösung

Kurz gesagt: Bei einem JSON.parse-Fehler zuerst Position und Token greifen; eine Position von 0 bedeutet, nach einer HTML-Antwort, einem BOM oder dem falschen Typ zu suchen, und eine „Expected“-Meldung bedeutet, das vorangehende Zeichen anzusehen – nicht ab der gemeldeten Position zeilenweise neu lesen.

Der Fehlertext ist kein Rauschen – er ist die Antwort. Der Parser sagt Ihnen, auf welches Zeichen er gestoßen ist, was er erwartet hat und was tatsächlich kam. Nach der Fehlermeldung zu suchen ist besser, als das ganze Dokument von Hand neu zu schreiben.

Jeder JSON.parse()-Fehler hat drei Teile: die Position (ein Zeichenoffset oder Zeile/Spalte), die Erwartung (Expected...) und die Realität (Unexpected token X oder „xxx is not valid JSON“). Die Engines formulieren sie unterschiedlich – Chrome und Node (V8) sagen Expected ',' or '}' after property value in JSON at position 25, Firefox sagt JSON.parse: expected ',' or '}' after property value in object at line 3 column 1, Safari sagt JSON Parse error: Expected ',' or '}' – aber alle drei zeigen auf denselben Syntaxbruch. Beim Nachschlagen ignorieren Sie die Formulierung und greifen die drei Fakten: welches Zeichen, was wurde erwartet, was kam an.

1. Die Nachschlagetabelle mit 12 Fehlern

Die linke Spalte ist das am besten identifizierbare Fragment aus Ihrer Konsole (V8-Formulierung). Firefox-/Safari-Varianten stehen in Klammern.

Die ersten beiden verdienen einen genaueren Blick, denn keine bedeutet „Ihr JSON ist falsch“, sondern „was Sie erhalten haben, ist nicht das, was Sie denken“.

2. Drei häufige Ursachen für einen Fehler an Position 0

Eine Position von 0 bedeutet, dass schon das allererste Zeichen unzulässig ist. Wenn nichts verdächtig aussieht, ist das Zeichen wahrscheinlich unsichtbar. Drei übliche Verdächtige:

Erstens: <, also HTML. Das ist der häufigste Parse-Fehler in der Produktion. Eine falsche URL, eine abgelaufene Sitzung, die das Gateway weiterleitet, oder ein Server-Fehlertemplate – der Body beginnt mit <!DOCTYPE html> und der Parser gibt beim ersten Zeichen auf. Der richtige Schritt ist, das Netzwerk-Panel zu öffnen, die rohe Antwort zu lesen und dann den API-Aufruf zu reparieren, nicht das JSON.

Zweitens: ein BOM oder Zero-Width-Zeichen. Von Windows Notepad gespeicherte Dateien beginnen oft mit einem UTF-8-BOM (\uFEFF), und aus Webseiten oder Chat-Apps kopierter Text kann Zero-Width-Leerzeichen (\u200B–\u200D) tragen. Für Sie unsichtbar, für den Parser offensichtlich:

复制// Strip BOM and zero-width characters before parsing
const cleaned = raw.replace(/^\uFEFF/, '').replace(/[\u200B-\u200D]/g, '');
const data = JSON.parse(cleaned);

Drittens: der falsche Typ. JSON.parse(undefined) meldet "undefined" is not valid JSON; JSON.parse(someObject) meldet Unexpected token o (das Objekt wurde zu "[object Object]" umgewandelt, und o ist an Position 1 unzulässig). Beide bedeuten „die Daten sind bereits geparst“ oder „es gab nie Daten“. Prüfen Sie den Typ, nicht die Syntax:

复制let data = text;
if (typeof data === 'string') {
  data = JSON.parse(data); // Parse only when it really is a string
}

3. Die Position zeigt stromabwärts; die Ursache liegt stromaufwärts

Zwei Fehler führen bei der Ortsangabe in die Irre, und es sind die beiden am häufigsten falsch gelesenen Einträge der Tabelle:

• Ein fehlendes Komma: {"a": 1 "b": 2} meldet Expected ',' or '}' after property value in der Zeile von "b". Die Meldung ist korrekt, aber die Behebung gehört ans Ende der vorherigen Zeile.
• Eine fehlende schließende Klammer: Bei tiefer Verschachtelung fehlt ein } oder ], der Parser schluckt alles bis zum Eingabeende und meldet Unexpected end of JSON input. Die Position ist das Dateiende; die echte Lücke kann weit davor liegen. Suchen Sie rückwärts nach dem zuletzt nicht geschlossenen { oder [ – Paare zählen ist besser als Schätzen mit den Augen.

Die allgemeine Technik ist Bisektion: den Text vor der gemeldeten Position abschneiden und allein parsen. Parst er, liegt das Problem nahe der gemeldeten Position; wenn nicht, weiter rückwärts halbieren. Die Grenze des ersten scheiternden Teils ist die echte Fehlerstelle. Bei großen Dateien das Dokument zuerst formatieren – mit ausgerichteten Einrückungen ist die fehlende Ebene auf einen Blick sichtbar (der Online-JSON-Formatter eignet sich dafür).

4. Vier „scheinbar gesunde“ Zustände, die parsen, aber falsch arbeiten

Schlimmer als ein Fehler ist kein Fehler und falsche Daten. In allen vier Fällen ist das JSON gültig und der Parser zufrieden – das Problem ist die Form der Daten:

1. Doppelte Kodierung: Das ganze Dokument wurde zweimal JSON.stringify-t, das Parsen liefert also einen String, kein Objekt. Ist typeof result === 'string', erneut parsen – aber die doppelte Serialisierung an der Quelle finden und beheben.
2. Doppelte Schlüssel überschreiben stillschweigend: {"name": "Tom", "name": "Jerry"} ist gültiges JSON, die meisten Parser beschweren sich nicht, und der zweite Wert gewinnt. Das beißt beim Zusammenführen von Daten aus mehreren Quellen; machen Sie es mit einem strengen JSON-Validator sichtbar, bevor es beißt.
3. NDJSON als ein Dokument behandelt: Streaming-APIs geben ein Objekt pro Zeile aus; das ganze Textstück zu parsen scheitert mit Unexpected non-whitespace character after JSON. An \n trennen und zeilenweise parsen.
4. Stiller Präzisionsverlust bei Zahlen: Ganzzahlen oberhalb von 2^53 - 1 (Snowflake-IDs) kommen mit auf null gesetzten Endziffern zurück, ganz ohne Fehler. IDs als Strings übertragen.

Der gemeinsame Faden: Der Parser glaubt, alles sei in Ordnung. Wenn API-Daten falsch aussehen, geben Sie zuerst die ersten 80 Zeichen des Rohtexts und dessen typeof aus – die Form bestätigen, bevor über den Inhalt gesprochen wird.

5. Fehler beim Schreiben unmöglich machen

Die Nachschlagetabelle ist das Werkzeug danach; Vorbeugen ist das Werkzeug davor. Vier Gewohnheiten fangen die meisten Fehler ab, bevor sie entstehen:

复制// 1. Two checks before parsing any response
const response = await fetch('/api/users');
if (!response.ok) {
  throw new Error(`HTTP ${response.status}: the API returned no data`);
}
const contentType = response.headers.get('content-type') ?? '';
if (!contentType.includes('application/json')) {
  throw new Error(`Expected JSON, got ${contentType}`);
}
const data = await response.json(); // 2. json() already parses — do not parse again

• Serialisieren zum Erzeugen, niemals zusammenkleben: JSON.stringify() behandelt Anführungszeichen, Zeilenumbrüche und Steuerzeichen korrekt; von Hand gebaute Strings sind die wichtigste Quelle von Bad control character und Unterminated string.
• Immer abfangen: Ein geworfener JSON.parse-Fehler ist ein synchroner Absturz, wenn ihn nichts abfängt. Bei nicht vertrauenswürdiger Eingabe – localStorage, externe Dateien – braucht der catch-Block einen Standardwert oder eine ausdrückliche Fehlermeldung.
• Struktur an das Schema delegieren: Gültige Syntax bedeutet nicht gültige Struktur. Fehlende Felder und falsche Typen gehören in die JSON-Schema-Validierung an der Grenze; siehe was JSON Schema löst.

6. Der schnelle Entscheidungsweg

Der ganze Artikel lässt sich zu einer Entscheidungsreihenfolge verdichten. Bei einem Fehler zuerst Position und Token greifen:

1. Position 0 → die drei Ursachen prüfen: < (HTML), BOM, falscher Typ;
2. end of input → auf einen leeren oder abgeschnittenen Body prüfen, dann rückwärts nach nicht geschlossenen Klammern suchen;
3. Expected ... → das vorangehende Zeichen ansehen; meist ein fehlendes Komma oder Anführungszeichen;
4. after JSON data → mehrere Dokumente wurden verkettet; zeilenweise trennen;
5. Parst sauber, aber Daten sehen falsch aus → die vier „scheinbar gesunden“ Prüfungen ausführen.

Zusammen mit der schrittweisen Triage in JSON-Parse-Fehler beheben lösen sich 90 % der Parse-Probleme innerhalb von fünf Minuten. Setzen Sie sich den Fehlertext selbst ins Lesezeichen – er ist das Debug-Log, das der Parser für Sie geschrieben hat, seine Formulierung ändert sich alle drei Jahre, und ein Blick zahlt sich ein Jahr aus.

Was bedeutet „Unexpected token in JSON“?

Der Parser stieß auf ein Zeichen, das an dieser Stelle in der JSON-Grammatik unzulässig ist. Das Token ist das abgelehnte Zeichen: < bedeutet meist, die API lieferte HTML, ' bedeutet einfache Anführungszeichen, / bedeutet einen Kommentar, und ein einfacher Buchstabe bedeutet meist einen unquotierten Schlüssel oder ein nur in JavaScript gültiges Literal wie undefined oder NaN. Zuerst das Token lesen, dann die Position – und die Ursache verengt sich auf eine.

Wie behebe ich „Unexpected end of JSON input“?

Zwei Quellen: leere Eingabe (ein leerer Response-Body oder ein leerer String in localStorage) oder abgeschnittene Eingabe (ein unterbrochener Download, eine Kopie ohne die letzte Zeile, ein Größenlimit). Den Leerfall mit if (!text) return behandeln; dann die Vollständigkeit prüfen und das zuletzt nicht geschlossene {, [ oder " schließen. Beachten Sie, dass der Fehler auch von einer tief verschachtelten fehlenden Klammer stammen kann – die Position ist dann zufällig das Dateiende.

Warum melden Chrome, Firefox und Safari Fehler unterschiedlich?

Die drei Browser bringen unterschiedliche JS-Engines mit (V8, SpiderMonkey, JavaScriptCore), und jede formuliert ihre Fehler auf eigene Weise; MDN dokumentiert alle offiziellen Varianten. Aber alle drei Fehler tragen dieselben drei Elemente – Position, Erwartung, Realität – mit eins-zu-eins derselben Semantik. Übersetzen Sie in die V8-Formulierung und nutzen Sie diese Tabelle unverändert.

Die Fehlerposition zeigt auf eine Stelle, die in Ordnung aussieht – was nun?

Der echte Fehler liegt früher. Typische Fälle: ein fehlendes Komma (in der nächsten Zeile gemeldet) und eine fehlende schließende Klammer (am Dateiende gemeldet). Gehen Sie von der gemeldeten Position Token für Token rückwärts, oder halbieren Sie: den ersten Teil allein parsen, und die Grenze des ersten scheiternden Teils ist die wahre Fehlerstelle.