如同人類通過交流相互合作，計算機網絡中計算機的相互合作也依賴於彼此的信息交流。人類間的相互交流可以通過當面交流，電話，短信，郵件，IM應用來實現，但這建立在兩人使用共同語言的基礎上。計算機間可以以TCP等方式傳輸數據，但我們需要預定義一種爲雙方計算機所接受的“語言“，方能使數據交流正常進行，這種語言我們稱之爲”數據交換語言“。
基於數據交互的基礎性，各種開發語言基本都提供了自身的數據交換功能或者對通用交換語言標準的接口。但在不同的系統不同的語言間交換數據時，我們一般傾向於使用無關於平臺及語言的數據交換語言。此類語言主要包括XML，JSON，YAML，Protobuf等，常用於接口調用，配置文件，數據存儲等場景。
JSON作爲一種輕量級的，易於編寫和閱讀的數據交換語言在web開發中得到了越來越多的應用，本文將對JSON的歷史，特點及語法進行簡要介紹，並將其與XML語言進行橫向對比，通過不同應用場景對數據交換語言的不同要求分析對數據交換語言的選擇。
JSON歷史
JSON全稱爲JavaScript Object Notation（ JavaScript 對象表示法）， 是基於JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999的一個子集。
JSON早在2000年就已經在使用了。2006年Douglas Crockford把JSON提交給IETF後，JSON開始作爲Javascript的一個嚴格的子集得到推廣。JSON用Javascript中的一些模式來表示結構化數據，這使得JSON對於Javascript開發者來說極爲易讀易寫，極大地推動了JSON在web開發界的應用。目前JSON已被越來越多的API及Database選爲輸出的首選格式，在輕量級數據交換語言界獨佔鰲頭。
JSON特點
1. JSON是一種輕量級的數據交換語言而非編程語言，其語法只支持字符串，數值，布爾值及null以及在此基礎上的對象和數組。JSON輕量級的一部分體現即來源於此，因爲JSON只處理了非常有限的數據類型，甚至沒有一個日期數據類型。與之相對的重量級數據交換語言如XML則擁有更爲複雜的數據類型及規則。有限的數據類型固然一定程度上限制了JSON在功能上的實現，卻也使得JSON字符使用量極少，極大地降低了讀寫成本，特別適合互聯網的數據傳遞。
2. JSON採用與編程語言無關的文本格式，任何編程語言只要按JSON的規則都能解析JSON，這使得JSON的跨平臺傳遞效率極高。JSON同時採用了大量類C語言（C，C++，C#，Java，JavaScript，Perl，Python等）的語言習慣，使得其可讀性極高，容易編寫編譯。
3. JSON是Javascript的一個子集，因而具有Javascript的原生支持。JSON可以用Javascript內建的方法直接進行解析，轉換成Javascript也非常方便。
4. JSON不是完整的標記語言，這使得其拓展性及可檢索性較低。
JSON語法
我們在上文提過， JSON其語法只支持字符串，數值，布爾值及null以及在此基礎上的對象和數組。下面我們分別介紹其在JSON中的表達形式。
1. 對象
對象是一個無序的“鍵－值”集合。一個對象以“{”（左括號）開始，“}”（右括號）結束。每個“鍵”後跟一個“:”（冒號）；“鍵－值”之間使用“,”（逗號）分隔。
2. 數組
數組是值（value）的有序集合。一個數組以“[”（左中括號）開始，“]”（右中括號）結束。值之間使用“,”（逗號）分隔。
3. 值
值（value）可以是雙引號括起來的字符串（string）、數值(number)、true、false、 null、對象（object）或者數組（array）。這些結構可以嵌套。
具體的字符串和數值的實現與Javascipt非常類似，這裏就不多展開了，下面給出幾個JSON代碼樣例。
對python中dictionary熟悉的讀者相信能很輕鬆地提取出其中的信息。JSON的解析工具浩如繁星，如JavaScript中的eval()函數，這裏也不詳細展開了。
額外安利一個檢驗JSON格式的網址JSON在線解析及格式化驗證 - JSON.cn，不僅能在線檢驗JSON代碼格式的正確，同時能夠給出相應的修改意見。如果你的代碼沒有問題，還會自動幫你排版爲更易讀的版式，強迫症福音！
JSON與XML的對比
XML全稱爲extensible markup language，是一種類似於HTML的語言。XML沒有預先定義的標籤，使用DTD(document type definition)文檔類型定義來組織數據，是業界公認的標準數據交換語言之一。
JSON與XML的區別主要包括：
1. 標記語言
JSON與XML最大的不同在於XML是一個完整的標記語言，而JSON不是。這使得XML在程序判讀上需要比較多的功夫。XML利用標記語言的特性提供了絕佳的延展性（如XPath），在複雜數據存儲，擴展及高級檢索方面具備對JSON的優勢，但同時也意味着冗餘信息較多。對於需要高性能交互的應用，過多的冗餘信息則成了缺點。
2. 字符佔用量
XML由於其標記語言的特性具有大量的冗餘信息，這使得其字符佔用量超過同等信息量的JSON文件。以下我們提供一個例子：
爲了提供一個人的相關信息，我們先以XML語言編寫相關文件：
然後我們再以JSON文件編寫一次：
可以看出，字符數僅爲XML編碼所用約1/2。
3. 編譯方式
XML主流的編譯方式包括DOM, SAX,JDOM 和DOM4J四種，DOM擁有較強的遍歷能力和檢索能力，但需要將文件整體讀入內存進行處理，對計算機性能和內存的要求較高。SAX處理的優點非常類似於流媒體的優點。分析能夠立即開始，而不是等待所有的數據被處理。而且，由於應用程序只是在讀取數據時檢查數據，因此不需要將數據存儲在內存中。這對於大型文檔來說是個巨大的優點。 而目前JSON的編譯方式還比較單一，與DOM較爲類似。因而在大規模數據的處理上有一定劣勢。
JSON vs XML -- 應用場景分析
從以上分析我們可以得出，JSON由於其非標記語言的設計思路具有字符利用率高，解析速度快的優點，而XML作爲一種完整的標記語言雖然繼承了標記語言的冗餘度，在讀寫成本上遜色於JSON，但在數據的檢索與複用上對JSON有較大的優勢。下面我們就不同的應用場景分析對JSON和XML的選擇。
1. 開放式平臺
此類應用場景實例包括微博，Facebook等。此類場景的特點是：
1. 調用方不完全可控，而且是針對公網的，你可能不知道是誰、是什麼語言、是什麼方式在調用你提供的數據接口；
2. 接口訪問量一般都非常大，要求具有很高的性能和吞吐量；
3. 需要考慮安全問題，外部提交的數據可能不是合法的。
所以在這種情況下，需要考慮數據傳輸的帶寬消耗和數據交換協議的易用性，以及多語言支持程度。以前對於html頁面使用的JavaScript接口調用一般都使用XML格式，最近幾年幾乎都轉成了JSON格式了，因爲JSON傳輸量更小，比XML更加容易使用。 而對於開放平臺，由於使用的場景很多，所以需要提供多種交換協議格式。基本上都會提供XML和JSON。
大型互聯網公司像Twitter， Facebook和LinkedIn的很多原始數據仍然使用XML而不是JSON存儲，像可編程Web和其他數據表明，XML仍然是API的主要數據格式，但是“大JSON”正在快速上升。 Twitter的API大約兩年前開始就只支持JSON了。Foursquare也跟進了。
有業界人士表示：“當涉及到數據API服務時， XML仍然是最常用的格式，但JSON是的增長更快。儘管還有很多XML格式的API，但最近的API ，越來越傾向於使用JSON格式。這樣的例子還有很多…… 企業正在迅速從XML遷移到JSON。”
2. 內部服務
對於一個大型系統來說，內部服務的數據交換無處不在。從最基本和常見的數據庫數據交換、memcached緩存數據交換、消息隊列的數據交換到系統之間使用的RPC服務框架等等，都可以算作內部服務的數據交換。
內部服務的特點是不用考慮防火牆，不對外開放，速度快（基本無帶寬成本）。
內部服務的數據交換協議的選擇空間非常大，一般需要考慮：
1. 數據交換語言的性能
2. 是否需要跨語言支持
3. 數據交換協議的消息體大小
以數據庫爲例，傳統數據庫如Oracle,Postgres等均支持XML，因爲在數據量的吞吐上數據交換語言的性能及消息體大小並不會成爲瓶頸，同時傳統關係型數據庫對數據的可檢索性及複用性要求較高，這使得XML成爲一種理想的選擇。
而隨着大數據和NoSQL型數據庫的發展，JSON在數據庫上的應用越來越普遍，因爲
1. JSON的設計思路就是從存儲無關係數據的角度出發的，這與NoSQL型數據庫的設計出發點相符；
2. 大數據時代數據規模的激增及分佈式存儲使得數據交換語言的性能及消息體大小成爲制約數據庫性能的極大瓶頸。
這是有很多知名的例子，像MongoDB，CouchDB，和Riak。這三種數據庫都基於JSON，橫向可擴展，由Web驅動。
其他的例子比比皆是：亞馬遜DynamoDB的架構是完全基於REST/JSON的。 Neo4j，圖形數據庫，有一個REST/JSON API，沒有對應XML的支持。 HBase的的REST架構目前支持XML，但這種支持正走在被廢棄的路上。
結語
JSON作爲一種輕量級的數據交換語言，因其較低的讀寫成本，較好的跨平臺性以及其數據結構與當前數據交流要求的契合在web大數據時代得到了越來越廣泛的應用。但JSON並不是盡善盡美的，從其語法結構的設計我們可以看出JSON是基於”鍵－值“型數據的一種較爲簡單的數據交換語言，單一的數據結構在提供了較低讀寫成本的同時也使得JSON的檢索效率及可複用性較差，使其在複雜關係性數據的存儲上具有一定劣勢。在實際應用中我們仍需根據數據類型，硬件性能及數據交流實際需求在以JSON爲代表的輕量級數據交換語言和以XML爲代表的重量級數據交換語言間做出合理的選擇。
參考
軟件系統開發中的數據交換協議