Перевірка та форматування JSON

Перевірка та форматування JSON, це безплатний інструмент, який перевіряє синтаксичну коректність JSON і форматує валідні дані, щоб їхню структуру було легше читати.

Що робить перевірка та форматування JSON?

Перевірка визначає, чи відповідають введені дані граматиці JSON, а форматування впорядковує валідні об'єкти й масиви, додаючи однакові відступи та пробіли. Це корисно під час налагодження відповідей API, перевірки конфігурації перед розгортанням або читання компактних даних від стороннього постачальника.

Синтаксис JSON суворіший за синтаксис літерала об'єкта JavaScript. Назви властивостей потрібно брати в подвійні лапки, для рядків не можна використовувати одинарні лапки, а після останнього елемента об'єкта чи масиву не може бути коми. Коментарі, undefined, NaN та Infinity також не входять до специфікації JSON.

Цей інструмент використовує серверну функцію PHP json_decode. Введені дані передаються на сервер через 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 не дозволяє ставити кому після останньої властивості. Видали цю кому, щоб об'єкт став валідним.

Якщо вхідні дані мають коректне кодування UTF-8, рядки JSON можуть безпосередньо містити літери з діакритичними знаками й символи нелатинських абеток. Наприклад, {"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, порівняй не лише видимі значення, а й типи даних, переконайся, що керівні послідовності не змінилися, і запусти застосунок, який споживатиме ці дані, або перевірку за його схемою. Під час діагностики даних від стороннього постачальника зберігай незмінену копію початкової відповіді, щоб форматування не приховало джерело помилки.