яка різниця між json та xml [закрито]

У чому різниця між JSON та XML?

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

Мова розмітки - це спосіб додавання додаткової інформації до вільного текстового тексту, наприклад

Here is some text.

За допомогою XML (використовуючи певний словниковий запас) ви можете помістити:

<Document>
    <Paragraph Align="Center">
        Here <Bold>is</Bold> some text.
    </Paragraph>
</Document>

Саме це робить мови розмітки настільки корисними для представлення документів.

Позначення об'єкта, як JSON, не таке гнучке. Але це, як правило, добре. Коли ви представляєте об'єкти, вам просто не потрібна додаткова гнучкість. Щоб представити наведений вище приклад у JSON, вам фактично довелося б вирішити деякі проблеми, які XML вирішує за вас.

{
    "Paragraphs": [
        {
            "align": "center",
            "content": [
                "Here ", {
                    "style" : "bold",
                    "content": [ "is" ]
                },
                " some text."
            ]
        }
    ]
}

Це не так приємно, як XML, і причина в тому, що ми намагаємось зробити розмітку з позначенням об’єкта. Тому ми повинні винайти спосіб розкидати фрагменти простого тексту навколо наших об’єктів, використовуючи масиви «вмісту», які можуть містити суміш рядків та вкладених об’єктів.

З іншого боку, якщо у вас є типова ієрархія об’єктів і ви хочете представляти їх у потоці, JSON більше підходить для цього завдання, ніж HTML.

{
    "firstName": "Homer",
    "lastName": "Simpson",
    "relatives": [ "Grandpa", "Marge", "The Boy", "Lisa", "I think that's all of them" ]
} 

Ось логічно еквівалентний XML:

<Person>
    <FirstName>Homer</FirstName>
    <LastName>Simpsons</LastName>
    <Relatives>
        <Relative>Grandpa</Relative>
        <Relative>Marge</Relative>
        <Relative>The Boy</Relative>
        <Relative>Lisa</Relative>
        <Relative>I think that's all of them</Relative>
    </Relatives>
</Person>

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

Але найголовніше, що у нього є визначений спосіб розрізнення "запису" (елементи впорядковані, ідентифіковані за іменами) та "списку" (елементи, упорядковані, ідентифіковані за позицією). Позначення об'єкта практично марне без такої різниці. І XML не має такої різниці! У моєму прикладі XML <Person>є запис і <Relatives>є списком, але вони не ідентифікуються як такі синтаксисом.

Натомість XML має "елементи" проти "атрибути". Це схоже на таку саму різницю, але це не так, оскільки атрибути можуть мати лише рядкові значення. Вони не можуть бути вкладеними об’єктами. Отже, я не міг застосувати цю ідею <Person>, оскільки мені не потрібно перетворюватись <Relatives>на єдиний рядок.

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

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

На жаль для XML, ми вже маємо HTML як першу у світі мову розмітки текстових розміток. Була зроблена спроба переформулювати HTML з точки зору XML, але в цьому немає великої переваги.

Отже, XML (на мій погляд) мав би бути досить обмеженою нішевою технологією, яка найкраще підходить лише для винаходу власних мов розмітки текстового тексту, якщо ви з якихось причин не хочете використовувати HTML. Проблема полягала в тому, що в 1998 р. Все ще було багато галасу про Інтернет, і XML став популярним завдяки його поверхневій схожості з HTML. Дивним вибором дизайну було спробувати застосувати до ієрархічних даних синтаксис, насправді розроблений для зручної розмітки.

Вони обидва є форматами даних для ієрархічних даних, тому, хоча синтаксис досить різний, структура схожа. Приклад:

JSON:

{
  "persons": [
    {
      "name": "Ford Prefect",
      "gender": "male"
    },
    {
      "name": "Arthur Dent",
      "gender": "male"
    },
    {
      "name": "Tricia McMillan",
      "gender": "female"
    }
  ]
}

XML:

<persons>
  <person>
    <name>Ford Prefect</name>
    <gender>male</gender>
  </person>
  <person>
    <name>Arthur Dent</name>
    <gender>male</gender>
  </person>
  <person>
    <name>Tricia McMillan</name>
    <gender>female</gender>
  </person>
</persons>

Однак формат XML є більш досконалим, ніж показано в прикладі. Наприклад, ви можете додати атрибути до кожного елемента, а також можете використовувати простори імен для елементів розділів. Існують також стандарти для визначення формату XML-файлу, мови XPATH для запиту даних XML та XSLT для перетворення XML у дані презентації.

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

Хоча XML розроблявся як незалежний формат даних, JSON був розроблений спеціально для використання з Javascript та AJAX, тому формат точно такий же, як і літеральний об'єкт Javascript (тобто це підмножина коду Javascript, як, наприклад, може не містить виразів для визначення значень).

Різниця між XML та JSON полягає в тому, що XML - це мета-мова / мова розмітки, а JSON - це легкий обмін даними. Тобто синтаксис XML розроблений спеціально, щоб не мати властивої йому семантики. Назви окремих елементів нічого не означають, поки певна програма обробки не обробить їх певним чином. На відміну від цього, синтаксис JSON має певну семантику, вбудовану в речі між {} - це об’єкт, речі між [] - це масив тощо.

Таким чином, парсер JSON точно знає, що означає кожен документ JSON. Аналізатор XML знає лише, як відокремити розмітку від даних. Щоб розібратися зі значенням XML-документа, вам слід написати додатковий код.

Для ілюстрації суті, дозвольте мені запозичити приклад Гуффи:

{   "persons": [
  {
    "name": "Ford Prefect",
    "gender": "male"
 },
 {
   "name": "Arthur Dent",
   "gender": "male"
  },
  {
    "name": "Tricia McMillan",
    "gender": "female"
  }   ] }

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

Кращим XML-еквівалентом було б визначити (фіктивну) мову XJSON з такою ж семантикою, що і JSON, але використовуючи синтаксис XML. Це може виглядати приблизно так:

<xjson>   
  <object>
    <name>persons</name>
    <value>
      <array>
         <object>
            <value>Ford Prefect</value>
            <gender>male</gender>
         </object>
         <object>
            <value>Arthur Dent</value>
            <gender>male</gender>
         </object>
         <object>
            <value>Tricia McMillan</value>
            <gender>female</gender>
         </object>
      </array>
    </value>   
  </object> 
 </xjson>

Після того, як ви написали процесор XJSON, він може робити саме те, що робить процесор JSON, для всіх типів даних, які може представляти JSON, і ви можете перекладати дані без втрат між JSON і XJSON.

Отже, скаржитися на те, що XML не має тієї самої семантики, що й JSON, це пропускати суть. Синтаксис XML за задумом не містить семантики. Суть полягає в тому, щоб надати базовий синтаксис, який можна використовувати для створення мов розмітки з будь-якою потрібною вами семантикою. Це робить XML чудовим для створення спеціальних форматів даних та документів, оскільки вам не потрібно будувати парсери для них, вам просто потрібно написати процесор для них.

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

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

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

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

Це два різні способи представлення даних, але вони досить несхожі. На сторінках вікіпедії для JSON та XML подано кілька прикладів кожного з них, і є параграф порівняння

Це два формати подання інформації. Хоча JSON був розроблений для того, щоб бути більш компактним, XML був спроектований, щоб бути більш читабельним.

XML використовує структури тегів для представлення елементів, наприклад <tag>item</tag>, тому документ XML - це набір тегів, вкладених один в одного. А синтаксис JSON виглядає як конструкція з мови Javascript, з усіма речами, такими як списки та словники:

{
 'attrib' : 'value',
 'array' : [1, 2, 3]
}

Отже, якщо ви використовуєте JSON, дуже просто використовувати рядки JSON у багатьох мовах сценаріїв, особливо Javascript та Python.