Валидиране на синтаксиса на JSON
- Табло
- Документация
- API
За какво се използва 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