Die Syntax eines JSON validieren
- Dashboard
- Dokumentation
- API
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:
// commentaireoder/* */. 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 aufGET https://cdrn.fr/api/v1/tools/json-validator- liefert das Schema dieses ToolsPOST https://cdrn.fr/api/v1/tools/json-validator/execute- führt dieses Tool mit einem JSON-Payload aus