CDRN

JSON-syntaxis valideren

  • Dashboard
  • Documentatie
  • API
controleert de syntaxis van een JSON-string en meldt de regel en kolom van elke fout

Waarvoor dient een JSON-validator?

Een JSON-validator heeft een bescheidener, maar preciezere rol dan een opmaker: hij herschrijft niets. Hij neemt een tekenreeks en antwoordt op een binaire vraag: is deze tekst conforme JSON volgens de RFC 8259? Zo ja, geeft de tool de controle terug. Zo niet, geeft hij precies de regel, de kolom en een uittreksel van de JSON rond het probleem aan, om de ontwikkelaar te helpen onmiddellijk te corrigeren.

In de praktijk is het de tool die men gebruikt zodra een parser ergens een cryptische foutmelding teruggeeft zoals SyntaxError: Unexpected token } in JSON at position 217. In plaats van met de hand de tekens te tellen in een editor, plakt men de volledige tekenreeks, leest men de positie en ziet men het foute uittreksel.

Validatie, opmaak: twee verschillende bewerkingen

Beide worden vaak verward. Onze JSON-opmaker neemt geldige JSON en herschrijft deze met een leesbare inspringing. De validator beperkt zich tot een syntactisch oordeel. Hij voert geen semantische validatie uit: hij weet niet of de waarde van een veld email op een email lijkt, noch of de structuur overeenkomt met een JSON Schema. Daarvoor gebruikt men speciale tools (ajv in Node, justinrainbow/json-schema in PHP).

De klassieke debug-sequentie is: eerst valideren (de tool wijst op de syntaxisfout), vervolgens opmaken (de nu geldige payload wordt leesbaar), tenslotte vergelijken met een andere referentie-payload via onze JSON-comparator.

De meest voorkomende JSON-fouten

  • Trailing comma: {"a": 1, "b": 2,}. Getolereerd door JavaScript, ECMAScript en JSON5; geweigerd door zuiver JSON. Het is de fout nr.1 wanneer men kopieert-plakt vanuit een code-editor.
  • Apostrofen in plaats van dubbele aanhalingstekens: {'a': 1} is ongeldig. JSON accepteert alleen dubbele aanhalingstekens, rond zowel sleutels als tekenreekswaarden.
  • Niet-gequote sleutels: {a: 1}, geldige JavaScript-syntaxis maar ongeldige JSON.
  • Niet-geëscaped besturingstekens in een tekenreeks: een ruw regeleinde, een tab. JSON eist \n, \t, \r.
  • Commentaren: // commentaar of /* */. Geaccepteerd in JSONC (VS Code config) of JSON5, geweigerd in zuiver JSON.
  • Verkeerde codering: een UTF-8 BOM aan het begin van het bestand, inhoud in slecht geconverteerd latin-1. De validator geeft vaak een generieke melding terug voor deze gevallen.
  • Niet-beëindigde structuur: een { of [ zonder sluiting, vaak wanneer men een payload afkapt bij het kopiëren-plakken.

Hoe de validator de fout lokaliseert

De tool gebruikt json_decode() van PHP met de vlag JSON_THROW_ON_ERROR. PHP geeft een melding terug die een positie in bytes bevat (position 217), die we converteren naar een regel/kolom-paar door de regeleinden voor de offset te tellen. Een uittreksel van ongeveer 80 tekens wordt vervolgens uitgesneden rond de positie om context te geven. Dat is over het algemeen voldoende om de fout op te sporen: een verkeerd geplaatste aanhalingsteken, een overbodige komma, een ontbrekende haakje.

Let op: de door PHP gerapporteerde positie is niet altijd precies het foute teken. Het is vaak na de fout, op het moment dat de parser opgaf. Als het uittreksel toont "name": "Alice", }, is de echte fout de komma, niet de accolade.

Typische gebruiksgevallen

  • Corrupte configuratie: composer.json, package.json, tsconfig.json die een build verhinderen te starten. Men plakt, men ziet de regel, men corrigeert.
  • Afgekapt API-antwoord: een proxy heeft de payload afgekapt. De structuur is niet beëindigd, de validator signaleert het.
  • Webhook-payload: een service van derden stuurt slecht gevormde JSON. De validator maakt het mogelijk om het probleem aan de zenderkant vast te stellen zonder in de applicatiecode te duiken.
  • Door concatenatie geconstrueerde JSON: te vermijden praktijk maar gangbaar, vooral in bash of SQL. De validator onthult niet-geëscapeerde dubbele aanhalingstekens.

Limieten van de tool

De validator voert geen validatie tegen een schema uit. Hij zegt niet dat het veld email ontbreekt, dat de waarde geen geheel getal is of dat de verwachte array niet de juiste lengte heeft. Voor deze structurele controles gebruikt men JSON Schema. De validator corrigeert ook niet de JSON: hij probeert geen ontbrekende accolade toe te voegen, noch een overbodige komma te verwijderen. Het is een keuze: automatische correctie verbergt te vaak echte fouten.

Veelgestelde vragen

Wat is het verschil met een linter?

Een linter gaat verder: hij controleert ook stijlregels (alfabetisch, benoemingsconventies), detecteert dubbele waarden, stelt verbeteringen voor. De validator blijft bij syntactische conformiteit.

Mijn JSON is geldig, maar mijn applicatie weigert hem?

Controleer de codering (UTF-8 zonder BOM), de groottelimiet aan de serverkant, de verwachte typen. Een JSON die syntactisch correct is, kan toch niet overeenkomen met het applicatieschema.

Bewaart de validator mijn JSON?

Nee. De verwerking is synchroon aan de serverkant, zonder persistentie. Voor zeer gevoelige gegevens verkiest u toch een lokale validatie via jq of een PHP-script.

Voorbeeldverzoek

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

Invoerschema

Veld Type Vereist Standaard
input text ✓ –

Endpoints

  • GET https://cdrn.fr/api/v1/tools - toont alle beschikbare tools
  • GET https://cdrn.fr/api/v1/tools/json-validator - geeft het schema van deze tool terug
  • POST https://cdrn.fr/api/v1/tools/json-validator/execute - voert deze tool uit met een JSON-payload