Die Syntax eines JSON validieren

überprüft die Syntax eines JSON-Strings und zeigt Zeile und Spalte des kleinsten Fehlers an

Wofür dient ein JSON-Validator?

Ein JSON-Validator hat eine bescheidenere, aber präzisere Rolle als ein Formatierer: Er schreibt nichts um. Er nimmt eine Zeichenkette und beantwortet eine binäre Frage: Ist dieser Text ein JSON, das der RFC 8259 entspricht? Wenn ja, gibt das Tool die Kontrolle zurück. Wenn nein, gibt es genau die Zeile, die Spalte und einen Auszug des JSON rund um das Problem an, um dem Entwickler zu helfen, sofort zu korrigieren.

In der Praxis ist es das Tool, das man verwendet, sobald ein Parser irgendwo eine kryptische Fehlermeldung zurückgibt wie SyntaxError: Unexpected token } in JSON at position 217. Statt die Zeichen in einem Editor von Hand zu zählen, fügt man die vollständige Zeichenkette ein, liest die Position und sieht den fehlerhaften Auszug.

Validierung, Formatierung: zwei unterschiedliche Operationen

Beides wird oft verwechselt. Unser JSON-Formatierer nimmt gültiges JSON entgegen und schreibt es mit lesbarer Einrückung um. Der Validator hingegen begnügt sich mit einem syntaktischen Urteil. Er führt keine semantische Validierung durch: Er weiß nicht, ob der Wert eines email-Feldes wie eine E-Mail aussieht oder ob die Struktur einem JSON-Schema entspricht. Dafür verwendet man dedizierte Tools (ajv in Node, justinrainbow/json-schema in PHP).

Die klassische Reihenfolge beim Debuggen ist: zuerst validieren (das Tool meldet den Syntaxfehler), dann formatieren (das nun gültige Payload wird lesbar), schließlich mit einem anderen Referenz-Payload vergleichen über unseren JSON-Vergleicher.

Die häufigsten JSON-Fehler

  • Nachgestelltes Komma (trailing comma): {"a": 1, "b": 2,}. Toleriert von JavaScript, ECMAScript und JSON5; abgelehnt von reinem JSON. Das ist Fehler Nr. 1 beim Kopieren-Einfügen aus einem Code-Editor.
  • Apostrophe statt doppelter Anführungszeichen: {'a': 1} ist ungültig. JSON akzeptiert nur doppelte Anführungszeichen, um Schlüssel wie um Zeichenkettenwerte.
  • Nicht quotierte Schlüssel: {a: 1}, gültige JavaScript-Syntax, aber ungültiges JSON.
  • Nicht escaped Steuerzeichen in einer Zeichenkette: ein roher Zeilenumbruch, eine Tabulation. JSON verlangt \n, \t, \r.
  • Kommentare: // commentaire oder /* */. Akzeptiert in JSONC (VS-Code-Konfiguration) oder JSON5, abgelehnt in reinem JSON.
  • Falsche Kodierung: ein UTF-8-BOM am Dateianfang, schlecht konvertierter latin-1-Inhalt. Der Validator gibt für diese Fälle oft eine generische Meldung zurück.
  • Nicht abgeschlossene Struktur: ein { oder [ ohne Schließung, häufig wenn man ein Payload beim Kopieren-Einfügen abschneidet.

Wie der Validator den Fehler lokalisiert

Das Tool verwendet json_decode() von PHP mit dem Flag JSON_THROW_ON_ERROR. PHP gibt eine Meldung zurück, die eine Position in Bytes enthält (position 217), die wir in ein Zeilen-/Spalten-Paar umwandeln, indem wir die Zeilenumbrüche vor dem Offset zählen. Ein Auszug von etwa 80 Zeichen wird dann um die Position herum extrahiert, um Kontext zu liefern. Das reicht in der Regel aus, um den Fehler zu erkennen: ein falsch platziertes Anführungszeichen, ein zu viel gesetztes Komma, eine fehlende Klammer.

Achtung: Die von PHP gemeldete Position ist nicht immer genau das fehlerhafte Zeichen. Sie liegt oft nach dem Fehler, zu dem Zeitpunkt, an dem der Parser aufgegeben hat. Wenn der Auszug "name": "Alice", } zeigt, ist der eigentliche Fehler das Komma, nicht die Klammer.

Typische Anwendungsfälle

  • Beschädigte Konfiguration: composer.json, package.json, tsconfig.json, die einen Build am Starten hindern. Man fügt ein, sieht die Zeile, korrigiert.
  • Abgeschnittene API-Antwort: Ein Proxy hat das Payload abgeschnitten. Die Struktur ist nicht abgeschlossen, der Validator meldet das.
  • Webhook-Payload: Ein Drittanbieter sendet schlecht geformtes JSON. Der Validator erlaubt es, das Problem auf der Senderseite festzustellen, ohne in den Anwendungscode einzutauchen.
  • Durch Verkettung erstelltes JSON: Eine zu vermeidende, aber häufige Praxis, vor allem in bash oder SQL. Der Validator deckt nicht escaped doppelte Anführungszeichen auf.

Grenzen des Tools

Der Validator führt keine Validierung gegen ein Schema durch. Er sagt nicht, dass das Feld email fehlt, dass der Wert keine ganze Zahl ist oder dass das erwartete Array nicht die richtige Länge hat. Für diese strukturellen Prüfungen verwendet man JSON Schema. Der Validator korrigiert das JSON auch nicht: Er versucht nicht, eine fehlende Klammer hinzuzufügen oder ein zu viel gesetztes Komma zu entfernen. Es ist eine bewusste Entscheidung: Automatische Korrektur verschleiert zu oft echte Fehler.

Häufig gestellte Fragen

Was ist der Unterschied zu einem Linter?

Ein Linter geht weiter: Er prüft auch Stilregeln (alphabetisch, Benennungskonventionen), erkennt doppelte Werte und schlägt Verbesserungen vor. Der Validator bleibt bei der syntaktischen Konformität.

Mein JSON ist gültig, aber meine Anwendung weist es zurück?

Prüfen Sie die Kodierung (UTF-8 ohne BOM), die serverseitige Größenbeschränkung, die erwarteten Typen. Ein syntaktisch korrektes JSON kann dennoch nicht dem Anwendungsschema entsprechen.

Speichert der Validator mein JSON?

Nein. Die Verarbeitung erfolgt synchron serverseitig, ohne Persistenz. Für sehr sensible Daten bevorzugen Sie dennoch eine lokale Validierung über jq oder ein PHP-Skript.

Beispielanfrage

curl -X POST https://cdrn.fr/api/v1/tools/json-validator/execute \
  -H "Content-Type: application/json" \
  -d '{"input":"..."}'

Eingabeschema

Feld Typ Erforderlich Standard
input text

Endpunkte

  • GET https://cdrn.fr/api/v1/tools - listet alle verfügbaren Tools auf
  • GET https://cdrn.fr/api/v1/tools/json-validator - liefert das Schema dieses Tools
  • POST https://cdrn.fr/api/v1/tools/json-validator/execute - führt dieses Tool mit einem JSON-Payload aus