Tagapagpatunay at pampaganda ng JSON

Ang Tagapagpatunay at pampaganda ng JSON ay isang libreng tool na sumusuri kung wasto ang syntax ng JSON at nag-aayos ng wastong content para mas madaling basahin ang istruktura nito.

Ano ang ginagawa ng pagpapatunay at pagpapaganda ng JSON?

Tinitiyak ng pagpapatunay na sumusunod sa grammar ng JSON ang input, samantalang ipinapakita ng pagpapaganda ang mga wastong object at array na may pare-parehong espasyo at indentation. Kapaki-pakinabang ito sa pag-debug ng mga tugon mula sa API, pagsuri ng configuration bago i-deploy, o pagbasa ng compact na data mula sa third party.

Mas mahigpit ang syntax ng JSON kaysa sa JavaScript object literal. Kailangang gumamit ng dobleng panipi ang mga pangalan ng property, hindi maaaring gumamit ng isahang panipi ang mga string, at hindi maaaring magkaroon ng trailing comma ang mga object o array. Hindi rin saklaw ng detalye ng JSON ang mga comment, undefined, NaN, at Infinity.

Ginagamit ng tool na ito ang function na json_decode ng PHP sa server. Ipinapadala sa server sa pamamagitan ng HTTPS ang iyong input at hindi ito iniimbak. Gayunman, lumalabas ang data sa iyong device, kaya alisin o itago ang mga password, access token, at personal na data kung hindi pinapayagan ng mga patakaran ng iyong organisasyon na ipadala ang mga ito sa external na server.

Paano magpatunay at magpaganda ng JSON?

I-paste ang content sa field na JSON, pagkatapos ay patakbuhin ang tool. Para maging kapaki-pakinabang ang resulta, maglagay ng isang kumpletong JSON value sa halip na bahagi lamang ng object na kinopya mula sa isang log line.

1. Kopyahin ang raw na tugon, configuration block, o iba pang JSON value nang hindi kasama ang mga console label sa paligid nito.
2. I-paste ito sa field na JSON, at panatilihin ang mga panipi at escape character.
3. Patakbuhin ang pagpapatunay at suriin ang naka-format na resulta o ang iniulat na error.
4. Kung hindi pumasa sa pagpapatunay, ayusin ang unang nakikitang problema sa syntax at patakbuhin itong muli. Ang isang nawawalang panipi ay maaaring maging dahilan para maling bigyang-kahulugan ang ilang kasunod na character.

Walang epekto sa data ang apat na pinapayagang whitespace character sa pagitan ng mga JSON token: space (U+0020), tab (U+0009), line feed (U+000A), at carriage return (U+000D). Maaari silang idagdag o alisin nang hindi binabago ang data. Ang whitespace sa loob ng string na may panipi ay bahagi ng data at hindi dapat baguhin. Pinananatili rin ang bantas sa loob ng mga string, bagaman kailangan ng naaangkop na escape sequence para sa mga panipi, backslash, at control character.

Paano basahin ang resulta ng pagpapatunay?

Kapag matagumpay ang resulta, ibig sabihin ay na-decode ng PHP ang input bilang JSON. Kapag hindi ito pumasa, hindi nabigyang-kahulugan ng parser ang input bilang isang kumpleto at wastong JSON value. Pagkatapos, ipinapakita ng pagpapaganda ang nesting at mga hangganan ng mga wastong object at array.

Kabilang sa mga karaniwang sanhi ng error ang:

• trailing comma bago ang } o ];
• pangalan ng property na walang panipi, gaya ng {name: "Ada"};
• mga string na gumagamit ng isahang panipi;
• nawawalang comma sa pagitan ng mga property o elemento ng array;
• dobleng panipi o backslash sa loob ng string na walang escape;
• hindi kumpletong object, array, o string;
• hindi wastong UTF-8 input o raw na control character sa loob ng string;
• integer na may hindi kinakailangang zero sa unahan, gaya ng 01 o -01, o value na hindi kabilang sa JSON, gaya ng NaN.

Hindi wastong JSON ang field na walang laman. Sa kabilang banda, wastong JSON ang isang nakahiwalay na value gaya ng 42, true, null, o "hello", kahit hindi ito object o array. Maaari ring lumampas sa nesting limit ng decoder ang content na napakalalim ng nesting.

Hindi tinitiyak ng pagpapatunay ng syntax na tumutugma ang data sa kontrata ng API. Maaaring wastong JSON ang isang dokumento pero naglalaman ito ng string kung saan numero ang inaasahan ng application, walang kinakailangang property, o gumagamit ng hindi katanggap-tanggap na format ng petsa. Para sa mga kinakailangang iyon, gumamit ng JSON Schema o mga pagsusuri sa antas ng application.

Mga halimbawa ng JSON

Wastong compact na input:

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

Inilalagay ng pinagangandang resulta ang mga property at elemento ng array sa magkakahiwalay at naka-indent na antas. Nananatiling string, Boolean, at array ang mga value. Presentasyon lamang ang binabago ng pag-format, hindi ang mga uri ng pinagbabatayang data.

Hindi wastong input na may trailing comma:

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

Hindi ito pumapasa dahil hindi pinapayagan sa JSON ang comma pagkatapos ng huling property. Alisin ang comma na iyon para maging wasto ang object.

Maaaring direktang lumitaw sa mga JSON string ang mga letrang may accent at tekstong hindi Latin kapag wastong UTF-8 ang input. Halimbawa, wasto ang {"city":"Zürich","greeting":"こんにちは"}. Isa ring wastong representasyon ng ilang Unicode character ang JSON escape notation na gaya ng \u00fc, bagaman kailangan ng mga surrogate pair para sa mga character na wala sa Basic Multilingual Plane.

Kailan hindi kailangang pagandahin ang JSON?

Hindi kailangang pagandahin ang JSON kung machine lamang ang babasa rito at walang planong suriin ito ng tao o i-review sa version control. Pinapataas ng karagdagang indentation at mga line break ang dami ng byte na inililipat, kaya karaniwang ipinapadala sa compact na anyo ang mga production response.

Kaunti rin ang pakinabang sa pag-minify ng JSON na compact na. Hindi mapaiikli ng paulit-ulit na pag-minify ang mga nakapirming pangalan ng property o mga string value, at mababago ang data kung babaguhin ang mga value na iyon. Para sa JavaScript na ide-deploy, sa halip na JSON data, mas angkop gamitin ang Minifier ng JS.

Pinakakapaki-pakinabang ang pagpapaganda kapag sinusuri ang mga istruktura o value ng JSON sa pag-debug, code review, at mga pagsusuri bago mag-deploy. Mas madaling makita rito ang hindi nagtutugmang nesting, mas mabilis suriin ang malalaking array, at mas malinis ang mga diff kapag naka-commit sa Git ang configuration. Hindi nito awtomatikong inaayos ang malformed na JSON o tinutukoy kung ano talaga ang ibig sabihin ng isang hindi malinaw na fragment.

Mga madalas itanong

Pwede bang may comment sa JSON?

Hindi. Walang syntax para sa comment ang karaniwang JSON, kaya hindi papasa sa pagpapatunay ang // comment at /* comment */. Kung kailangan ng mga comment sa configuration file, gumamit ng format na sumusuporta sa mga ito, o alisin muna ang mga comment bago iproseso ang content gamit ang mahigpit na JSON parser.

Hindi ba tatanggapin ang mga nauulit na pangalan ng property?

Hindi palagi. Ayon sa detalye ng JSON, dapat natatangi ang mga pangalan ng member sa loob ng isang object, ngunit hindi laging itinuturing ng mga parser na syntax error ang mga nauulit na pangalan. Karaniwang pinananatili ng PHP decoding ang mas huling value, kaya tukuyin ang mga duplicate bago ang pagpapatunay kung mahalagang mapanatili ang bawat paglitaw.

Pwede bang magpatunay ng JSON Lines file?

Hindi bilang iisang JSON document. Ang JSON Lines, na tinatawag ding NDJSON, ay may hiwalay na JSON value sa bawat linya, samantalang isang top-level value ang inaasahan ng karaniwang JSON parser. Patunayan nang hiwalay ang bawat linya o gawing iisang JSON array ang mga record.

Mahalaga ba ang pagkakasunod-sunod ng mga property sa object?

Hindi dapat umasa ang mga application sa pagkakasunod-sunod ng mga property ng JSON object. May tiyak na ayos ang mga array, ngunit ang mga object ay kumakatawan sa mga koleksiyon ng pinangalanang member, at maaaring ilabas ng ibang parser o serialiser ang mga ito sa ibang pagkakasunod-sunod. Kung may kahulugan ang sequence, ilagay ang mga value sa isang array.

Bakit hindi pumapasa ang JSON file kahit mukhang tama naman?

Maaaring hindi pumasa ang tekstong mukhang tama dahil sa hindi nakikitang byte-order mark, malformed na UTF-8, o control character na walang escape. Maaari ring makapagdagdag ng mga prefix ang pagkopya mula sa terminal, gaya ng mga status label o timestamp. Suriin ang mga raw byte o buksan ang file sa editor na kayang magpakita ng encoding at mga control character.

Mga huling pagsusuri

Bago i-deploy ang inayos na JSON, ihambing ang mga uri ng data pati ang mga nakikitang value, tiyaking hindi nabago ang mga escape sequence, at patakbuhin ang application na gagamit nito o ang schema validation nito. Kapag sinusuri ang data mula sa third party, magtago ng hindi binagong kopya ng orihinal na tugon para hindi maitago ng pag-format ang pinagmulan ng problema.