CDRN

JSON szintaxis validálása

  • Irányítópult
  • Dokumentáció
  • API
ellenőrzi egy JSON karakterlánc szintaxisát és megjelöli az első hiba sorát és oszlopát

Mire jó a JSON validátor?

A JSON validátor szerényebb, de pontosabb szerepet tölt be, mint a formázó: nem ír át semmit. Beolvas egy karakterláncot, és egy bináris kérdésre válaszol: megfelel-e ez a szöveg a RFC 8259 szerinti JSON-nak? Ha igen, az eszköz befejezi a munkát. Ha nem, pontosan megjelöli a sort, az oszlopot és egy részletet a JSON-ból a probléma körül, hogy segítse a fejlesztőt az azonnali javításban.

A gyakorlatban ezt az eszközt használjuk, amint egy elemző valahol titokzatos hibaüzenetet küld, például: SyntaxError: Unexpected token } in JSON at position 217. Ahelyett, hogy egy szerkesztőben kézzel számolnánk a karaktereket, beillesztjük a teljes láncot, leolvassuk a pozíciót, és látjuk a hibás részletet.

Validálás, formázás: két külön művelet

Gyakran összekeverik a kettőt. A JSON formázónk érvényes JSON-t fogad, és olvasható behúzással írja újra. A validátor ezzel szemben beéri egy szintaktikai ítélettel. Nem végez szemantikai ellenőrzést: nem tudja, hogy egy email mező értéke hasonlít-e egy e-mailre, sem azt, hogy a szerkezet megfelel-e egy JSON Schema-nak. Ehhez dedikált eszközöket használunk (ajv Node-ban, justinrainbow/json-schema en PHP).

A klasszikus hibakeresési folyamat: először validálás (az eszköz jelzi a szintaktikai hibát), majd formázás (a már érvényes payload olvashatóvá válik), végül összehasonlítás egy másik referencia payload-dal a JSON összehasonlítónkon keresztül.

A leggyakoribb JSON hibák

  • Záró vessző (trailing comma): {"a": 1, "b": 2,}. A JavaScript, az ECMAScript és a JSON5 tolerálja; a tiszta JSON elutasítja. Ez az első számú hiba, amikor kódszerkesztőből másolunk-beillesztünk.
  • Aposztrófok a dupla idézőjelek helyett: a {'a': 1} érvénytelen. A JSON csak a dupla idézőjelet fogadja el, mind a kulcsoknál, mind a szöveges értékeknél.
  • Idézőjel nélküli kulcsok: {a: 1}, érvényes JavaScript szintaxis, de érvénytelen JSON.
  • Nem escaped vezérlőkarakterek egy karakterláncban: nyers soremelés, tabulátor. A JSON megköveteli a \n, \t, \r használatát.
  • Megjegyzések: // megjegyzés vagy /* */. A JSONC (VS Code konfiguráció) vagy a JSON5 elfogadja, a tiszta JSON elutasítja.
  • Helytelen kódolás: UTF-8 BOM a fájl elején, rosszul konvertált latin-1 tartalom. A validátor ezekben az esetekben gyakran általános üzenetet küld vissza.
  • Be nem fejezett szerkezet: egy { vagy [ lezárás nélkül, ami gyakori, ha a másolás-beillesztéskor csonkoljuk a payload-ot.

Hogyan lokalizálja a validátor a hibát

Az eszköz a PHP json_decode() függvényét használja a JSON_THROW_ON_ERROR jelzővel. A PHP egy üzenetet küld vissza, amely tartalmazza a pozíciót bájtokban (position 217), amelyet mi sor/oszlop párossá alakítunk az eltolás előtti soremelések megszámlálásával. Ezután egy körülbelül 80 karakteres részletet vágunk ki a pozíció körül, hogy kontextust adjunk. Ez általában elegendő a hiba felismeréséhez: egy rossz helyen lévő idézőjel, egy felesleges vessző, egy hiányzó zárójel.

Figyelem: a PHP által jelentett pozíció nem mindig pontosan a hibás karakter. Gyakran a hiba után van, azon a ponton, ahol az elemző feladta. Ha a részlet ezt mutatja: "name": "Alice", }, a valódi hiba a vessző, nem a kapcsos zárójel.

Tipikus felhasználási esetek

  • Sérült konfiguráció: composer.json, package.json, tsconfig.json, amelyek megakadályozzák a build elindulását. Beillesztjük, látjuk a sort, javítjuk.
  • Csonkolt API válasz: egy proxy levágta a payload-ot. A szerkezet nincs befejezve, a validátor ezt jelzi.
  • Webhook payload: egy harmadik féltől származó szolgáltatás rosszul formázott JSON-t küld. A validátor lehetővé teszi a probléma észlelését a küldő oldalon anélkül, hogy belemerülnénk az alkalmazás kódjába.
  • Konkatenációval felépített JSON: elkerülendő, de gyakori gyakorlat, különösen bash-ben vagy SQL-ben. A validátor felfedi a nem escaped dupla idézőjeleket.

Az eszköz korlátai

A validátor nem végez sémával szembeni ellenőrzést. Nem mondja meg, ha hiányzik az email mező, ha az érték nem egész szám, vagy ha a várt tömb nem megfelelő hosszúságú. Ezekhez a strukturális ellenőrzésekhez JSON Schema-t használunk. A validátor nem is javítja a JSON-t: nem próbál meg hiányzó kapcsos zárójelet hozzáadni vagy felesleges vesszőt eltávolítani. Ez választás kérdése: az automatikus javítás túl gyakran fedi el a valódi hibákat.

Gyakori kérdések

Mi a különbség a linterhez képest?

A linter tovább megy: ellenőrzi a stílusszabályokat is (ábécérend, elnevezési konvenciók), észleli a kettőzött értékeket, javításokat javasol. A validátor megmarad a szintaktikai megfelelőségnél.

A JSON-om érvényes, de az alkalmazásom elutasítja?

Ellenőrizze a kódolást (UTF-8 BOM nélkül), a szerveroldali méretkorlátot, a várt típusokat. Egy szintaktikailag helyes JSON még mindig nem biztos, hogy megfelel az alkalmazás sémájának.

Megőrzi a validátor a JSON-omat?

Nem. A feldolgozás szinkron módon történik a szerveroldalon, tartós tárolás nélkül. Nagyon érzékeny adatok esetén továbbra is célszerűbb a helyi validálás a jq vagy egy PHP szkript segítségével.

Kérés példa

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

Bemeneti séma

Mező Típus Kötelező Alapértelmezett
input text ✓ –

Végpontok

  • GET https://cdrn.fr/api/v1/tools - listázza az összes elérhető eszközt
  • GET https://cdrn.fr/api/v1/tools/json-validator - lekéri ezen eszköz sémáját
  • POST https://cdrn.fr/api/v1/tools/json-validator/execute - végrehajtja ezen eszközt JSON payloaddal