JSON е съкращение от Java скрипт Обозначение на обект, което е формат, който използва за четене от човека текст прехвърляне на данни състояща се от двойки атрибут-стойност. Това е най-разпространеният формат за данни, използван за асинхронна комуникация между браузъра и сървъра, който до голяма степен замества XML (използвайки AJAX).
JSON е независим от езика формат за данни, който е получен от JavaScript. От 2017 г. много езици за програмиране са използвали код, за да генерират и анализират данни в него. Имената на JSON файлове използват разширение .json.
Оригиналният JSON формат е разработен от Дъглас Крокфорд в началото на нулата, а впоследствие два конкуриращи се стандарта (RFC 7159 и ECMA-404) са го дефинирали през 2013 година. Стандартът ECMA описва само валиден синтаксис, докато RFC покрива някои от основите на сигурността и оперативната съвместимост.
В допълнение, има RFC 7493 стандарт, който определя ограничен профил, известен като I-JSON (съкращение от „Internet JSON“). Той се стреми да преодолее някои от проблемите на взаимодействието. Всеки такъв документ е валиден документ JSON.
Необходимостта от създаване на този формат се е повишила от необходимостта от реален протокол за комуникация между сървъра и браузъра, реализиран в реално време без използването на плъгини (като Flash или Java аплети).
Както вече беше отбелязано, Дъглас Крокфорд, като създател на StateSoftware, първо идентифицира и популяризира JSON формата. Впоследствие съоснователите се съгласиха да създадат система, използваща стандартни възможности на браузъра, и осигуриха абстрактен слой за разработчиците да създават приложения с непрекъсната дуплексна връзка с уеб сървъра. В същото време стана възможно да се отворят две HTTP връзки и да се обработят до стандартното време на браузъра, ако не се обменят данни. Съоснователите проведоха дискусия на кръглата маса и гласуваха за назоваване на JSML или JSON формата на данните, както и определят вида на лиценза, под който ще се предлага новата разработка. В момента форматът е с отворен код.
Уебсайтът на JSON.org стартира през 2002 година. През декември 2005 г. Yahoo! започна да предлага някои от своите уеб услуги в този формат. Google започна да използва JSON емисии за своя уеб протокол GData едва през декември 2006 г.
първоначално файлов формат JSON е предназначен за подмножество на скриптовия език на JavaScript (по-специално стандарт ECMA-262 3rd Edition-December) и често се използва с него. Въпреки това, той е формат, независим от езика на данните. Кодът за анализ и генериране на JSON данни е достъпен на много езици за програмиране. Уебсайтът на JSON изброява всички библиотеки.
Въпреки че онлайн JSON форматът първоначално е рекламиран и се счита за строго подмножество на JavaScript и ECMAScript, той периодично позволява някои символи, които не са избягали в низове, които не са валидни в низове на JavaScript и ECMAScript.
Самият JSON стана международен стандарт ECMA през 2013 г. като стандарт ECMA-404, който беше използван в RFC 7158 същата година като отправна точка. През 2014 г. RFC 7159 се превърна в основна препратка към използването на JSON в Интернет (например MIME приложение / json).
Основните типове данни в JSON са:
Ограничените пространства са позволени и могат да бъдат поставени около или между синтактичните елементи (стойности и пунктуация, но не и в рамките на низовата стойност). За тази цел се разглеждат само четири специални знака. пространства: пространство, хоризонтален раздел, емисия и наклонена черта. По-специално, етикетът за байтовия ред не трябва да се генерира от съответната реализация (въпреки че може да бъде приет при парсинг на JSON). Заявка в JSON формат не съдържа синтаксис за коментари.
Ранните версии (например тези, описани в RFC 4627) изискват валиден документ да се състои само от обект или тип масив, който може да съдържа други типове в тях. Такъв формат JSON, пример за който може да бъде намерен на остарели уеб страници, понастоящем не се използва.
Въпреки че Douglas Crockford първоначално твърди, че JSON е строго подмножество на JavaScript, неговата спецификация ви позволява да създавате документи, които не са четими в JavaScript. По-специално, JSON позволява стойностите на Uicode U + 2028 LINE SEPARATOR и U + 2029 PARAGRAPH SEPARATOR да изглеждат неекранирани в цитираните линии, но JavaScript не го прави. Това се дължи на факта, че JSON забранява само "контролни знаци". За максимална съвместимост, тези знаци трябва да се избягват с обратна наклонена черта. Тази тънкост е важна при създаването на JSONP.
JSON документите могат да бъдат кодирани в UTF-8, UTF-16 или UTF-32, кодирането по подразбиране е UTF-8. Тези стандарти поддържат пълния набор от Unicode символи, включително знаците извън основната многоезикова равнина (от U + 10,000 до U + 10FFFF). Обаче, ако те се избягват, тези знаци трябва да бъдат написани с помощта на UTF-16 сурогатни двойки - подробности липсват от някои анализатори в JSON формат. Как да отворите и как ще бъде прочетен такъв файл?
Числата в този формат са агностични по отношение на тяхното представяне в езиците за програмиране. Няма разлика между цялото число и стойността с плаваща запетая: някои изпълнения могат да разглеждат 42, 42.0 и 4.2E + 1 като един и същ номер, а други не. Освен това няма изисквания за въпроси като препълване, недостатъчност, загуба на точност или закръгляване. В допълнение, JSON форматът не казва нищо за обработка на подписани нули, независимо дали 0.0 е различен от -0.0. Повечето приложения, използващи стандарт с плаваща запетая IEEE 754, включително JavaScript, запазват подписани нули, но не всички JSON реализации могат да направят това.
Тъй като JSON форматът е получен от JavaScript и неговият синтаксис е (най-вече) подмножество на езика, можете да използвате функцията JavaScripteval за анализиране на JSON данни. Поради проблем със синтактичния анализ на Unicode терминатори, споменати в предишния раздел, функцията eval трябва да извърши тяхната подмяна.
Това не е безопасно, ако низът не е правилно валидиран. Вместо това, за да четете и пишете JSON, използвайте библиотеката на JSON парсер или поддръжката на JavaScript.
Правилно изпълненият анализатор приема само валиден JSON формат, чието описание присъства в системата, предотвратявайки неволното изпълнение на потенциално злонамерен код.
От 2010 г. уеб браузъри като Firefox и Internet Explorer са активирали поддръжката за анализ и качват в JSON формат.
Синтаксисът на JavaScript определя няколко родни типа данни, които не са включени в стандарта JSON: Map, Set, Date, Error, Regular Expression, Function и някои други. Тези типове данни на JavaScript трябва да бъдат представени от някои други формати, като и двете програми се съгласяват с типа на преобразуването между типовете. Днес има някои дефакто стандарти, например конвертиране на дата в низ, но никой от тях не е общоприет. Други езици може да имат различен набор от местни типове, които трябва да бъдат внимателно сериализирани, за да се справят с този тип преобразуване.
Използва се схема за определяне на JSON структура на данни за валидиране, документиране и управление на взаимодействието. Той предоставя вид договор за данните, изисквани от приложението, и начин да го промените.
Схемата се основава на концепции от XML Schema (XSD), но е местна. Както и при XSD, същите инструменти за сериализация / десериализация се използват както за схемата, така и за данните.
Схемата е онлайн проект, който в момента е във версия 5 (издаден на 13 октомври 2016 г.). Има няколко валидатора за различни езици за програмиране, всеки от които има различно ниво на съответствие. Няма стандартно разширение на файла, но някои експерти предлагат одобряването на .schema.json.
Официалният MIME тип за JSON текст е "application / json". Въпреки факта, че повечето съвременни реализации са приели официалния MIME тип, много приложения продължават да предоставят наследство за други MIME типове. Много доставчици на услуги, браузъри, сървъри, уеб приложения, библиотеки, рамки и приложни програмни интерфейси използват, очакват или разпознават MIME тип, съдържанието на което изглежда като "text / json" или "text / javascript". Забележителни примери са Google Search API, Yahoo !, Flickr, Facebook API, DojoToolkit 0.4 и така нататък.
JSON-RPC е протокол за отдалечена процедура (RPC), изграден на JSON, създаден като заместител на XML-RPC или SOAP. Това е прост протокол, който дефинира само няколко вида данни и команди. Тя позволява на системата да изпраща известия (информация на сървър, който не изисква отговор) и няколко повиквания към сървъра, на които може да се отговори нередовно.
Асинхронният JavaScript и JSON (или AJAJ) принадлежат към една и съща методология за динамични уеб страници като Ajax, но вместо XML, JSON данните са основен формат. AJAJ е технология за уеб разработка, която позволява на уеб страница да изисква нови данни, след като бъде заредена в браузър. Той обикновено ги показва от сървъра в отговор на потребителски действия на тази страница. Например, това, което потребителят въвежда в полето за търсене, клиентският код след това изпраща на сървъра, който незабавно отговаря с падащ списък на съответните елементи от базата данни.
Текстът JSON се дефинира като обект за сериализация на данни. Въпреки това, неговият дизайн, като свободно дефинирано подмножество на скриптовия език на JavaScript, създава няколко проблеми със сигурността. Те се фокусират върху използването на интерпретатора на Javascript за динамично изпълнение на JSON текста като вграден JavaScript. Това излага програмата на погрешни или злонамерени скриптове. Това е сериозен проблем при работа с данни, извлечени от интернет.
Този прост и популярен, но рисков метод използва съвместимост с функцията JavaScripteval.
Някои разработчици погрешно смятат, че текстът JSON също е синтактично подобен на JavaScript кода, въпреки че това е само частично вярно. Затова се смята, че един прост начин за JavaScript програма за анализ на данните в този формат е да се използва вградената функция JavaScripteval, която е проектирана да оценява изразите "Javascript". Вместо да използва специфичен анализатор, самият интерпретатор се използва за изпълнение на JSON данни, създавайки естествени JavaScript обекти. Този метод обаче е рискован, ако е вероятно JSON данните да съдържат произволен Javascript код, който след това да бъде изпълнен по същия начин. Освен ако не се предприемат мерки за валидиране на данните, методът eval е уязвим за уязвимости в сигурността, когато данните и цялата среда на JavaScript не са под контрола на един надежден източник.
Например, ако данните не са проверени, те са обект на атаки с код на JavaScript. Такива нарушения могат също да създадат риск от кражба на данни, измама за удостоверяване и други потенциални злоупотреби с данни и ресурси.
Така новата JSON.parse функция е разработена като по-безопасна алтернатива на eval. Той е специално проектиран да обработва данни точно JSON, а не JavaScript. Първоначално той беше предвиден за включване в четвъртото издание на стандарта ECMAScript, но това не се случи. Първо беше добавен към версия 5 и сега се поддържа от основните браузъри.