JSON

от Уикипедия, свободната енциклопедия
Направо към: навигация, търсене
JSON
JSON logo.gif
Лого на JSON езика.
Реализиране през 2001
Автор Дъглас Крокфорд
Софтуерен разработчик State Software
Повлиян от JavaScript
Уебсайт json.org

JSON, или JavaScript Object Notation, е текстово базиран отворен стандарт създаден за човешки четим обмен на данни. Произлиза от скриптовия език JavaScript, за да представя прости структури от данни и асоциативни масиви, наречени обекти. Въпреки своята връзка с JavaScript, това е езиково независима спецификация, с анализатори, които могат да преобразуват много други езици в JSON.

Форматът на JSON първоначално е бил създаден от Дъглас Крокфорд (Douglas Crockford) и е описан в RFC 4627. Официалният Интернет медия тип за JSON е application/json. Разширението на файловете написани на JSON е .json.

Форматът на JSON често е използван за сериализация и предаване на структурирани данни през Интернет връзка. Използва се главно, за да предаде данни между сървър и Интернет приложение, изпълнявайки функциите на алтернатива на XML.

История[редактиране | edit source]

Дъглас Крокфорд първи установява и популяризира JSON формата.[1]

JSON е бил използван в State Software Inc., компания съоткрита от Крокфорд, открита през Април 2001 и спонсорирана от Tesla Ventures. Когато компанията е била създадена през ранната 2001 от шест бивши служители на Communities.com, те се съгласили да създадат система, която да използва стандартните възможности на браузъра и да предоставят абстрактен слой на Интернет разработчиците, за да създават динамично защитени Интернет приложения, които да имат постоянна дуплекс връзка с Интернет сървъра,която да държи две HTTP връзки отворени. Тя ги презарежда преди стандартните за браузъра времена за прекъсване, ако няма повече данни, които да се обменят. Идеята на State Application Framework била разработена от Чип Морнингстар (Chip Morningstar) в State Software.[2][3]

Бил е използван в проект на Communities.com за Cartoon Network, които използват плъгини със собствен формат на съобщенията, за да манипулират DHTML елементите (тази система е собственост на 3DO). По време на ранното откриване на възможностите на езика Ajax,digiGroups, Noosh и други използвали рамки, за да предават информация във визуалното поле на браузърите на потребителите без да е нужно да се презарежда визуалният контекст на Интернет приложението. Всъщност Интернет приложенията използвали само стандартните HTTP, HTML и JavaScript способности на Netscape 4.0.5+ и IE 5+. След това Дъглас Крокфорд осъзнал, че JavaScript може да бъде използван като обектно-базиран формат за пращане на съобщения за такава система. Системата била продадена на Sun Microsystems, Amazon.com и EDS. Интернет сайтът на Json JSON.org бил стартиран през 2002. През Декември 2005 Yahoo! започнали да предлагат някои от своите Интернет услуги в JSON код.[4] Google започва да предлага JSON поддръжка за неговия GData интернет портокол през Декември 2006.[5]

Въпреки че JSON е оригинално базиран на не стриктно подмножество на скриптовия език JavaScript (по-специално, стандартът ECMA-262 3rd Edition—Декември 1999[6]) и често се изполва с този език, той е езиково независима спецификация за формат на данни. Код за анализиране и генериране на данни за JSON имат голямо разнообразие от програмни езици. Сайтът на JSON предоставя разбираемо подреждане на съществуващите JSON библиотеки, организирани от езика.

Типове данни, синтаксис и примери[редактиране | edit source]

Базовите типове данни на JSON са:

  • Number (число с плаваща запетая, double precision floating-point format в JavaScript)
  • String (Низ от символи с Unicode кодиране, затворени в двойни кавички, като „специалните“ символи се представят с т.н. escaping - символни последователности, започващи със символа "\")
  • Boolean (true или false)
  • Array (наредена поредица от стойности, разделени със запетая и затворени в квадратни скоби; стойностите не е задължително да бъдат от един и същ тип)
  • Object (неподредена колекция от двойки ключ:стойност, символът ":" разделя ключът и стойността, разделени със запетая и затворени в къдрави скоби; ключовете трябва да са string-ове и да са различни един от друг)
  • null (empty)

Всяко незначимо бяло пространство може да бъде добавено около „структорните символи“ (като скоби “{} []”, двоеточие ‘:’ и запетаи ‘,’).

Следващият пример показва представянето на обект, който описва човек в JSON. Обектът има string полета за първо и последно име, Number поле за години,Object, който представя адресът на човека и Array от телефонни номера представени като Object.

{
    "firstName": "John",
    "lastName": "Smith",
    "age": 25,
    "address": {
        "streetAddress": "21 2nd Street",
        "city": "New York",
        "state": "NY",
        "postalCode": 10021
    },
    "phoneNumbers": [
        {
            "type": "home",
            "number": "212 555-1234"
        },
        {
            "type": "fax",
            "number": "646 555-4567"
        }
    ]
}

Един потенциален недостатък на свободната форма на JSON идва от способността числата да се пишат като числови литерали или string-ове в кавички. Като пример: ZIP кодовете в североизточна Америка започват с нули ( например, 07728 за Freehold, New Jersey). Ако е написано с кавички от един програмист, но не и от друг, започващите нули може да се пропуснат при обмяна на данни между системите, когато се търси за тях в същата система или когато се принтират. Като добавка, пощенските кодове в САЩ използват числа, но в други страни използват и букви. Това е типът проблеми, с които JSON Schema-та (виж по-надолу) се цели да се справи.

Откакто JSON e почти подмножество на JavaScript е възможно, но не се препоръчва[7] да се преобразува текстът от JSON в обект като се използва функцията на JavaScript eval(). Като пример, ако горните данни от JSON кода се поберът в JavaScript string променлива contact, човек може да я използва, за да създаде обект както следва:

 var p = eval("(" + contact + ")");

Променливата contact трябва да бъде в скоби, за да се избегне двусмислието в JavaScript синтаксиса.[8]

Предпочитаният начин обаче е да се използва JSON анализатор. Освен ако клиентът не вярва на източникът или трябва да анализира и приеме текст, който не е JSON съвместим, човек трябва да избягва eval(). Коректно имплементран JSON анализатор приема само валиден JSON код, предотвратявайки от изпълнение злонамерени кодове по погрешка.

 var p = JSON.parse(contact);

Интернет браузърите като Firefox и Internet Explorer включват от 2010 специални функции, които да анализират JSON. Като поддръжката на браузъра е по-ефикасна и сигурна отколкото eval(). Поддръжката на JSON e включена в петото издание на ECMAScript стандартът.[9]

Библиотеките на jQuery обвиват обекта на JSON в функция конструктор и я изпълняват незабавно, ако не съществува JSON анализатор. Това избягва ползването на eval().

 var p = new Function('return ' + contact ';')();

Въпреки широкоразпространеното вярване, че JSON e подмножество на JavaScript, това не е вярно. По-точно, JSON позволява уникод прекъсващите реда символи U+2028 РЕД РАЗДЕЛИТЕЛ и U+2029 ПАРАГРАФ РАДЕЛИТЕЛ да изглеждат не избегнати поставени в кавички, докато Java Script не го прави. Това е в следствие на непозволяващите „контролни литерали“ в JSON. Тази финна разлика е важна, когато се генерира JASONP.

Неподдържани от JSON типове данни[редактиране | edit source]

JavaScript синтаксиса дефинира няколко присъщи за него типове данни, които не са включени в стандарта на JSON.  :[10] Date, Error, Regular Expression, and Function.Тези JavaScript типове данни трябва да бъдат представени като някой друг формат данни, като програмите от двата края на се разбират как става преобразуването на данните между типовете. От 2011 има някои стандарти като например за преобразуването на Date в String, но не са универсално разпознати.[11][12] Други езици може да имат различен брой присъщи типове, които можат внимателно да бъдат използвани, за да се разреши проблема с преобразуването между типовете данни.

JSON Schema[редактиране | edit source]

JSON Schema[13] определя JSON базиран формат, който да дефинира структурата на JSON данните за валидиране, документация и контрол на взаимодействието. JSON Schema-та осигурява споразумение между данните на JSON и приложението, което иска да ги ползва и модифицира. JSON Schema е базирана на концепцията на XML Schema, RelaxNG, и Kwalify, но е и JSON базирана, за да може данните на JSON във формата на JSON Schema да бъдат използвани, за да се валидират данни от JSON. Същите сериализационни/десриализационни инструменти могат да бъдат използвани за схемата и данните.

JSON Schema е Internet Draft, в момента на version 4.[14] Има няколко сериални валидатори, които са налични за различните програмни езици, всеки с различни нива на съответствие.[15]

Примерна JSON Schema:

{
    "name": "Product",
    "properties": {
        "id": {
            "type": "number",
            "description": "Product identifier",
            "required": true
        },
        "name": {
            "type": "string",
            "description": "Name of the product",
            "required": true
        },
        "price": {
            "type": "number",
            "minimum": 0,
            "required": true
        },
        "tags": {
            "type": "array",
            "items": {
                "type": "string"
            }
        },
        "stock": {
            "type": "object",
            "properties": {
                "warehouse": {
                    "type": "number"
                },
                "retail": {
                    "type": "number"
                }
            }
        }
    }
}

JSON Schema-та отгоре може да се използва, за да се валидира кодът по-долу:

{
    "id": 1,
    "name": "Foo",
    "price": 123,
    "tags": [ "Bar", "Eek" ],
    "stock": {
        "warehouse": 300,
        "retail": 20
    }
}

MIME type[редактиране | edit source]

Официалният MIME тип за JSON е "application/json".[16]

JSON-RPC[редактиране | edit source]

JSON-RPC е RPC протокол разработен на JSON, като заместител на XML-RPC или SOAP. Той е прост портокол, който дефинира само няколко типове данни и команди. JSON-RPC разрешава известия (информация изпратена до сървъра, която не изисква отговор) и множество от повиквания да бъдат изпратени до сървъра, които могат да бъдат отговорени без да бъдат поръчвани.

Пример за JSON-RPC 2.0 заявка и отговор използвайки позиционни параметри:

--> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}
<-- {"jsonrpc": "2.0", "result": 19, "id": 1}

Use in Ajax[редактиране | edit source]

JSON често се използва в програмирането на Ajax. Ajax е термин за способността на уебстраницата да изисква нови данни след като е заредила в уеб браузъра, обикновено в отговор на действията на потребителя на изобразената интернет страница. Като част от модела на Ajax, новата информация обикновено се включва в интерфейса на потребителя и се показва динамично още щом се получи от сървъра. Като пример за това на практика е, че ако някой потребител пише в search box, скриптове от браузъра на клиента изпращат какво е написал потребителят досега в сървъра, който отговаря с лист от възможни завършени търсения от неговата база данни. Те могат да бъдат изобразени като падащо меню под търсачката , за да може потребителят отгоре да спре да пише и да избере цялостен и често търсен стринг директно. Когато е бил описан през средата на 2000-дната година, Ajax най-често използвал XML като формат за обмен на данни, но много разработчици също използвали JSON, за да предават обновления между сървъра и клиента.[17]

Следващият JavaScript код е пример за client, който използва XMLHttpRequest, за да изискат информацията в JSON формат от сървъра. (Програмирането от страна на сървъра е пропуснато; то трябва да е настроено да отговаря на заявките на url с JSON-форматиран string.)

var my_JSON_object;
var http_request = new XMLHttpRequest();
http_request.open("GET", url, true);
http_request.onreadystatechange = function () {
    var done = 4, ok = 200;
    if (http_request.readyState == done && http_request.status == ok) {
        my_JSON_object = JSON.parse(http_request.responseText);
    }
};
http_request.send(null);

Проблеми със сигурността[редактиране | edit source]

Въпреки че JSON e предназначен като формат за сериализация на информация, неговият дизайн на не стрингово подмножество на скриптовия език JavaScript има и няколко проблеми със сигурността. Тези проблеми изхождат от използването на JavaScript като интерпретатор, който да изпълнява JSON текст динамично като JavaScript. Ето защо излагането на програма написана на JSON на скрипт, който е грешен или зловреден (скрит в кода) често представлява най-голям проблем за избягване, когато се справяте с получаване на информация от интернет. Въпреки, че не е единствения начин за обработване на JSON, това е лесена и популяна техника, произхождаща от съвместимостта на JSON с JavaScript-овата функция eval() и илюстрирана от следващит примери.

JavaScript eval()[редактиране | edit source]

Тъй като повечето от JSON форматираният текст е синтактично валиден JavaScript код, един лесен начин за JavaScript програмите да се преобразуват в JSON форматирана информация е да се използват вградената JavaScript eval() функция, която е предназначена да изпълнява JavaScript изрази. Вместо да се използва специален анализатор за JSON, интерпретаторът на JavaScript се използва, за да изпълнява информацията от кода на JSON и да произвежда нейтив JavaScript обекти. Въпреки това, има няколко Unicode символа, които са валидни JSON стрингове, но невалидни в JavaScript. Ето защо още избягващи символи са нужни в някои ситуации преди използването на JavaScript интерпретатора.[18]

Освен ако не се вземат предпазни мерки и първо да се валидират данните, техниката на eval е предмет на уязвимост в сигурността, ако данните и цялата среда на JavaScript не са под контрола на една система, на която може да се разчита. Като пример, ако данните сами по себе си не са достоверни, то може да сте предмет на атака от зловреден JavaScript. Също такива пробиви в сигурността може да създадът предпоставки за кражба на данни, кражба на самоличност и други потенциални грешни употреби на данни и ресурси. Регулярни изрази могат да бъдат използвани, за да се валидират правата на данните, които извикват eval(). Като пример, RFC, който дефинира JSON(RFC 4627) предполага използването на код за валидиране на JSON преди да се извика eval() (променливата 'text' е входа на JSON):

var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
    text.replace(/"(\\.|[^"\\])*"/g, ''))) && eval('(' + text + ')');

Нова функция , JSON.parse(), е разработена като по-сигурна алтернатива на eval. Тя е специално предназначена да обработва JSON код, а не JavaScript. Първоначално е планувано да се включи в четвъртото издание на ECMAScript стандартът,[19], но това не се случило. За първи път е било добавено към петото издание,[20] и сега се поддържа от повечето браузъри, които са дадени по-надолу. За по-старите има съвместима JavaScript библиотека, която е налична на JSON.org.

Нейтив кодиране и декодиране в браузъри[редактиране | edit source]

Скорошните интернет браузъри или имат или разработват нейтив JSON кодиране/ декодиране. Това не само елиминара проблемът в сигурността с използването на eval(), но също така увеличава производителността, защото вече функциите не трябва да се преобразуват. Нейтив JSON е по-бърз в сравнение с JavaScript библиотеките често използвани преди. От Юни 2009 следващите браузъри имат или ще имат нейтив поддръжка на JSON с JSON.parse() и JSON.stringify():

Най-малко пет популярни JavaScript библиотеки използват JSON, ако е възможно:

Кодирането по подразбиране в JSON e UTF8; той също поддържа UTF16 и UTF32.

Object references[редактиране | edit source]

Станадартът на JSON не поддържа обекти , но Dojo Toolkit илюстрира как спогодбите могат да бъдат осиновени, за да поддържат такива референции използвайки стандартен JSON. Специален dojox.json.ref модул дава поддръжка за няколко форми на получаване включително circular, множествени, inter-message, и lazy съотнасяния.[30][31] Алтернативни не стандартни решения съществуват като използването на Mozilla JavaScript Sharp Variables, въпреки че тази функционалност е премахната от Firefox във version 12.[32]

Сравнение с други формати[редактиране | edit source]

JSON е промотиран като слаба алтернатива на XML като и двата от тези формати имат голяма подкрепа за създаване, четене и декодиране в ситуации от реалния живот, където те често се използват. [33] Освен XML, примерите могат да включват OGDL, YAML и CSV. Също Google Protocol Buffers могат да изпълнят тази роля, въпреки че не е език за обмен на данни.

YAML[редактиране | edit source]

YAML е почти, но не напълно, подмножество на JSON. Като пример, избягването на наклонената черта (/) става с обратно наклонена черта (\) и е валиден JSON, но не и YAML. (Това е честа практика, когато се имплементира JSON в HTML, за да се защита от скриптови атаки от други сайтове.) Въпреки че, много YAML анализатори могат да анализират директно изхода на много JSON енкодери.[34]

XML[редактиране | edit source]

XML е бил използван, за да се описват структори от данни и да се сериализарт обекти. Съществуват различни XML-базирани портоколи, които да представят същият тип от структори от данни като JSON код за размяна на същите типове данни. Когато данни са кодирани в XML, резултатът е типично по-голям отколкото еквивалентното му кодиране в JSON, главно заради затварящите тагове на XML. Ако данните са компресирани използвайки алгоритъм като gzip има много малка разлика, защото компресията е добра в пестенето на място, когато даден код се повтаря на няколко места.

XML стойностите нямат сецифичен тип данни.

Примери[редактиране | edit source]

JSON примери[редактиране | edit source]

{
    "firstName": "John",
    "lastName": "Smith",
    "age": 25,
    "address": {
        "streetAddress": "21 2nd Street",
        "city": "New York",
        "state": "NY",
        "postalCode": "10021"
    },
    "phoneNumber": [
        {
            "type": "home",
            "number": "212 555-1234"
        },
        {
            "type": "fax",
            "number": "646 555-4567"
        }
    ]
}

И двата следващи примера имат един и същ тип от информация като JSON примера отгоре, но записано по различни начини.

YAML пример[редактиране | edit source]

Горният JSON код е също 100% валиден YAML; YAML също предлага алтернативен синтаксис предназначен да бъде по-човешки достъпен като замества наследените разделители като {}, [] и " със структорирани бели пространства, които подреждат кода чрез вдлъбвания.[34]

---
  firstName:  John
  lastName:  Smith
  age: 25
  address:
        streetAddress: 21 2nd Street
        city: New York
        state: NY
        postalCode: 10021

  phoneNumber:
        -
            type: home
            number: 212 555-1234
        -
            type: fax
            number: 646 555-4567

XML примери[редактиране | edit source]

<person>
  <firstName>John</firstName>
  <lastName>Smith</lastName>
  <age>25</age>
  <address>
    <streetAddress>21 2nd Street</streetAddress>
    <city>New York</city>
    <state>NY</state>
    <postalCode>10021</postalCode>
  </address>
  <phoneNumbers>
    <phoneNumber type="home">212 555-1234</phoneNumber>
    <phoneNumber type="fax">646 555-4567</phoneNumber>
  </phoneNumbers>
</person>
<person firstName="John" lastName="Smith" age="25">
  <address streetAddress="21 2nd Street" city="New York" state="NY" postalCode="10021" />
  <phoneNumbers>
     <phoneNumber type="home" number="212 555-1234"/>
     <phoneNumber type="fax"  number="646 555-4567"/>
  </phoneNumbers>
</person>

Ето защо XML кодиранетоможеда бъде сравнено по дължина с еквивалентно JSON кодиране. Съществуват много XML обработващи технологии, от Document Object Model до XPath и XSLT. XML също може да бъде стилизирано за мигновенно показване използвайки CSS. XHTML е форма на XML, в която елементите могат да бъдат подавани готови за директно имплементиране в интернет страници използвайки скриптове от страна на клиента.

Виж също[редактиране | edit source]

  • S-expression - сравнитеният LISP за дървета като текст.
  • JSONP – JSON със Padding, модел на използване на често заемани, когато се извлича JSON код от домейни
  • BSON – бинарен JSON
  • GeoJSON - отворен формат за кодиране на различни географски структури от данни
  • JSON-LD - JavaScript Object Notation за свързани данни, за момента е W3C Working Draft
  • JSON-RPC
  • SOAPjr – хибрид от SOAP и JR (JSON-RPC)
  • JsonML
  • Jayrock - отворен код за имплементация на JSON за .NET Framework

Референции[редактиране | edit source]

  1. Video: Douglas Crockford — The JSON Saga, on Yahoo! Developer Network. In the video Crockford states: "I do not claim to have invented JSON ... What I did was I found it, I named it, I described how it was useful. ... So, the idea's been around there for a while. What I did was I gave it a specification, and a little Web site."
  2. Chip Morningstar Biography. // undated.
  3. State Software Breaks Through Web App Development Barrier With State Application Framework: Software Lets Developers Create Truly Interactive Applications; Reduces Costs, Development Time and Improves User Experience. // PR Newswire. February 12, 2002.
  4. Yahoo!. Using JSON with Yahoo! Web services. // Архив на оригинала от October 11, 2007. Посетен на July 3, 2009.
  5. Google. Using JSON with Google Data APIs. // Посетен на July 3, 2009.
  6. Crockford, Douglas. Introducing JSON. // json.org, May 28, 2009. Посетен на July 3, 2009.
  7. JSON in JavaScript, on JSON's web page: "The eval function is very fast. However, it can compile and execute any JavaScript program, so there can be security issues [...]"
  8. Crockford, Douglas. JSON in JavaScript. // json.org, July 9, 2008. Посетен на September 8, 2008.
  9. Standard ECMA-262
  10. RFC 4627
  11. jquery - How to format a JSON date? - Stack Overflow
  12. Dates and JSON - Tales from the Evil Empire
  13. JSON Schema
  14. JSON Schema draft 4
  15. JSON Schema реализации
  16. IANA | Application Media Types
  17. Garrett, Jesse James. Ajax: A New Approach to Web Applications. // Adaptive Path, 18 February 2005. Посетен на 19 March 2012.
  18. JSON: The JavaScript subset that isn't. // Magnus Holm. Посетен на 16 May 2011.
  19. Crockford, Douglas. JSON: The Fat-Free Alternative to XML. // December 6, 2006. Посетен на July 3, 2009.
  20. ECMAScript Fifth Edition. // Посетен на March 18, 2011.
  21. Using Native JSON. // June 30, 2009. Посетен на July 3, 2009.
  22. Barsan, Corneliu. Native JSON in IE8. // September 10, 2008. Посетен на July 3, 2009.
  23. Web specifications supported in Opera Presto 2.5. // March 10, 2010. Посетен на March 29, 2010.
  24. Hunt, Oliver. Implement ES 3.1 JSON object. // June 22, 2009. Посетен на July 3, 2009.
  25. YUI 2: JSON utility. // September 1, 2009. Посетен на October 22, 2009.
  26. Learn JSON. // April 7, 2010. Посетен на April 7, 2010.
  27. Ticket #4429. // May 22, 2009. Посетен на July 3, 2009.
  28. Ticket #8111. // June 15, 2009. Посетен на July 3, 2009.
  29. Ticket 419. // October 11, 2008. Посетен на July 3, 2009.
  30. Zyp, Kris. JSON съотнасяния към Dojo. // Юли 17, 2008. Посетен на Юли 3, 2009.
  31. von Gaza, Tys. JSON referencing in jQuery. // Dec 7, 2010. Посетен на Dec 7, 2010.[мъртъв линк]
  32. Sharp променливи JavaScript. // Посетен на 21 Април 2012.
  33. JSON: Алтернативата на XML. // json.org. Посетен на 14 March 2011.
  34. а б YAML Version 1.2

Външни препратки[редактиране | edit source]