JSON: прост формат, който изисква точна структура

Полезно е да знаеш

JSON се използва за обмен на данни между програми и за файлове с подредено съдържание. Форматът е текстов и е свързан исторически със синтаксиса на JavaScript, но е независим от конкретен език за програмиране. Официалното му представяне започва с две основни структури: колекция от двойки име и стойност и подреден списък от стойности. [1] Това е достатъчно за много практически задачи, когато участниците в обмена имат общо разбиране какво трябва да означават отделните полета.

Обектът използва имена за своите свойства, а масивът подрежда елементи в последователност. Стойностите могат да включват текст, числа, логически стойности, null и вложени структури. [1] Разликата е полезна при моделиране на каталог. Една статия може да бъде обект с именувани части, а списъкът със статии — масив. Самата форма обаче не определя автоматично кои полета са задължителни. Това е договор на приложението, който трябва да бъде описан и проверен отделно от базовата граматика на формата.

JSON има по-строги правила от обичайния JavaScript код. Имената на свойства са в двойни кавички, коментари не се допускат, а последната запетая след елемент е невалидна. Стойности като undefined, NaN и Infinity не принадлежат на стандартния JSON синтаксис. [2] Следователно фрагмент, който изглежда удобен в програмен файл, може да бъде отказан като файл за обмен. Визуалното сходство не е достатъчно основание двата вида текст да се обработват като напълно еднакви.

В JavaScript обектът JSON предоставя операции за преобразуване между текстово представяне и програмни стойности. MDN описва методите за прочитане и сериализиране като различни посоки на този процес. [2] Успешното прочитане доказва, че текстът съответства на синтаксиса; то не доказва, че стойността на всяко поле е подходяща за конкретната система. Например валидно число може да е неприемливо за количество, а валиден текст може да е твърде дълъг за заглавие в съществуващата база.

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

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