JSON валидатор

Како да го користите JSON валидаторот

Залепете го вашиот JSON во полето за внесување и кликнете Валидирај JSON. Алатката го анализира вашиот влез и укажува дали е валиден или ја идентификува конкретната синтаксна грешка. Кога JSON-от е валиден, гледате форматирана верзија во излезното поле придружена со статистики вклучувајќи го вкупниот број клучеви, длабочината на вгнездување, типот на коренскиот податок и големината на документот. Користете го копчето Копирај за да го копирате форматираниот излез во вашиот клипборд.

Оваа алатка е суштинска за програмери кои работат со одговори од API, конфигурациски датотеки, извози од бази на податоци и кои било други JSON податоци. Наместо да чекате грешка при извршување да ви каже дека има проблем со вашиот JSON, прво валидирајте го и поправете ги проблемите пред да предизвикаат дефекти понатаму.

Разбирање на правилата за JSON синтакса

JSON има измамливо проста синтакса која ги фаќа дури и искусните програмери. Спецификацијата бара сите низи да користат двојни наводници, а не единечни наводници. Клучевите на објектите мора да бидат низи во двојни наводници. Низите и објектите не смеат да имаат завршни запирки. Нема никакви коментари. Броевите не смеат да имаат водечки нули (освен за самата вредност 0 или децимали како 0.5). Булевите вредности мора да бидат со мали букви true или false, а нултата вредност мора да биде со мали букви null.

Многу програмери се навикнати да пишуваат JavaScript објектни литерали, кои се попермисивни од JSON. JavaScript дозволува единечни наводници, неспакувани клучеви, завршни запирки и коментари. Кога програмерите копираат JavaScript објекти и се обидуваат да ги користат како JSON, валидаторот веднаш ги открива овие разлики. Разбирањето на разликата меѓу JavaScript објекти и JSON е фундаментално за работа со веб API.

Вообичаени JSON грешки и како да ги поправите

Завршните запирки се најчестата JSON грешка. Во JavaScript, {"a": 1, "b": 2,} е валидно, но во JSON завршната запирка по последната вредност е синтаксна грешка. Поправката е едноставно да ја отстраните запирката по последниот елемент. Единечните наводници се втората најчеста грешка. JSON бара "hello", а не 'hello'. Неспакуваните клучеви како {name: "John"} мора да се променат во {"name": "John"}. Погрешно спарените загради е потешко да се забележат во големи документи, што го прави валидаторот незаменлив.

Анализа на бројот на клучеви и длабочината на вгнездување

Бројот на клучеви ви го кажува вкупниот број својства во сите објекти на вашиот JSON документ, вклучувајќи ги оние во вгнездените објекти. Длабочината на вгнездување мери колку нивоа длабоко е најдлабоката вредност. Овие метрики се корисни за разбирање на сложеноста на структурата на податоци. Длабоко вгнезден JSON со повеќе од пет или шест нивоа може да биде тежок за ракување и може да укажува дека моделот на податоци треба да се реструктуира. Многу API наметнуваат ограничувања на длабочината за спречување злоупотреба, и познавањето на вашата длабочина ви помага да останете во тие ограничувања.

Објаснети правила за JSON синтакса

JSON, акроним за JavaScript Object Notation, дефинира две главни структури: објекти и низи. Објект е неподредена колекција на парови клуч-вредност оградена со големи загради {}. Секој клуч мора да биде низа оградена со двојни наводници, проследена со двоточка и вредност. Повеќе парови клуч-вредност се одвоени со запирки. Низа е подредена листа на вредности оградена со квадратни загради [], при што секоја вредност е одвоена со запирка. И двете структури можат да бидат вгнездени до произволна длабочина, овозможувајќи ви да претставувате сложени хиерархиски податоци.

Дозволените типови вредности во JSON се строго ограничени. Вредност може да биде низа (во двојни наводници), број (цел или децимален, без водечки нули), булева вредност (true или false, секогаш со мали букви), null (исто така со мали букви), објект или низа. Нема други типови вредности. Значајно е дека JSON не поддржува undefined, датуми, регуларни изрази, функции или кој било од другите сложени типови на програмските јазици. Датумите обично се претставуваат како ISO 8601 низи како "2026-04-07T12:00:00Z", а апликацијата е одговорна за нивното анализирање.

Проблемот со завршните запирки заслужува посебно внимание бидејќи претставува непропорционален број неуспешни валидации. Во многу програмски јазици, запирка по последниот елемент на листа или последното својство на објект е совршено прифатлива и дури поттикната за почисти разлики во контролата на верзии. JSON, сепак, строго ги забранува завршните запирки. Влезот {"a": 1, "b": 2,} е невалиден JSON и ќе биде отфрлен од секој усогласен анализатор. Слично, [1, 2, 3,] не поминува на валидација. Ова е една од најчестите грешки кои ги прават програмерите при рачно уредување JSON датотеки и е главната причина за користење валидатор пред поднесување податоци до API или вчитување конфигурациска датотека.

Детални вообичаени грешки при JSON валидација

Покрај завршните запирки, постојат неколку други чести извори на грешки при JSON валидација кои е корисно да се разберат подетално. Секоја произлегува од несовпаѓање меѓу тоа што програмерите очекуваат од JSON и тоа што спецификацијата реално дозволува.

Пропуштени или неправилни наводници на клучеви

Во JavaScript, можете да напишете {name: "Alice"} без да го ставите клучот во наводници. Во JSON, секој клуч мора да биде низа во двојни наводници: {"name": "Alice"}. Ова не подлежи на преговарање. Некои толерантни анализатори прифаќаат неспакувани клучеви, но тие ја прекршуваат спецификацијата, и вашите податоци ќе се расипат кога ќе бидат обработени од строг анализатор. Секогаш ставајте го секој клуч во двојни наводници во вашите JSON документи.

Единечни наспроти двојни наводници

JSON бара двојни наводници за сите низи, и клучеви и вредности. Употребата на единечни наводници како {'name': 'Alice'} е невалидна. Ова е честа грешка кај Python програмерите, бидејќи Python ги користи единечните наводници наизменично со двојните наводници и неговата str() претстава на речници користи единечни наводници. Ако конвертирате Python структури на податоци во JSON, секогаш користете ја функцијата json.dumps() наместо str(), бидејќи json.dumps() правилно произведува излез со двојни наводници.

Коментари во JSON

JSON спецификацијата не дозволува никаков вид коментари, ниту еднолиниски (//) ниту повеќелиниски (/* */). Ова е намерна дизајнерска одлука на Даглас Крокфорд, кој го создал JSON. Тој аргументирал дека коментарите биле користени за содржење на директиви за анализа, што предизвикувало проблеми со интероперабилноста. Ако ви се потребни коментари во конфигурациски датотеки, размислете за JSONC (JSON со коментари, користен од VS Code), JSON5, YAML или TOML. Кога ќе наидете на JSON со коментари, отстранете ги пред анализата или користете препроцесор толерантен на коментари.

Неизбегнати специјални знаци во низи

JSON низите мора да ги избегнуваат одредени знаци со обратна коса црта. Контролните знаци (знаци со кодни точки помали од U+0020) мора да бидат избегнати. Најчестите се преломи на линии (\n), табулатори (\t), враќања на почеток (\r) и самите обратни коси црти (\\). Двојните наводници внатре во низа мора да бидат избегнати како \". Заборавањето да се избегне обратна коса црта во Windows патека на датотека како "C:\new\folder" произведува невалидна JSON низа бидејќи \n се интерпретира како прелом на линија и \f како прелом на страница. Правилната претстава е "C:\\new\\folder". Овој проблем често се појавува при вградување на патеки на датотеки, regex обрасци или HTML делови во JSON.

Замки при форматирање на броеви

JSON броевите следат специфични правила кои се разликуваат од некои програмски јазици. Водечки нули не се дозволени: 007 е невалидно и мора да се напише 7. Позитивни знаци не се дозволени: +5 е невалидно, додека -5 е валидно. Хексадецимална нотација како 0xFF не е поддржана. Infinity и NaN не се валидни JSON вредности. Ако треба да претставите специјални нумерички вредности, мора да ги енкодирате како низи или да користите сентинел вредност и да ја обработите конверзијата во кодот на вашата апликација.

JSON во API и конфигурациски датотеки

JSON стана доминантен формат за размена на податоци за веб API. Кога испраќате POST барање до REST API со заглавие Content-Type: application/json, серверот очекува строго валидно JSON тело. Ако телото на вашето барање содржи синтаксна грешка, серверот генерално ќе врати одговор 400 Bad Request, често со криптичен порака за грешка при анализа која може да биде тешка за дебагирање. Валидирањето на вашата JSON содржина пред испраќање ја елиминира целата оваа категорија грешки и значително го забрзува развојот на API.

Во контекст на REST API, JSON валидацијата е важна на двата краја на комуникацијата. На клиентска страна, мора да се уверите дека податоците што ги испраќате се добро формирани. На серверска страна, мора да го валидирате влезниот JSON пред да го обработите за да спречите малформирани податоци да ја оштетат состојбата на вашата апликација. Многу веб рамки автоматски вршат основна JSON анализа, но структурната валидација — уверувањето дека правилните полиња постојат со правилните типови — бара дополнителни алатки за валидација на шеми како JSON Schema.

Конфигурациските датотеки се уште еден голем случај на употреба за JSON. Менаџерите на пакети како npm користат package.json, TypeScript користи tsconfig.json, ESLint користи .eslintrc.json и многу облак сервиси како AWS CloudFormation и Azure Resource Manager користат JSON шаблони. Синтаксна грешка во која било од овие датотеки може да спречи вашиот цевковод за градење да се изврши, вашата апликација да стартува или вашата инфраструктура да се распореди. Ризиците се особено високи во CI/CD околини каде малформирана JSON конфигурација може да го блокира целиот процес на издавање.

Системите за бази на податоци исто така во голема мера се потпираат на JSON. PostgreSQL има вродени типови колони json и jsonb, MongoDB ги складира документите во BSON (бинарна форма на JSON), и многу други бази на податоци поддржуваат JSON барања. При увоз на податоци во овие системи, невалиден JSON предизвикува неуспешни вметнувања кои можат да ги прекинат серискиот обработувачки задачи. Валидирањето на вашите JSON податоци пред вчитување во база на податоци заштедува време и спречува парцијални увози кои ги оставаат вашите податоци во неконзистентна состојба.

Покрај основната синтаксна валидација, многу организации усвојуваат JSON Schema за дефинирање на очекуваната структура на нивните JSON документи. JSON Schema ви овозможува да специфицирате кои полиња се задолжителни, какви типови податоци треба да има секое поле, прифатливи опсези на вредности, обрасци на низи и уште многу. Иако оваа алатка се фокусира на синтаксна валидација, уверувањето дека вашиот JSON е синтаксно правилен е првиот суштински чекор пред да може да се изврши каква било валидација на ниво на шема. Документ кој не се анализира правилно не може да се валидира спрема шема.

Често поставувани прашања

Што е JSON валидација?

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

Зошто треба да го валидирам JSON?

Валидирањето на JSON пред негова употреба ги спречува грешките при извршување. Единствена пропуштена запирка или погрешно спарена заграда може да предизвика неуспех на API барањата и вчитувањето на конфигурацијата.

Кои се вообичаените JSON грешки?

Завршни запирки, единечни наводници наместо двојни наводници, неспакувани клучеви, пропуштени запирки меѓу елементи, коментари и погрешно спарени загради се најчестите JSON грешки.

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

Не. JSON спецификацијата не дозволува коментари. Користете JSONC или YAML ако ви се потребни коментари во вашите конфигурациски датотеки.

Која е максималната големина на JSON документ?

Спецификацијата нема ограничување. Практично, анализаторите на прелистувачите обработуваат стотици мегабајти. Оваа онлајн алатка работи добро со документи од неколку мегабајти.