CDRN

Valider syntaksen af en JSON

  • Dashboard
  • Dokumentation
  • API
verificerer syntaksen af en JSON-streng og angiver linjen og kolonnen for den første fejl

Hvad bruges en JSON-validator til?

En JSON-validator har en mere beskeden, men mere præcis, rolle end en formaterer: den omskriver ikke intet. Det tager en streng og besvarer et binært spørgsmål: er denne tekst i overensstemmelse med JSON? RFC 8259? Hvis ja, returnerer værktøjet kontrol. Hvis ikke, angiver det nøjagtigt rækken, kolonnen og et uddrag af JSON omkring problemet, for at hjælpe udvikleren med at løse det med det samme.

I praksis er det det værktøj, vi bruger, så snart en parser et sted returnerer en fejlmeddelelse kryptisk som SyntaxError: Uventet token } i JSON i position 217. Snarere end tæl tegnene i hånden i en editor, indsæt hele strengen, læs stillingen og se det fornærmende uddrag.

Validering, formatering: to adskilte operationer

Vi forveksler ofte de to. Vores JSON formatter tager gyldig JSON og omskriver den med læsbar indrykning. Validatoren er tilfreds med en syntaktisk dom. Han udfører ikke semantisk validering: den ved ikke, om værdien af et e-mail felt ligner en e-mail, ej heller hvis strukturen matcher et JSON-skema. Til dette bruger vi dedikerede værktøjer (ajv i Node, justinrainbow/json-schema i PHP).

Den klassiske sekvens i debugging er: valider først (værktøjet angiver syntaksfejlen), format så (den nu gyldige nyttelast bliver læsbar), sammenlign til sidst med en endnu en referencenyttelast via vores JSON-komparator.

De mest almindelige JSON-fejl

  • Afsluttende komma: {"a": 1, "b": 2,}. Tolereres af JavaScript, ECMAScript og JSON5; afvist af ren JSON. Dette er den #1 fejl, når du kopierer og indsætter fra en kodeeditor.
  • Apostrof i stedet for dobbelte anførselstegn: {'a': 1} er ugyldig. JSON accepterer kun dobbelte anførselstegn, omkring nøgler og strengværdier.
  • Nøgler uden anførselstegn: {a: 1}, gyldig JavaScript-syntaks, men ugyldig JSON.
  • Uescaped kontroltegn i en streng: en rå ny linje, en tabulering. JSON kræver , , .
  • Kommentarer: // kommentar eller /* */. Accepteret i JSONC (config VS Code) eller JSON5, afvist i ren JSON.
  • Forkert kodning: en UTF-8-stykliste i starten af filen, forkert Latin-1-indhold konverteret. Validatoren returnerer ofte en generisk meddelelse for disse tilfælde.
  • Ufærdig struktur: en { eller [ uden lukning, almindelig når du afkorter en nyttelast, når du kopierer og indsætter.

Hvordan validatoren lokaliserer fejlen

Værktøjet bruger PHP's json_decode() med flaget JSON_THROW_ON_ERROR. PHP returnerer en besked, der indeholder en position i bytes (position 217), som vi konverterer til linje/søjlepar ved at tælle linjeskift før offset. Et uddrag på cirka 80 tegn er klip derefter rundt om positionen for at give kontekst. Dette er generelt tilstrækkeligt til at identificere fejlen: et malplaceret citat, et ekstra komma, en manglende parentes.

Advarsel: Den position, der rapporteres af PHP, er ikke altid præcis den fornærmende karakter. Det er hun ofte efter fejlen, når parseren har givet op. Hvis kodestykket viser "navn": "Alice", }, den faktiske fejl er kommaet, ikke klammeparentesen.

Typiske anvendelsestilfælde

  • Korrupt konfiguration: composer.json, package.json, tsconfig.json, der forhindrer en build i at starte. Vi indsætter, vi ser stregen, vi retter.
  • Trunkeret API-svar: En proxy reducerede nyttelasten. Strukturen er ikke færdig, validatoren rapporterer dette.
  • Webhook Payload: En tredjepartstjeneste sender forkert udformet JSON. Validatoren tillader at bemærke problemet på afsendersiden uden at dykke ned i applikationskoden.
  • JSON konstrueret ved sammenkædning: øv dig for at undgå, men almindelig, især i bash eller i SQL. Valideren afslører uundgåede dobbelte anførselstegn.

Værktøjsbegrænsninger

Validatoren validerer ikke mod et skema. Han siger ikke, at han mangler banen e-mail, at værdien ikke er et heltal, eller at det forventede array ikke har den korrekte længde. Til disse strukturelle kontroller bruger vi JSON Schema. Validatoren retter heller ikke JSON: den forsøger ikke at tilføje en manglende klammeparentes eller fjerne et ekstra komma. Det er et valg : automatisk korrektion skjuler for ofte reelle fejl.

Ofte stillede spørgsmål

Hvad er forskellen med en linter?

En linter går videre: den kontrollerer også stilregler (alfabetisk, navnekonventioner), registrerer duplikerede værdier, foreslår forbedringer. Validatoren forbliver på overholdelse syntaktisk.

Min JSON er gyldig, men min ansøgning afviser den?

Tjek kodningen (UTF-8 uden stykliste), størrelsesgrænse på serversiden, forventede typer. En JSON syntaktisk korrekt svarer muligvis stadig ikke til applikationsskemaet.

Beholder validatoren min JSON?

Nej. Behandlingen er synkron på serversiden, uden vedholdenhed. For meget følsomme data, foretrækker stadig lokal validering via jq eller et PHP-script.

Anmodningseksempel

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

Inputskema

Felt Type Påkrævet Standard
input text ✓ –

Endpoints

  • GET https://cdrn.fr/api/v1/tools - lister alle tilgængelige værktøjer
  • GET https://cdrn.fr/api/v1/tools/json-validator - henter skemaet for dette værktøj
  • POST https://cdrn.fr/api/v1/tools/json-validator/execute - udfører dette værktøj med et JSON-payload