中國人似乎特別喜歡比較。總會有百無聊賴的提問：
哪種程式語言更好？ 
是寫服務端好還是客戶端好？
是Android好還是ios好？
是桌面端好還是移動端好還是網頁端好？
等等……

我猜這樣的人最後什麼都學不成，更多的情況是C語言都不瞭解，一行程式碼不會寫，就提出這樣的問題。

============================================================
現在開始正文：

做c/s開發的人，即使你一定不懂JavaScript，那你也一定聽說過JSON，也一定聽說過XML。

這是兩種人們常常採用的儲存資料的格式。

那麼國人的本性發作了：who is better?

JSON 和 XML誰更好呢?  誰更快呢？我到底該使用哪一個呢？就像比較自行車和汽車哪個更好一樣？

先什麼都不說，看個片段：

{  "id": 110,  "title": "Living or Die",  "author": "Wang Shubo",  "published": {    "by": "gcd",    "year": 2016  }}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

<?xml version="1.0"?><book id="110">  <title>Living or Die</title>  <author>Wang Shubo</author>  <published>    <by>gcd</by
 
>    <year>2016</year>  </published></book>

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

上面兩個片段就是最基本的xml和json結構，誰能根據這個就判斷who is better！！！
第一個片段共計140個字母，第二個片段167個字母，根據這個就能判斷who is better？

再看看他們的優缺點：
JSON
優點：
Simple syntax, which results in less “markup” overhead compared to XML.
Easy to use with JavaScript as the markup is a subset of JS object literal notation and has the same basic data types as JavaScript.
JSON Schema for description and datatype and structure validation
缺點：
Simple syntax, only a handful of different data types are supported.
支援的資料型別少。

XML
優點：
Generalized markup; it is possible to create “dialects” for any kind of purpose
XML Schema for datatype, structure validation. Makes it also possible to create new datatypes
XSLT for transformation into different output formats
XPath/XQuery for extracting information (which makes getting information in deeply nested structures much easier then with JSON)
built in support for namespaces
缺點：
Relatively wordy compared to JSON (results in more data for the same amount of information).
支援更多的型別，可以新增更多的資訊。

還有~
需要明確的是：
JSON is a good data format, and it is just a data format

所以，就是說很多情況下json是不能替代xml的：
XML is not a data format; it is a language. A very powerful one

從foreigner的一篇文章趴下來的理由：連結 http://www.yegor256.com/2015/11/16/json-vs-xml.html
XPath. 
To get data like the year of publication from the document above, I just send an XPath query: /book/published/year/text(). However, there has to be an XPath processor that understands my request and returns 2004. The beauty of this is that XPath 2.0 is a very powerful query engine with its own functions, predicates, axes, etc. You can literally put any logic into your XPath request without writing any traversing logic in Java, for example. You may ask “How many books were published by David West in 2004?” and get an answer, just via XPath. JSON is not even close to this.

Attributes and Namespaces. 
You can attach metadata to your data, just like it’s done above with the id attribute. The data stays inside elements, just like the name of the book author, for example, while metadata (data about data) can and should be placed into attributes. This significantly helps in organizing and structuring information. On top of that, both elements and attributes can be marked as belonging to certain namespaces. This is a very useful technique during times when a few applications are working with the same XML document.

XML Schema. 
When you create an XML document in one place, modify it a few times somewhere else, and then transfer it to yet another place, you want to make sure its structure is not broken by any of these actions. One of them may use  to store the publication date while another uses  with ISO-8601. To avoid that mess in structure, create a supplementary document, which is called XML Schema, and ship it together with the main document. Everyone who wants to work with the main document will first validate its correctness using the schema supplied. This is a sort of integration testing in production. RelaxNG is a similar but simpler mechanism; give it a try if you find XML Schema too complex.

XSL. 
You can make modifications to your XML document without any Java/Ruby/etc. code at all. Just create an XSL transformation document and “apply” it to your original XML. As an output, you will get a new XML. The XSL language (it is purely functional, by the way) is designed for hierarchical data manipulations. It is much more suitable for this task than Java or any other OOP/procedural approach. You can transform an XML document into anything, including plain text and HTML. Some complain about XSL’s complexity, but please give it a try. You won’t need all of it, while its core functionality is pretty straight-forward.

最後的最後，本想自己總結一下，但是在stackoverflow上看到了更好的，很到位：

如果你只是想簡單的傳遞atomic values，json比xml好用了太多：json可以直接用在Internet上，被很多應用程式廣泛的支援，而且可以寫很簡單的程式去處理json，json容易被建立，而且使用的是Unicode編碼。

對於非結構化的資料，我們就要使用xml

！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

彩蛋：
 I’m not worried about the future of XML at all even if its death is gleefully celebrated by a cadre of web API designers.

And I can’t resist tucking an “I told you so!” token away in my desk. I look forward to seeing what the JSON folks do when they are asked to develop richer APIs. When they want to exchange less well strucured data, will they shoehorn it into JSON? I see occasional mentions of a schema language for JSON, will other languages follow? …

最後，看到了一個人說的比較有意思：
抵制xml的大多是Web Developers，而不是integration developers。

笑而不語~~