為什麼XML這麼笨重的數據結構仍在廣泛應用?
JSON還沒有類似於XPath的成熟技術作支撐,在處理海量數據時將會是一場煉獄之旅。
XML是面向機器的數據格式,雖然手工編寫困難,但處理效率高。
反觀JSON,手寫很快,但要規範處理則不容易,特別是取得某個指定位置的數據,需要寫一堆的代碼,而不能向XPath這類引擎借力,在代碼維護上就有相當高的成本。機器的邊際成本永遠是廉價的,而人力則會越來越貴。
XPath已經標準化:XML Path Language (XPath)。
JSON方面了解不多,還沒有看到標準化的數據抽取引擎,可以看看這個:JSONiq - The JSON Query Language。誰說笨重了?你覺得笨重那是因為你用了某些要xml手寫配置文件的框架吧。xml本來就是設計為機器之間互通的。
更新:以上回答純粹為噴,下面好好答一下
首先你說XML笨重是不對的,應該說XML內容豐富而不是笨重。做網站開發的朋友馬上會想到簡單的JSON,為什麼我們不用JSON呢?XML中的X就是Extensible,它是可擴展的。這讓XML能夠變成任何你所需的文檔。Windows Presentation Foundation的XAML,蘋果的property list,蘋果畫GUI的xib文件,Firefox的界面標記語言XUL等等無數的應用,都是XML的例子。
如果拿JSON來做對比,缺點就在於擴展性差。舉例說你在做一個手機App的API網站,想要把一個日期傳送到客戶端。用XML只要在標籤加上屬性例如type="datetime",客戶端看到這個屬性,馬上把內容字元串解析成客戶端所支持的對象。而換做JSON,如果要實現類型安全的反序列化,笨辦法得用正則表達式去判斷每一個字元串,符合要則解析為日期。當然有很多其餘辦法可以規避對每個字元串使用正則判斷,但在這裡XML的可擴展性就是一個例子。試想下如果你要發明一種標記語言,以JSON作為基礎是件多麼痛苦的事情。
沒錯我們做手機API大部分時候還是使用了JSON,日期是個很好解決的例子,例如可以把字元串在伺服器直接給出客戶端直接顯示。但這並不能說明XML應用不夠廣泛,不適合其他場合。如果需要設計一種結構化的描述語言,只要給XML加一個schema就能很容易辦到,其他標記語言如JSON就不是那麼得心應手了。
我對XML的認識也經過的喜歡-討厭-理解的階段。我討厭XML的時候,是因為Java/C#裡面配置文件用這個寫,實在是痛苦。實際上很多時候是一些軟體、框架的作者在此錯誤的使用了XML,或者說把XML用在了不該用的地方。就像如果在今天一定要用C語言寫一個簡單的博客網站,再大罵C語言開發效率低一樣,那是自己的問題,而不是C語言。如果僅僅是表示簡單的鍵值對、數組的配置文件,YAML就是個很好的選擇,ruby社區廣泛流行。退一步講,寫XML也不是那麼痛苦的事情,有無數種工具輔助你。試想xhtml標準,手寫html沒有人抱怨。
有人抱怨&結束標籤,其實正是結束標籤讓XML解析變得容易,類似當初C語言自由格式對古老的固定格式。當然固定縮進由於有了現代的編輯器,又慢慢開始採用,如Python語言,HAML標記語言。只能說兩者各有千秋,從來沒有哪一種打敗哪一種。作為自由格式,XML在解析的時候可以忽略所有空格,很容易知道一個語義塊的結束。而且冗餘的信息還有助於在片段丟失後進行修補。試想下YAML錯了一個縮進,除非知道該文件格式,否則極難猜測它本來的結構。
至於多出來的幾個位元組,有誰會在乎呢?實在要分析,第一我們有gzip壓縮,特別擅長對付重複的字元串;第二,由於容易解析帶來的解析器的簡化,其實是減少了總的碳排放量。xml哪裡笨重了,如果說到長度,json每一個attribute name都要加上一對雙引號,基本上跟xml的&就互相抵消了。說到library,顯然xpath和xschema的重要性json完全無法提供。多少人想給json寫一個query language最後都傻逼了,就是因為json沒有【類型名字】導致的。
xschema那可好用了。初學者可以用xschema來做簡單的檢查,高手可以把xschema當type-2 grammar來用,就跟用antlr寫parser一樣容易。假如我的協議用xml來寫,反正gzip一下都是很短的,到了伺服器只要一上xschema就可以驗證正確性了。你來一個json,我伺服器要檢查你的json是否合法,正確的才接受,錯誤的要告訴客戶端到底錯在哪,卧槽那多麻煩啊。檢查json是否滿足一個指定的【樣子】這種事情,已經麻煩到了只會導致你根本不檢查。嗯,然後隨著系統越來越大,你就傻逼了。
總的來說,json之所以流行,純粹是因為滿足了程序員那種可以不顧質量隨便寫出一個程序的需求而已。如果你真的要把系統的validation做完整,那一點都不比xml好用。
因為佔了先機。這個格式最初就已經被定義出來了,並且被應用到很多地方,再想改,代價很大。
從純語言的角度來說,json 不適合強類型語言,但非常適合動態語言,xml 不適合動態語言但非常適合強類型的語言。c/c++/java 處理 xml 比處理 json 更容易。而 lua/python/ruby/javascript 一類的語言處理 json 比處理 xml 更容易。
xpath 的引入只是使得處理 xml 終於能夠接近 json 的處理方式而已,它並不是一種超越,而是說有了 xpath 之後,xml 的易用性站到 json 同一條線上,xml 跟 json 孰優孰劣,嚴重依賴於你使用它的編程語言,對於動態的弱類型語言來說,xml 沒有優勢,對於靜態的強類型語言來說,xml 優勢明顯。
更多的時候你面對一幫 java 工程師他們一定會給你整個 xml 格式,面對後面那些語言的擁護者他們多半會給你弄個 json 格式。誰說語言與編程完全無關呢?語言不是那麼的重要,但也不是你想像的那麼不重要。
也許,主流 c/c++/java 語言的 json 庫都很糟糕,也是這些語言不適合用 json 的一個重要原因。
XML是一個家族的技術,人們拿XML和JSON作比較的時候往往把注意力放在作為一種結構化數據的表示語言,單就這個角度來說,XML誠然很「笨重」。實際上XML包含了一系列技術, 請看 XML Technologies
現在XML之所以仍在廣泛使用,我覺得可以從幾個角度來看待- 歷史原因,早先制定的介面和各種標準都是基於XML格式的,因為XML畢竟曾經流行過一段時間
- XML所謂的「笨重」其實不是一個根本問題,選擇JSON而不選擇XML在很多場景下更多是一個「品味」問題,而不構成一個關鍵技術決策點,也就是說如果我之前選擇了XML,哪怕只要我願意我可以切換成JSON,但從技術角度,這不是「不得不做」的改動;本質上XML和JSON只是實現不同,兩者都用來描述結構化數據,設計本質是相通的
- 看過前面的鏈接,確實有JSON做不了的事,比如JSON沒有XSLT的對應,所以JSON數據只是數據,而XML數據可以配合其他技術衍生別的應用;這當然不是JSON的問題,因為JSON設計的目的不在那些點上;
- XML格式的擴展能力在一些場景下比JSON靈活,舉一個例子(不一定最十分恰當),假設我不得不把{"name": "Bob", "age": 30}轉換成數組,那麼就可能需要改成這樣的形式 [["name", "Bob"], ["age", 30]] ,原因是比如所解析的語言里,object notation產生的object的key是不排序的(比如javascript),你會看到轉換本身帶來的結構變化比較大,因為JSON格式一旦協定,是Object還是Array這樣的信息就已經確定了,XML更側重表示數據的從屬關係,解析成數組還是object還可以由解析器或者上層代碼來決定&
&
Bob& &30&&,在一個數據結構本身非常不穩定的場景下,XML的適應性會好一些。
XML的語法元素種類多,對於一般熟悉JSON或類似Key-value結構的人來說都會覺得它很笨重。但是,很多數據結構本身比Key-value結構要複雜得多,這個時候XML的優勢才能體現出來,因為很多信息可以在語法層面上表達出來,像這樣:
&
&
&
&
否則的話,像JSON只有array和dict,語法層面的信息很少,只能靠你自己從語義上附帶額外信息:
{
"comment": "a comment",
"type": "View",
"size": "400, 300",
"subview": [
{
"type": "TextView",
"size": "200, 100",
"content": "Hello!"
}
]
}
所以,到底哪個格式適合你,要看你需要表達的數據結構本身和哪一種語言的模型元素關係更貼合。
--
跟笨重無關,關鍵是適用性和歷史。- C vs JAVA (恆久遠的話題)
- JAVA vs Ruby (靜態語言和動態語言之爭)
- Properties vs XML vs JSON vs YAML (配置文件之爭)
估計樓主是看了SSH的XML配置吧,以前稱為 The XML Configuration Hell
然後就流行Annotation註解的方式,通過meta元數據來描述。現在動態語言就更喜歡用DSL等方式。PS: XML的應用不僅僅是配置文件。
一些擴展閱讀:- XML vs YAML vs JSON: A Study To Find Answers
- perl - XML vs YAML vs JSON
- http://blog.apigee.com/detail/why_xml_wont_die_xml_vs._json_for_your_api
- What are the pros and cons of XML and JSON?
你用{XAML寫WPF/UWP}/{XML寫Android}就知道XAML/XML多好使了
不信你可以嘗試把我這段改寫成json試試
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
&
那段XAML運行起來就長這個樣子【裡邊的3D模型是代碼生成的】
【WPF和winform聯動會有點問題,湊活看吧,這問題我也不會修~
整體排版略亂,是因為之前這個窗口我沒加多少鍵盤的操作,全靠左邊八個按鈕移動視角。加上鍵盤滑鼠的代碼後那八個按鈕就給刪了】
業界標準已經形成了,絕不是輕易能更換的了的。
XML還是個行業標準,有些連行業標準都不是,你像http://VB.Net這麼笨的語言,就因為歷史悠久,積累了很多用戶,微軟推銷得好,也能得到廣泛應用。
http://VisualBasic.NET 現在2016年6月份,排在TIOBE世界編程語言排行榜第9名
json的流行是因為近幾年web的快速發展,前端語言javaScript天生支持Json,解析一點都不費勁,Json相比XML確實更加輕量級,帶寬利用率高,數據結構支持數組,字元串,整型,嵌套對象等,適合web傳輸。
而XML之所以能成為行業的標準,因為它可擴展,XML Scheme定義了它的數據結構,很容易創建新的結構,非常適合數據存儲,不論是ant,maven還是spring,hibernate甚至Android的配置文件都採用了XML,都歸功於它的易擴展,對機器來說解析起來也很方便。
json的數據類型需要進行推導,所以更適合動態語言比如javaScript,總之不能說哪個好哪個不好,看具體的使用環境和需求。xml 本身並不笨重,題主說的笨重可能只是在使用它作為「數據交換」相比於 json 時的印象。但除了「數據交換」 xml 主要存在的意義是它的「可擴展標記」的功能,它不僅是包含數據還描述了數據本身是什麼,利用它你能自行定義服務或應用相關的交換格式,通過數據控制邏輯,比如 .doc、.xls 文件除了需要文檔中攜帶的內容,還需要知道內容對應的樣式、提供的交互方式。
再說說 xml 相比於 json 所運用場景的不同,使用後者是因為在不同端已經明確知道我要什麼樣的數據,即通過代碼就能夠知曉業務邏輯比如回答裡面可以嵌入視頻並點贊,使用 json 這種 kv 數據格式最方便不過了,可以定義一個 key 表示是否包含視頻,如果有則讀取另一個表示視頻地址的 key 。但如果有需求是對問題也能嵌入視頻怎麼辦,問題的結構里也加兩個 key?如果在一開始在 xml 的基礎之上定義出結構和規則,只需要實現出現「視頻結構」時的通用邏輯,那麼這種擴展性就是自然而然的了。
在人類讀取方面,XML的優點主要是兩個1. 每個obj有兩種屬性的寫法,一些寫在&<&>里的屬性就可以直觀的告訴讀者這個和children不同2. 結束符號仍然顯示名稱,你直到結束到哪一層了,JSON如果遇到} } } } },就會傻傻分不清楚結束到哪一層。
技術和市場是兩回事
對JavaScript來說,json確實簡潔明快;對C/C++/C#來說,json比XML更笨重。
最近接觸了下xml,一切用代碼處理起來方便的都算不上笨重。
被忽悠了,切入太深。其他廉價的切換替代方案沒有出現--換言之,JSON還不夠優秀。
XML 個人認為是一個比較好的介於 人的認知 和 機器的認知 之間的語言。
XML 與 json 之類的比較,就想 白話文 和 文言文之間的區別。。要快要效率,必然文言文寫出的東西簡短;要人人都理解,必然白話文要容易的多。。XML 說不上笨重,關鍵是你看中它那方面的東西。。推薦閱讀:
※為什麼都反對 XML 而支持使用 JSON?
※XML到底是幹什麼的?
※關於能否基於XML重新實現TeX?
TAG:XML |