Порівняння JSON та XML [закрито]

Хочу знати, що швидше: XML та JSON? Коли використовувати який?

Перш ніж відповісти, коли використовувати який, невеликий фон:

редагувати: Я повинен зазначити, що це порівняння дійсно з точки зору використання їх у браузері з JavaScript. Це не так , як формат або дані повинен бути використаний, і є багато хороших аналізатори , які змінять деталі , щоб зробити те , що я говорю , не зовсім справедливий.

JSON є і більш компактним, і (на мій погляд) більш читабельним - в передачі він може бути "швидшим" ​​просто тому, що передається менше даних.

При розборі це залежить від вашого аналізатора. Аналізатор, що перетворює код (будь то JSON або XML) у структуру даних (як карта), може отримати користь від суворого характеру XML ( XML-схеми чудово розмежують структуру даних) - однак у JSON тип елемента (String / Кількість / вкладений об'єкт JSON) можна зробити синтаксичний висновок, наприклад:

myJSON = {"age" : 12,
          "name" : "Danielle"}

Аналізатору не потрібно бути достатньо розумним, щоб зрозуміти, що 12представляє число (і Danielleє рядком, як і будь-який інший). Тож у javascript ми можемо:

anObject = JSON.parse(myJSON);
anObject.age === 12 // True
anObject.name == "Danielle" // True
anObject.age === "12" // False

У XML нам слід зробити щось на кшталт наступного:

<person>
    <age>12</age>
    <name>Danielle</name>
</person>

(як осторонь, це ілюструє те, що XML є більш багатослівним; турбота про передачу даних). Щоб скористатися цими даними, ми б провели їх через аналізатор, тоді нам доведеться викликати щось на кшталт:

myObject = parseThatXMLPlease();
thePeople = myObject.getChildren("person");
thePerson = thePeople[0];
thePerson.getChildren("name")[0].value() == "Danielle" // True
thePerson.getChildren("age")[0].value() == "12" // True

Насправді, хороший аналізатор цілком може набрати тип ageдля вас (з іншого боку, ви, можливо, не хочете цього робити). Те, що відбувається, коли ми отримуємо доступ до цих даних, - замість того, щоб шукати атрибути, як у прикладі JSON вище - ми робимо пошук карти на ключі name. Формувати XML таким чином може бути більш інтуїтивно:

<person name="Danielle" age="12" />

Але нам все одно доведеться шукати карти, щоб отримати доступ до наших даних:

myObject = parseThatXMLPlease();
age = myObject.getChildren("person")[0].getAttr("age");

EDIT: Оригінал:

У більшості мов програмування (не у будь-якому розтягуванні) пошук карти, такий як цей, буде дорожчим, ніж пошук атрибутів (як ми отримали вище, коли ми розібрали JSON).

Це вводить в оману: пам’ятайте, що в JavaScript (та інших динамічних мовах) немає різниці між пошуком карти та пошуком поля. Насправді пошук поля - це лише пошук карти.

Якщо ви хочете по-справжньому гідного порівняння, найкращим є його порівняння - робіть орієнтири в контексті, де ви плануєте використовувати дані.

Коли я набирав текст, Фелікс Клінг вже висунув досить лаконічну відповідь, порівнюючи їх з точки зору використання кожного з них, тому більше не буду продовжувати.

Швидше не є атрибутом JSON чи XML або результатом, який дасть порівняння між ними. Якщо такі є, то це атрибут парсерів або смуга пропускання, з якою ви передаєте дані.

Ось (початок) перелік переваг та недоліків JSON та XML:

JSON

Про:

• Простий синтаксис, що призводить до меншої націнки витрат у порівнянні з XML.
• Простий у використанні з JavaScript, оскільки розмітка - це підмножина буквальних позначень об'єктів JS і має ті ж основні типи даних, що і JavaScript.
• Схема JSON для опису, перевірки типу та структури даних
• JsonPath для отримання інформації в глибоко вкладених структурах

Con:

• Простий синтаксис, підтримується лише кілька різних типів даних.

• Немає підтримки для коментарів.

XML

Про:

• Узагальнена розмітка; можна створювати "діалекти" з будь-якою метою
• XML-схема для типу даних, перевірки структури. Також можливо створювати нові типи даних
• XSLT для перетворення у різні вихідні формати
• XPath / XQuery для вилучення інформації в глибоко вкладені структури
• вбудована підтримка просторів імен

Con:

• Відносно багатослівний у порівнянні з JSON (призводить до отримання більшої кількості даних за однаковий обсяг інформації).

Тож зрештою ви повинні вирішити, що вам потрібно . Очевидно, що обидва формати мають свої законні випадки використання. Якщо ви в основному використовуєте JavaScript, тоді вам слід перейти з JSON.

Будь ласка, додайте плюси і мінуси. Я не експерт XML;)

Швидкість обробки може бути не єдиним релевантним питанням, однак, оскільки це питання, ось деякі цифри у еталоні: JSON vs. XML: Деякі важкі цифри про багатослів’я . Щодо швидкості, у цьому простому орієнтирі XML представляє 21% накладні витрати на JSON.

Важлива примітка про багатослів’я, яка, як йдеться у статті, є найпоширенішою скаргою: на практиці це не так актуально (ні дані XML, ні JSON зазвичай не обробляються людьми, а машинами), навіть якщо це стосується швидкість, для стиснення потрібно трохи розумнішого часу.

Крім того, у цьому орієнтирі обробляється велика кількість даних, і типовий веб-додаток не передає фрагменти даних таких розмірів, як 90 МБ, і стиснення може бути не вигідним (для досить невеликих шматок даних стислий фрагмент буде більше, ніж нестиснений шматок), тому не застосовується.

Тим не менш, якщо компресія не бере участь, JSON, як очевидно, терміном, буде важити менше за канал передачі, особливо якщо він передається через з'єднання WebSocket, де відсутність класичного накладного режиму HTTP може змінити перевагу в JSON, навіть більше вагомий.

Після передачі дані повинні споживатися, і це враховується за загальний час обробки. Якщо потрібно передавати досить великі або складні дані, відсутність схеми, яку автоматично перевіряє перевіряючий XML-аналізатор, може зажадати більше перевірки даних JSON; ці перевірки повинні бути виконані в JavaScript, який, як відомо, не є особливо швидким, і тому він може представляти додаткові накладні витрати над XML у таких випадках.

У будь-якому випадку, лише тестування дасть відповідь на ваш конкретний випадок використання (якщо швидкість справді є єдиною справою, а не стандартна, ні безпека, ні цілісність…).

Оновлення 1: варто згадати, це EXI, двійковий формат XML, який пропонує стиснення за менші витрати, ніж використання Gzip, та збереження обробки, інакше необхідної для декомпресії стисненого XML. EXI - це XML, що BSON - JSON. Тут є короткий огляд з деяким посиланням на ефективність у просторі та часі: EXI: Останній бінарний стандарт? .

Оновлення 2: Існує також двійкові звіти про продуктивність XML, що проводяться W3C, оскільки ефективність та низька пам'ять та слід процесора також є предметом для області XML: Ефективна оцінка обміну обміну XML .

Оновлення 2015-03-01

Варто зазначити в цьому контексті, оскільки накладні витрати HTTP були поставлені як проблема: IANA зареєстрував кодування EXI (ефективний бінарний XML, згаданий вище), як кодування вмісту для протоколу HTTP (поряд із стисканням , дефляцією та gzip ) . Це означає, що EXI - це варіант, який, як можна очікувати, буде зрозумілий браузерам серед можливо інших HTTP-клієнтів. Див. Параметри протоколу передачі гіпертексту (iana.org) .

Цю статтю на цифровому базарі я вважав дійсно цікавою. Цитуючи свої цитати з Norm:

Про плюси JSON:

Якщо все, що ви хочете пройти, - це атомні значення або списки чи хеші атомних значень, JSON має багато переваг XML: він легко доступний через Інтернет, підтримує широкий спектр програм, легко писати програми для обробки JSON, У нього є кілька необов’язкових функцій, він зрозумілий і зрозумілий для людини, його дизайн формальний і стислий, документи JSON легко створювати, і він використовує Unicode. ...

Про плюси XML:

XML надзвичайно добре справляється з повним багатством неструктурованих даних. Мене взагалі не хвилює майбутнє XML, навіть якщо його смерть радісно святкує кадр дизайнерів веб-API.

І я не можу протистояти налаштуванню "Я вам це сказав!" жетон в моєму столі. Я з нетерпінням чекаю, що люди JSON роблять, коли їх просять розробити багатші API. Коли вони хочуть обмінюватися менш добре структурованими даними, чи впорядкують їх у JSON? Я бачу, що періодично згадується мова схеми для JSON, чи дотримуватимуться інші мови? ...

Я особисто погоджуюся з Нормою. Я думаю, що більшість атак на XML відбувається від веб-розробників для типових програм, а не насправді від розробників інтеграції. Але це моя думка! ;)

XML (розширювана мова розмітки) використовується часто XHR, оскільки це стандартна мова мовлення, яка може використовуватися будь-якою мовою програмування та підтримується як серверною, так і клієнтською стороною, тому це найбільш гнучке рішення. XML можна розділити на більше частин, щоб визначена група могла розробити частину програми, не впливаючи на інші частини. Формат XML також може бути визначений XML DTD або XML-схемою (XSL) і може бути протестований.

JSON - формат обміну даними, який стає все більш популярним, оскільки можливий формат програм JavaScript. В основному це масив нотацій об'єктів. JSON має дуже простий синтаксис, тому його можна легко вивчити. А також підтримка JavaScript розбирає JSON з evalфункцією. З іншого боку, evalфункція отримала негативи. Наприклад, програма може дуже повільно розбирати JSON і через безпеку evalможе бути дуже ризикованою. Це не означає, що JSON не гарний, просто треба бути обережнішими.

Я пропоную вам використовувати JSON для програм із легким обміном даними, як ігор. Оскільки вам не потрібно дуже дбати про обробку даних, це дуже просто і швидко.

XML найкраще підходить для великих веб-сайтів, наприклад, для покупок або чогось подібного. XML може бути більш безпечним і зрозумілим. Ви можете створити базову структуру даних та схему, щоб легко перевірити виправлення та легко розділити їх на частини.

Я пропоную вам використовувати XML через швидкість і безпеку, але JSON для легких речей.

Найважливіше в JSON - зберігати передачу даних в зашифрованому вигляді з міркувань безпеки. Без сумніву, JSON набагато швидше, ніж XML. Я бачив, як XML займає 100 мс, де як JSON взяв лише 60 мс. Дані JSON легко маніпулювати.