爲什麼unmarshalling json比xml更容易

Question

它只是內置工具嗎？從根本上來說，這種格式對自動編組xml毫無妨礙。

一個XML和JSON之間的唯一差異是[標籤] HI世界[/標籤]爲{標籤：HI世界}，分別 ..所以該JSON obj爲一半大小

正確？

Answer 1

這不一定容易。完整的JSON解析器實現可以像XML文檔一樣複雜。 當然，由於顯而易見的原因，JSON字符串的大小几乎總是小於其等效的XML。

但是，在XML中作爲數據傳輸格式的JSON之間的選擇取決於底層技術（JavaScript到JavaScript或服務器或其他方式）。 在其他情況下，例如，當您的數據已經以XML格式存在時，將其轉換爲JSON並不是非常高效，因此您可以將它發送到某處（對REST服務或其他任何地方）。

因此，這是一個簡單的選擇：選擇您使用的技術所支持的最佳選項。 JSON用於處理JavaScript和XML的SOAP Web服務，或者當您的數據已經在XML中。

Answer 2

JSON的根源在Javascript，這是一種動態語言，使用寬鬆的打字方式。每個數據項都是「鬆散類型的」，這意味着運行時系統並不在意這些東西是一串字符，一個數組，一個整數，還是一個對象或函數。變量具有「某些東西」，並且類型是在您嘗試使用某些東西時確定的。

因此，反序列化JSON數據包非常簡單。要反序列化的表示形式是字符串或數字。另一方面，XML Schema標準列出了許多特定的數據類型，包括像整數，浮點數，字符串等基本的東西，還有dateTime，日期，然後是更復雜的派生類型，如有序序列那些東西，這些東西的陣列，和「工會」。當定義這個XML的時候，在保證xml文檔是一個很好的構造方面做了大量的工作，而且b）根據這些相當具體的模式定義之一有效。大多數XML序列化器使用鍵入魔法的一部分。

在XML模式中，您還可以指定引用，以便XML文檔中的一個項目可以引用另一個項目。

作爲一個例子，當我使用stackexchange API查詢特定用戶發佈的「問題答案」列表時，我找回了一個項目列表，其中每個項目都包含一個用於同一用戶的重複塊。他們都像這樣（僞代碼）：

{ answers: [ 
    { answer_id: 98393398398 
    question_id 28282828 
    owner: { 
    name: Cheeso 
    user_id 48082 
    reputation: 3093 
    date_created: 110101010} 
    }, 
    { answer_id: 28783398398 
    question_id 111128828 
    owner: { 
    name: Cheeso 
    user_id 48082 
    reputation: 3093 
    date_created: 110101010} 
    }, 
    ... 
] } 

但XML允許我參考一下其他地方的文件中，所以我回來是這樣的（同樣，僞代碼）：

{ users: [ ["#user1", "Cheeso", "48082", 3093 ]] , 
    answers: [ 
    { answer_id: 98393398398 
    question_id 28282828 
    owner: #user1 }, 
    { answer_id: 28783398398 
    question_id 111128828 
    owner: #user1}, 
    ... 
] } 

當然，您可以構建您的JSON應用程序來理解和使用「文檔內參考」。但關鍵是，使用XML，這已經是模型的一部分。

所有這些都意味着序列化和反序列化XML在實踐中可能比用JSON做更多的參與。

我認爲人們會發現寬鬆的json方法更可取，因爲它更靈活，適應性更強，並且更易於使用。另一方面，一些文檔足夠大，XML模式的剛性和形式是非常有價值的，而json太鬆了。例如，我正在考慮一個OOXML文檔。

Answer 3

JSON提供了Javascript中使用的數據結構的序列化，它與許多編程語言中的數據結構非常相似。 XML是爲文檔標記而設計的。所以JSON的設計是爲了匹配什麼編程語言擅長的，XML的設計是爲了滿足文檔創作的需求。

人都在尋找寬鬆的JSON的方法是可取的，因爲它是更靈活

相反。人們發現JSON更可取，因爲它不夠靈活;它只會處理像Javascript這樣的語言很容易處理的事情。