JSON валидатор и форматиране

JSON валидатор и форматиране е безплатен инструмент, който проверява дали JSON е синтактично валиден и форматира валидното съдържание така, че структурата му да се чете по-лесно.

Какво правят валидирането и форматирането на JSON?

Валидирането проверява дали въведеното съдържание спазва граматиката на JSON, а форматирането представя валидните обекти и масиви с последователни интервали и отстъпи. Това е полезно при отстраняване на грешки в отговори от API, проверка на конфигурация преди внедряване или преглед на компактни данни от трета страна.

Синтаксисът на JSON е по-строг от този на обектните литерали в JavaScript. Имената на свойствата трябва да са в двойни кавички, за низовете не могат да се използват единични кавички, а след последния елемент в обект или масив не се допуска запетая. Коментарите, undefined, NaN и Infinity също не са част от спецификацията на JSON.

Инструментът използва функцията json_decode на PHP на сървъра. Въведеното съдържание се изпраща до сървъра през HTTPS и не се съхранява. То все пак напуска устройството ти, затова премахни паролите, токените за достъп и личните данни, ако правилата на организацията ти не позволяват изпращането им до външен сървър.

Как да валидирам и форматирам JSON?

Постави съдържанието в полето JSON и стартирай инструмента. За да получиш полезен резултат, въведи една пълна JSON стойност, а не част от обект, копирана от ред в регистрационен файл.

1. Копирай необработения отговор, конфигурационния блок или друга JSON стойност без придружаващите я етикети от конзолата.
2. Постави съдържанието в полето JSON, като запазиш кавичките и екраниращите знаци.
3. Стартирай валидирането и прегледай форматирания резултат или съобщението за грешка.
4. Ако валидирането е неуспешно, поправи първата видима синтактична грешка и опитай отново. Една липсваща кавичка може да доведе до неправилно тълкуване на няколко последващи знака.

Четирите разрешени знака за празно пространство между JSON елементите, интервал (U+0020), табулация (U+0009), нов ред (U+000A) и връщане на каретката (U+000D), не влияят на данните. Те могат да се добавят или премахват, без съдържанието да се променя. Празното пространство в низ, ограден с кавички, е част от данните и трябва да остане непроменено. Пунктуацията в низовете също се запазва, но кавичките, обратните наклонени черти и контролните знаци трябва да бъдат представени с подходяща екранираща последователност.

Как да разчета резултата от валидирането?

Успешният резултат означава, че PHP е успял да декодира въведеното съдържание като JSON. Неуспешният резултат показва, че анализаторът не го разпознава като една пълна и валидна JSON стойност. След това форматирането показва ясно нивата на влагане и границите на валидните обекти и масиви.

Сред честите причини за неуспешно валидиране са:

• запетая непосредствено преди } или ];
• име на свойство без кавички, например {name: "Ada"};
• низове в единични кавички;
• липсваща запетая между свойства или елементи на масив;
• неекранирана двойна кавичка или обратна наклонена черта в низ;
• незавършен обект, масив или низ;
• невалидни входни данни в UTF-8 или необработен контролен знак в низ;
• цяла числова част с ненужни водещи нули, например 01 или -01, или стойности извън JSON, като NaN.

Празното поле не е валиден JSON. За разлика от него, самостоятелна стойност като 42, true, null или "hello" е валиден JSON, макар да не е обект или масив. Съдържание с твърде много нива на влагане също може да надхвърли ограничението на декодера.

Синтактичното валидиране не потвърждава, че данните отговарят на договора на дадено API. Един документ може да е валиден JSON, но да съдържа низ там, където приложението очаква число, да няма задължително свойство или да използва неприемлив формат за дата. За такива изисквания използвай JSON Schema или проверки на ниво приложение.

Практически примери с JSON

Валидни компактни входни данни:

{"name":"Ada","active":true,"roles":["admin","editor"]}

Форматираният резултат показва свойствата и елементите на масива на отделни нива с отстъпи. Стойностите остават съответно низ, булева стойност и масив. Форматирането променя начина на представяне, а не основните типове данни.

Невалидни входни данни със запетая след последното свойство:

{"name":"Ada","active":true,}

Валидирането е неуспешно, защото JSON не допуска запетая след последното свойство. Премахни я, за да стане обектът валиден.

Текст с ударения и знаци извън латиницата може да присъства директно в JSON низовете, когато входните данни са валидни в UTF-8. Например {"city":"Zürich","greeting":"こんにちは"} е валиден JSON. Екраниращ запис в JSON като \u00fc е друг валиден начин за представяне на определени Unicode знаци, но за знаците извън основната многоезична равнина са необходими сурогатни двойки.

Кога няма смисъл да форматирам JSON?

Форматирането не е необходимо, когато JSON ще се чете само от машина и не се предвижда преглед от човек или чрез система за контрол на версиите. Допълнителните отстъпи и нови редове увеличават броя на прехвърлените байтове, затова отговорите в работна среда обикновено се изпращат в компактен вид.

Няма особен смисъл и да минимизираш JSON, който вече е компактен. Повторното минимизиране не може да съкрати фиксираните имена на свойства или стойностите на низовете, а промяната им би променила данните. За JavaScript, предназначен за внедряване, а не за JSON данни, по-подходящият инструмент е JS минимизатор.

Форматирането е най-полезно при преглед на JSON структури или стойности по време на отстраняване на грешки, преглед на код и проверки преди внедряване. То разкрива несъответствията във влагането, улеснява преглеждането на големи масиви и създава по-ясни сравнения, когато конфигурацията се записва в Git. Инструментът не поправя автоматично невалиден JSON и не определя какво е трябвало да означава даден двусмислен фрагмент.

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

Може ли JSON да съдържа коментари?

Не. Стандартният JSON няма синтаксис за коментари, затова // comment и /* comment */ водят до неуспешно валидиране. Ако са ти нужни коментари в конфигурационен файл, използвай формат, който ги поддържа, или ги премахни, преди да подадеш съдържанието към строг JSON анализатор.

Отхвърлят ли се повтарящите се имена на свойства?

Не непременно. Според спецификацията на JSON имената на членовете в един обект трябва да са уникални, но анализаторите невинаги третират повторенията като синтактична грешка. При декодиране PHP обикновено запазва по-късната стойност, затова провери за повторения преди валидирането, ако е важно да съхраниш всяко срещане.

Мога ли да валидирам файл JSON Lines?

Не и като един JSON документ. JSON Lines, наричан още NDJSON, съдържа отделна JSON стойност на всеки ред, докато стандартният JSON анализатор очаква една стойност от най-високо ниво. Валидирай всеки ред поотделно или преобразувай записите в един JSON масив.

Има ли значение редът на свойствата в JSON обект?

Приложенията не трябва да разчитат на реда на свойствата в JSON обектите. Масивите са подредени, но обектите представляват колекции от именувани членове, а друг анализатор или сериализатор може да ги изведе в различен ред. Ако последователността носи значение, постави стойностите в масив.

Защо JSON файлът е невалиден, въпреки че изглежда правилно?

Невидим маркер за реда на байтовете, неправилно кодиран UTF-8 или неекраниран контролен знак може да направи привидно правилния текст невалиден. При копиране от терминал могат да се добавят и префикси, например етикети за състояние или времеви печати. Прегледай необработените байтове или отвори файла в редактор, който може да показва кодирането и контролните знаци.

Последни проверки

Преди да внедриш поправения JSON, сравни типовете данни, а не само видимите стойности, провери дали екраниращите последователности не са се променили и стартирай приложението, което използва данните, или неговото валидиране по схема. Когато диагностицираш данни от трета страна, запази непроменено копие на първоначалния отговор, за да не може форматирането да прикрие източника на грешката.