Валидиране на синтаксиса на JSON

проверява синтаксиса на JSON низ и посочва реда и колоната на първата грешка

За какво се използва JSON валидатор?

JSON валидаторът има по-скромна, но по-прецизна роля от форматиращия: той не пренаписва нищо. Той взема низ и отговаря на двоичен въпрос: този текст отговаря ли на JSON? RFC 8259? Ако да, инструментът връща контрола. Ако не, той показва точно реда, колоната и извлечението от JSON около проблема, за да помогне на разработчика да го поправи незабавно.

На практика това е инструментът, който използваме веднага щом анализатор някъде върне съобщение за грешка криптичен като SyntaxError: Unexpected token } в JSON на позиция 217. По-скоро отколкото пребройте символите на ръка в редактор, поставете пълния низ, прочетете позицията и вижте обидния екстракт.

Валидиране, форматиране: две отделни операции

Често бъркаме двете. Нашият JSON форматиращ инструмент приема валиден JSON и пренаписва го с четлив отстъп. Валидаторът е доволен от синтактична присъда. той не извършва семантична проверка: не знае дали стойността на полето email изглежда като имейл, нито ако структурата съвпада с JSON схема. За това използваме специални инструменти (ajv в Node, justinrainbow/json-schema в PHP).

Класическата последователност при отстраняване на грешки е: първо валидиране (инструментът показва синтактичната грешка), формат след това (вече валидният полезен товар става четим), сравнете накрая с друг референтен полезен товар чрез нашия JSON компаратор.

Най-често срещаните JSON грешки

  • Запетая в края: {"a": 1, "b": 2,}. Толериран от JavaScript, ECMAScript и JSON5; отказано от чист JSON. Това е грешка №1 при копиране и поставяне от редактор на код.
  • Апострофи вместо двойни кавички: {'a': 1} е невалиден. JSON приема само двойни кавички, около ключове и низови стойности.
  • Ключове без кавички: {a: 1}, валиден синтаксис на JavaScript, но невалиден JSON.
  • Неекранирани контролни знаци в низ: необработен нов ред, a табулиране. JSON изисква , , .
  • Коментари: // коментар или /* */. Приема се в JSONC (config VS Code) или JSON5, отказан в чист JSON.
  • Неправилно кодиране: UTF-8 BOM в началото на файла, неправилно съдържание на Latin-1 преобразуван. Валидаторът често връща общо съобщение за тези случаи.
  • Незавършена структура: { или [ без затваряне, често когато съкращавате полезен товар при копиране и поставяне.

Как валидаторът локализира грешката

Инструментът използва json_decode() на PHP с флага JSON_THROW_ON_ERROR. PHP връща съобщение, което съдържа позиция в байтове (позиция 217), която преобразуваме в двойка ред/колона чрез преброяване на прекъсванията на реда преди отместването. Извадка от приблизително 80 знака е след това изрежете около позицията, за да дадете контекст. Това обикновено е достатъчно за идентифициране грешката: неправилно поставен цитат, допълнителна запетая, липсваща скоба.

Предупреждение: позицията, докладвана от PHP, не винаги е точно обидният характер. Тя е често след грешката, когато анализаторът се е отказал. Ако фрагментът показва "име": „Алиса“, }, действителната грешка е запетаята, а не скобата.

Типични случаи на употреба

  • Повредена конфигурация: composer.json, package.json, tsconfig.json, които предотвратяват стартирането на компилация. Поставяме, виждаме линията, коригираме.
  • Скъсен отговор на API: Прокси сървърът намалява полезния товар. Конструкцията не е завършена, валидаторът отчита това.
  • Полезен товар на Webhook: Услуга на трета страна изпраща неправилно образуван JSON. Валидаторът позволява за да забележите проблема от страната на подателя, без да се гмуркате в кода на приложението.
  • JSON, създаден чрез конкатенация: практика, която трябва да се избягва, но често срещана, особено в bash или в SQL. Валидаторът разкрива неекранирани двойни кавички.

Ограничения на инструмента

Валидаторът не валидира срещу схема. Той не казва, че теренът му липсва email, че стойността не е цяло число или че очакваният масив няма правилната дължина. За тези структурни проверки използваме JSON схема. Валидаторът също не коригира JSON: не се опитва да добави липсваща скоба или да премахне допълнителна запетая. Това е избор : автоматичната корекция твърде често крие истински грешки.

Често задавани въпроси

Каква е разликата с линтер?

Линтерът отива по-далеч: той също проверява стиловите правила (азбучен ред, конвенции за именуване), открива дублирани стойности, предлага подобрения. Валидаторът остава в съответствие синтактичен.

Моят JSON е валиден, но приложението ми го отхвърля?

Проверете кодирането (UTF-8 без BOM), ограничението за размер от страна на сървъра, очакваните типове. JSON синтактично правилно може все още да не съответства на схемата на приложението.

Валидаторът запазва ли моя JSON?

Не. Обработката е синхронна от страна на сървъра, без постоянство. За много чувствителни данни, все още предпочитат локално валидиране чрез jq или PHP скрипт.

Пример за заявка

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

Входна схема

Поле Тип Задължително По подразбиране
input text

Крайни точки

  • GET https://cdrn.fr/api/v1/tools - изброява всички достъпни инструменти
  • GET https://cdrn.fr/api/v1/tools/json-validator - извлича схемата на този инструмент
  • POST https://cdrn.fr/api/v1/tools/json-validator/execute - изпълнява този инструмент с JSON payload