{"id":13149,"date":"2026-09-24T12:45:00","date_gmt":"2026-09-24T10:45:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13149"},"modified":"2026-09-09T13:21:29","modified_gmt":"2026-09-09T11:21:29","slug":"tutorial-ein-json-prufen-bevor-es-in-ein-tag-wandert","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/web-entwicklung\/tutorials-de-web-entwicklung\/tutorial-ein-json-prufen-bevor-es-in-ein-tag-wandert\/","title":{"rendered":"Tutorial: Ein JSON pr\u00fcfen, bevor es in ein Tag wandert"},"content":{"rendered":"

Eine Nutzlast, die ein Parser verweigert, ist \u00e4rgerlich und harmlos: Etwas bricht sofort, an einer Stelle, und die Behebung dauert eine Minute. Eine Nutzlast, die ein Parser annimmt und anders liest als gemeint, ist weder das eine noch das andere.<\/p>\n

Beide Arten haben dieselbe Quelle. JSON sieht aus wie ein JavaScript-Objekt und ist ein deutlich engeres Format – und die Unterschiede zwischen beiden sind genau die folgende Liste.<\/p>\n

\n\"Eine
F\u00fcnf der sieben halten den Parser an. Die beiden anderen erzeugen ein Dokument, das sauber liest und etwas anderes bedeutet.<\/figcaption><\/figure>\n

Warum ein JavaScript-Objekt kein JSON ist<\/h2>\n

Alles, was in JSON g\u00fcltig ist, ist g\u00fcltiges JavaScript. Umgekehrt gilt das nicht, und in diesem Abstand wohnen die Fehler.<\/p>\n

{                                     \/\/ JavaScript, kein JSON\n  'order_id': 9007199254740993,       \/\/ einfache Anfuehrungszeichen\n  total: 129.90,                      \/\/ Schluessel ohne Anfuehrungszeichen\n  items: [ { sku: \"SKU-42\", qty: 2, } ],   \/\/ Komma vor der Klammer\n  rabatt: NaN,                        \/\/ kein JSON-Wert\n  \/* ein Kommentar *\/\n}<\/code><\/pre>\n
JSON erlaubt doppelte Anf\u00fchrungszeichen und sonst keine, verlangt f\u00fcr jeden Schl\u00fcssel Anf\u00fchrungszeichen, verbietet ein Komma vor einer schliessenden Klammer, kennt keine Kommentare und genau sieben Wertarten: Objekt, Liste, Zeichenkette, Zahl, true<\/code>, false<\/code> und null<\/code>. Es gibt kein undefined<\/code>, kein NaN<\/code>, kein Infinity<\/code> und kein Datum.<\/p>\n
Der letzte Punkt geh\u00f6rt klar ausgesprochen, denn er erzeugt eine wiederkehrende \u00dcberraschung: Ein Datum hat keine eigene Darstellung. Was ankommt, ist eine Zeichenkette oder eine Zahl, die beide Seiten als Datum zu lesen vereinbart haben – und jede Uneinigkeit \u00fcber das Format ist f\u00fcr den Parser unsichtbar.<\/p>\n
Die f\u00fcnf Fehler mit Ausnahme<\/h2>\n
Das sind die lauten, und jeder davon erzeugt dieselbe wenig hilfreiche Meldung \u00fcber eine unerwartete Marke.<\/p>\n\n\n\n\n\n\n\n\n\n
Fehler<\/th>\nWie er aussieht<\/th>\n<\/tr>\n<\/thead>\n
Einfache Anf\u00fchrungszeichen<\/td>\n‘order_id’ statt “order_id”<\/td>\n<\/tr>\n
Schl\u00fcssel ohne Anf\u00fchrungszeichen<\/td>\ntotal: 129.90 statt “total”: 129.90<\/td>\n<\/tr>\n
Komma vor der Klammer<\/td>\nEin Komma vor } oder ]<\/td>\n<\/tr>\n
Kommentar<\/td>\nAlles nach \/\/ oder zwischen \/* und *\/<\/td>\n<\/tr>\n
Roher Umbruch in einer Zeichenkette<\/td>\nEin Zeilenumbruch zwischen Anf\u00fchrungszeichen; n\u00f6tig ist \\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Ein sechster geh\u00f6rt in dieselbe Gruppe und ist \u00fcberhaupt nicht sichtbar: eine Byte-Reihenfolge-Marke am Dateianfang. Das sind drei unsichtbare Bytes vor der \u00f6ffnenden Klammer, und der Parser meldet eine unerwartete Marke an Position 0 – was so aussieht, als sei die Klammer das Problem. Eine Datei, die fehlerfrei aussieht und an Position 0 scheitert, hat eine, und ein Editor mit der Einstellung \u201eohne Marke speichern” entfernt sie.<\/p>\n
Die zwei, die nichts melden<\/h2>\n
Nach diesen lohnt sich absichtlich zu suchen, denn nichts sonst wird darauf zeigen.<\/p>\n
Der erste ist ein doppelter Schl\u00fcssel. Die Spezifikation erlaubt ihn, und das \u00fcbliche Verhalten ist, dass der letzte gewinnt – ein Dokument mit zweimal \"total\"<\/code> liest sich also sauber und tr\u00e4gt den zweiten Wert. Liegen die beiden in einer langen Nutzlast weit auseinander, entsteht eine Zahl, die weder falsch aussieht noch richtig ist.<\/p>\n
{ \"total\": 129.90, \"currency\": \"EUR\", \"total\": 139.90 }\n\nJSON.parse(...).total   \u2192   139.90<\/code><\/pre>\n
Der zweite ist eine grosse ganze Zahl. Zahlen sind in JavaScript Gleitkommazahlen, und ganze Zahlen bleiben nur bis 2^53 \u2212 1 genau. Eine Bestellnummer, eine Kennung aus einer Datenbank, eine Meta-CAPI-Kennung – sie alle \u00fcberschreiten das regelm\u00e4ssig, und der Parser rundet sie wortlos.<\/p>\n
JSON.parse('{\"id\": 9007199254740993}').id   \u2192   9007199254740992\n\nJSON.parse('{\"id\": \"9007199254740993\"}').id \u2192   \"9007199254740993\"<\/code><\/pre>\n
Die Regel daraus ist kurz: Eine Kennung ist eine Zeichenkette, immer, auch wenn sie nur aus Ziffern besteht. Gerechnet wird damit ohnehin nie, und eine Zeichenkette \u00fcbersteht jeden Parser unver\u00e4ndert.<\/p>\n
Die gemeldete Position lesen<\/h2>\n
Die Position in der Fehlermeldung ist ein Zeichenversatz im ganzen Dokument, und in einer minifizierten Nutzlast ist das eine Zahl ohne Bedeutung.<\/p>\n
Der erste Schritt ist deshalb immer, das Dokument zu formatieren, und nicht, den Fehler zu suchen. Eine formatierte Nutzlast legt die Position auf eine Zeile, und die Zeile dar\u00fcber ist meist die eigentliche Fundstelle – ein fehlendes Komma f\u00e4llt bei der n\u00e4chsten Marke auf, nicht dort, wo es fehlt.<\/p>\n
try {\n  JSON.parse(text);\n} catch (e) {\n  const stelle = Number((e.message.match(\/position (\\d+)\/) || [])[1]);\n  if (!Number.isNaN(stelle)) {\n    console.log(text.slice(Math.max(0, stelle - 60), stelle + 60));\n    console.log(\" \".repeat(Math.min(60, stelle)) + \"^\");\n  }\n}<\/code><\/pre>\n
Sechzig Zeichen zu jeder Seite gen\u00fcgen in fast jedem Fall, um das Problem zu sehen, und das Dach nimmt das Abz\u00e4hlen ab. Das lohnt sich als Textbaustein aufzuheben, denn die Alternative besteht darin, einen Formatierer zu \u00f6ffnen, einzuf\u00fcgen, zu scrollen und die Position zu verlieren.<\/p>\n
Auf der Kommandozeile pr\u00fcfen<\/h2>\n
Kommt die Nutzlast aus einer Datei oder einer Anfrage, beantwortet ein einziger Befehl die Frage.<\/p>\n
# gueltig? formatierte Ausgabe, oder ein Fehler mit Zeilennummer\njq . nutzlast.json\n\n# nur die Antwort, ohne den Inhalt\njq -e . nutzlast.json >\/dev\/null && echo \"gueltig\" || echo \"ungueltig\"\n\n# doppelte Schluessel finden - jq behaelt den letzten, das hier zaehlt sie\njq -r 'paths(scalars) | join(\".\")' nutzlast.json | sort | uniq -d\n\n# grosse Zahlen, die an Genauigkeit verlieren werden\ngrep -oE '\"[a-z_]+\": *[0-9]{16,}' nutzlast.json<\/code><\/pre>\n
Der dritte Befehl lohnt sich auf jeder noch nie gepr\u00fcften Nutzlast. Er listet die Pfade, die mehr als einmal vorkommen, und das ist der einzige maschinelle Weg zum stillen Fall – bei einer erzeugten Nutzlast findet er \u00fcberraschend oft etwas, denn eine Vorlage, die ein Feld in zwei Zweigen anh\u00e4ngt, erzeugt genau das.<\/p>\n
Wo es am meisten z\u00e4hlt<\/h2>\n
Drei Orte machen aus einem kleinen JSON-Fehler etwas, das sp\u00e4ter schwer zu bemerken ist.<\/p>\n
Ein JSON-LD-Block in der Seite ist der erste. Ein Syntaxfehler bedeutet, dass Suchmaschinen \u00fcberhaupt keine strukturierten Daten lesen, und die Seite funktioniert weiterhin einwandfrei – nichts am Auftritt deutet also auf ein Problem hin, und der Verlust zeigt sich Wochen sp\u00e4ter als ausbleibende erweiterte Treffer. Ein Pr\u00fcfer auf der ausgelieferten Seite, nicht auf der Vorlage, ist die Kontrolle, die das f\u00e4ngt.<\/p>\n
Eine Conversions-API-Nutzlast ist der zweite. Die empfangende Plattform antwortet mit einem Fehler, aber dieser Fehler steht in einer Server-zu-Server-Antwort, die niemand beobachtet, und ein gescheitertes Ereignis erscheint schlicht nicht. Hier richtet der doppelte Schl\u00fcssel den gr\u00f6ssten Schaden an: Eine Nutzlast mit dem Ereigniswert zweimal sendet den falschen, und Sender wie Empf\u00e4nger halten die Anfrage f\u00fcr gelungen.<\/p>\n
Die Konfiguration einer Tag-Manager-Vorlage ist der dritte. Das JSON darin wird einmal beim Laden der Vorlage gelesen, und ein fehlerhaftes Feld kann die Vorlage installiert, aber wirkungslos zur\u00fccklassen. Anders ist dieser Fall darin, dass er beim Import scheitert statt zur Laufzeit – eine bessere Stelle zum Scheitern, und nur dann, wenn jemand die Meldung liest.<\/p>\n
Allen dreien gemeinsam: Gepr\u00fcft wird dort, wo die Nutzlast entsteht, nicht dort, wo sie verbraucht wird. Ein Bauschritt, der den Parser \u00fcber jede erzeugte Datei laufen l\u00e4sst, kostet nichts und f\u00e4ngt alle f\u00fcnf lauten Fehler ab, bevor sie die Maschine verlassen.<\/p>\n
\n
Quellen<\/h2>\n