者 | 豬哥
責(zé)編 | maozz
JSON的誕生原因是因為XML整合到HTML中各個瀏覽器實現(xiàn)的細節(jié)不盡相同,所以道格拉斯·克羅克福特(Douglas Crockford) 和 奇普·莫寧斯達(Chip Morningstar)一起從JS的數(shù)據(jù)類型中提取了一個子集,作為新的數(shù)據(jù)交換格式,因為主流的瀏覽器使用了通用的JavaScript引擎組件,所以在解析這種新數(shù)據(jù)格式時就不存在兼容性問題,于是他們將這種數(shù)據(jù)格式命名為 “JavaScript Object Notation”,縮寫為 JSON,由此JSON便誕生了!
今天我們來學(xué)習(xí)一下JSON的結(jié)構(gòu)形式、數(shù)據(jù)類型、使用場景以及注意事項吧!
JSON格式
上面我們知道JSON是從JavaScript的數(shù)據(jù)類型中提取出來的子集,那JSON有幾種結(jié)構(gòu)形式呢?又有哪些數(shù)據(jù)類型呢?他們又分別對應(yīng)著JavaScript中的哪些數(shù)據(jù)類型呢?
JSON的2種結(jié)構(gòu)形式,鍵值對形式和數(shù)組形式。
舉了一個JSON的實例,就是鍵值對形式的,如下:
{
"person": {
"name": "pig",
"age": "18",
"sex": "man",
"hometown": {
"province": "江西省",
"city": "撫州市",
"county": "崇仁縣"
}
}
}
這種結(jié)構(gòu)的JSON數(shù)據(jù)規(guī)則是:一個無序的“‘名稱/值’對”集合。一個對象以 {左括號 開始, }右括號 結(jié)束。每個“名稱”后跟一個 :冒號 ;“‘名稱/值’ 對”之間使用 ,逗號 分隔。
因為大多數(shù)的時候大家用的JSON可能都是上面那種key-value形式,所以很多人在講解JSON的時候總是會忽略數(shù)組形式,這一點是需要注意的。
那JSON的數(shù)組形式是怎么樣的呢?舉一個實例吧!
["pig", 18, "man", "江西省撫州市崇仁縣"]
數(shù)組形式的JSON數(shù)據(jù)就是值(value)的有序集合。一個數(shù)組以 [左中括號 開始, ]右中括號 結(jié)束。值之間使用 ,逗號 分隔。
JOSN的6種數(shù)據(jù)類型
上面兩種JSON形式內(nèi)部都是包含value的,那JSON的value到底有哪些類型,而且上期我們說JSON其實就是從Js數(shù)據(jù)格式中提取了一個子集,那具體有哪幾種數(shù)據(jù)類型呢?
string:字符串,必須要用雙引號引起來。
number:數(shù)值,與JavaScript的number一致,整數(shù)(不使用小數(shù)點或指數(shù)計數(shù)法)最多為 15 位,小數(shù)的最大位數(shù)是 17。
object:JavaScript的對象形式,{ key:value }表示方式,可嵌套。
array:數(shù)組,JavaScript的Array表示方式[ value ],可嵌套。
true/false:布爾類型,JavaScript的boolean類型。
:空值,JavaScript的。
以上數(shù)據(jù)形式圖片來源JSON官方文檔:http://www.json.org/json-zh.html
JSON使用場景
介紹完JSON的數(shù)據(jù)格式,那我們來看看JSON在企業(yè)中使用的比較多的場景。
接口返回數(shù)據(jù)和序列化。JSON用的最多的地方莫過于Web了,現(xiàn)在的數(shù)據(jù)接口基本上都是返回的JSON,具體細化的場景有:
Ajxa異步訪問數(shù)據(jù)
RPC遠程調(diào)用
前后端分離后端返回的數(shù)據(jù)
開放API,如百度、高德等一些開放接口
企業(yè)間合作接口
這種API接口一般都會提供一個接口文檔,說明接口的入?yún)ⅰ⒊鰠⒌龋?/p>
一般的接口返回數(shù)據(jù)都會封裝成JSON格式,比如類似下面這種
{
"code": 1,
"msg": "success",
"data": {
"name": "pig",
"age": "18",
"sex": "man",
"hometown": {
"province": "江西省",
"city": "撫州市",
"county": "崇仁縣"
}
}
}
程序在運行時所有的變量都是保存在內(nèi)存當中的,如果出現(xiàn)程序重啟或者機器宕機的情況,那這些數(shù)據(jù)就丟失了。一般情況運行時變量并不是那么重要丟了就丟了,但有些內(nèi)存中的數(shù)據(jù)是需要保存起來供下次程序或者其他程序使用。
保存內(nèi)存中的數(shù)據(jù)要么保存在數(shù)據(jù)庫,要么保存直接到文件中,而將內(nèi)存中的數(shù)據(jù)變成可保存或可傳輸?shù)臄?shù)據(jù)的過程叫做序列化,在Python中叫pickling,在其他語言中也被稱之為serialization,marshalling,flattening等等,都是一個意思。
正常的序列化是將編程語言中的對象直接轉(zhuǎn)成可保存或可傳輸?shù)模@樣會保存對象的類型信息,而JSON序列化則不會保留對象類型!
為了讓大家更直觀的感受區(qū)別,豬哥用代碼做一個測試,大家一目了然
Python對象直接序列化會保存class信息,下次使用loads加載到內(nèi)存時直接變成Python對象。
JSON對象序列化只保存屬性數(shù)據(jù),不保留class信息,下次使用loads加載到內(nèi)存可以直接轉(zhuǎn)成dict對象,當然也可以轉(zhuǎn)為Person對象,但是需要寫輔助方法。
對于JSON序列化不能保存class信息的特點,那JSON序列化還有什么用?答案是當然有用,對于不同編程語言序列化讀取有用,比如:我用Python爬取數(shù)據(jù)然后轉(zhuǎn)成對象,現(xiàn)在我需要將它序列化磁盤,然后使用Java語言讀取這份數(shù)據(jù),這個時候由于跨語言數(shù)據(jù)類型不同,所以就需要用到JSON序列化。
存在即合理,兩種序列化可根據(jù)需求自行選擇!
最后就是生成Token和配置文件
首先聲明Token的形式多種多樣,有JSON、字符串、數(shù)字等等,只要能滿足需求即可,沒有規(guī)定用哪種形式。
JSON格式的Token最有代表性的莫過于JWT(JSON Web Tokens)。
隨著技術(shù)的發(fā)展,分布式web應(yīng)用的普及,通過Session管理用戶登錄狀態(tài)成本越來越高,因此慢慢發(fā)展成為Token的方式做登錄身份校驗,然后通過Token去取Redis中的緩存的用戶信息,隨著之后JWT的出現(xiàn),校驗方式更加簡單便捷化,無需通過Redis緩存,而是直接根據(jù)Token取出保存的用戶信息,以及對Token可用性校驗,單點登錄更為簡單。
使用JWT做過app的登錄系統(tǒng),大概的流程就是:
用戶輸入用戶名密碼
app請求登錄中心驗證用戶名密碼
如果驗證通過則生成一個Token,其中Token中包含:
用戶的uid、Token過期時間、過期延期時間等,然后返回給app
app獲得Token,保存在cookie中,下次請求其他服務(wù)則帶上
其他服務(wù)獲取到Token之后調(diào)用登錄中心接口驗證
驗證通過則響應(yīng)
JWT登錄認證有哪些優(yōu)勢:
性能好:服務(wù)器不需要保存大量的session
單點登錄(登錄一個應(yīng)用,同一個企業(yè)的其他應(yīng)用都可以訪問):使用JWT做一個登錄中心基本搞定,很容易實現(xiàn)。
兼容性好:支持移動設(shè)備,支持跨程序調(diào)用,Cookie 是不允許垮域訪問的,而 Token 則不存在這個問題。
安全性好:因為有簽名,所以JWT可以防止被篡改。更多JWT相關(guān)知識自行在網(wǎng)上學(xué)習(xí),本文不過多介紹!
說實話JSON作為配置文件使用場景并不多,最具代表性的就是npm的package.json包管理配置文件了,下面就是一個npm的package.json配置文件內(nèi)容。
{
"name": "server", //項目名稱
"version": "0.0.0",
"private": true,
"main": "server.js", //項目入口地址,即執(zhí)行npm后會執(zhí)行的項目
"scripts": {
"start": "node ./bin/www" ///scripts指定了運行腳本命令的npm命令行縮寫
},
"dependencies": {
"cookie-parser": "~1.4.3", //指定項目開發(fā)所需的模塊
"debug": "~2.6.9",
"express": "~4.16.0",
"http-errors": "~1.6.2",
"jade": "~1.11.0",
"morgan": "~1.9.0"
}
}
但其實JSON并不合適做配置文件,因為它不能寫注釋、作為配置文件的可讀性差等原因。
配置文件的格式有很多種如:toml、yaml、xml、ini等,目前很多地方開始使用yaml作為配置文件格式。
JSON在Python中的使用
最后我們來看看Python中操作JSON的常用方法有哪些,在Python中操作JSON時需要引入json標準庫。
import json
類型轉(zhuǎn)換
Python類型轉(zhuǎn)JSON:json.dump
# 1、Python的dict類型轉(zhuǎn)JSON
person_dict={'name': 'pig', 'age': 18, 'sex': 'man', 'hometown': '江西撫州'}
# indent參數(shù)為縮進空格數(shù)
person_dict_json=json.dumps(person_dict, indent=4)
print(person_dict_json, '\n')
# 2、Python的列表類型轉(zhuǎn)JSON
person_list=['pig', 18, 'man', '江西撫州']
person_list_json=json.dumps(person_list)
print(person_list_json, '\n')
# 3、Python的對象類型轉(zhuǎn)JSON
person_obj=Person('pig', 18, 'man', '江西撫州')
# 中間的匿名函數(shù)是獲得對象所有屬性的字典形式
person_obj_json=json.dumps(person_obj, default=lambda obj: obj.__dict__, indent=4)
print(person_obj_json, '\n')
執(zhí)行結(jié)果:
JSON轉(zhuǎn)Python類型:json.loads
# 4、JSON轉(zhuǎn)Python的dict類型
person_json='{ "name": "pig","age": 18, "sex": "man", "hometown": "江西撫州"}'
person_json_dict=json.loads(person_json)
print(type(person_json_dict), '\n')
# 5、JSON轉(zhuǎn)Python的列表類型
person_json2='["pig", 18, "man", "江西撫州"]'
person_json_list=json.loads(person_json2)
print(type(person_json_list), '\n')
# 6、JSON轉(zhuǎn)Python的自定義對象類型
person_json='{ "name": "pig","age": 18, "sex": "man", "hometown": "江西撫州"}'
# object_hook參數(shù)是將dict對象轉(zhuǎn)成自定義對象
person_json_obj=json.loads(person_json, object_hook=lambda d: Person(d['name'], d['age'], d['sex'], d['hometown']))
print(type(person_json_obj), '\n')
執(zhí)行結(jié)果如下:
對應(yīng)的數(shù)據(jù)類型
上面我們演示了Python類型與JSON的相互轉(zhuǎn)換,最開始的時候我們講過JSON有6種數(shù)據(jù)類型,那這6種數(shù)據(jù)類型分別對應(yīng)Python中的哪些數(shù)據(jù)類型呢?
需要注意的點
JSON的鍵名和字符串都必須使用雙引號引起來,而Python中單引號也可以表示為字符串,所以這是個比較容易犯的錯誤!
Python類型與JSON相互轉(zhuǎn)換的時候到底是用load/dump還是用loads\dumps?
他們之間有什么區(qū)別?
什么時候該加s什么時候不該加s?
這個我們可以通過查看源碼找到答案:
不加s的方法入?yún)⒍嗔艘粋€fp表示filepath,最后多了一個寫入文件的操作。
所以我們在記憶的時候可以這樣記憶:
加s表示轉(zhuǎn)成字符串(str),不加s表示轉(zhuǎn)成文件。
Python自定義對象與JSON相互轉(zhuǎn)換的時候需要輔助方法來指明屬性與鍵名的對應(yīng)關(guān)系,如果不指定一個方法則會拋出異常!
相信有些看的仔細的同學(xué)會好奇上面使用json.dumps方法將Python類型轉(zhuǎn)JSON的時候,如果出現(xiàn)中文,則會出現(xiàn):
\u6c5f\u897f\u629a\u5dde
這種東西,這是為什么呢?
原因是:Python 3中的json在做dumps操作時,會將中文轉(zhuǎn)換成unicode編碼,并以16進制方式存儲,而并不是UTF-8格式!
總結(jié)
今天我們學(xué)習(xí)了JSON的2種形式,切記JSON還有[...]這種形式的。
學(xué)習(xí)了JSON的6種數(shù)據(jù)類型他們分別對于Python中的哪些類型。
了解了JSON的一些使用場景以及實際的例子。
還學(xué)習(xí)了在Python中如何使用JSON以及需要注意的事項。
一個JSON知識點卻分兩篇長文(近萬字)來講,其重要性不言而喻。因為不管你是做爬蟲、還是做數(shù)據(jù)分析、web、甚至前端、測試、運維,JSON都是你必須要掌握的一個知識點
本文為作者投稿,版權(quán)歸作者個人所有。
SON(JavaScript Object Notation)是一種輕量級的數(shù)據(jù)交換格式,JSON格式的數(shù)據(jù),主要是為了跨平臺交流數(shù)據(jù)用的。
但JSON和JavaScript確實存在淵源,可以說這種數(shù)據(jù)格式是從JavaScript對象中演變出來的,它是JavaScript的一個子集。JSON本身的意思就是JavaScript對象表示法(JavaScript Object Notation),它用嚴格的JavaScript對象表示法來表示結(jié)構(gòu)化的數(shù)據(jù)。
它是一種嚴格的js對象的格式,JSON的屬性名必須有雙引號,如果值是字符串,也必須是雙引號;
JSON只是一種數(shù)據(jù)格式(或者叫數(shù)據(jù)形式),數(shù)據(jù)格式其實就是一種規(guī)范,格式、形式、規(guī)范是不能用來存諸數(shù)據(jù)的。我們不能把以下的對象叫JSON,比如:
<script>
var obj2={};//這只是JS對象
var obj3={width:100,height:200};/*這跟JSON就更不沾邊了,只是JS的 對象 */
var obj4={'width':100,'height':200};/*這跟JSON就更不沾邊了,只是JS的對象 */
var obj5={"width":100,"height":200,"name":"rose"}; /*我們可以把這個稱做:JSON格式的JavaScript對象 */
var str1='{"width":100,"height":200,"name":"rose"}';/*我們可以把這個稱做:JSON格式的字符串 */
var a=[
{"width":100,"height":200,"name":"rose"},
{"width":100,"height":200,"name":"rose"},
{"width":100,"height":200,"name":"rose"},
];
/*這個叫JSON格式的數(shù)組,是JSON的稍復(fù)雜一點的形式 */
var str2='['+
'{"width":100,"height":200,"name":"rose"},'+
'{"width":100,"height":200,"name":"rose"},'+
'{"width":100,"height":200,"name":"rose"},'+
']' ;
/* 這個叫稍復(fù)雜一點的JSON格式的字符串 */
</script>
在互聯(lián)網(wǎng)上,最流行的兩大傳輸數(shù)據(jù)的標準就是json和XML了,關(guān)于誰是最好的,一直以來都是人們爭論的話題,其實各有各的缺點和優(yōu)點;
1.定義介紹
(1).XML定義
擴展標記語言 (Extensible Markup Language, XML) ,用于標記電子文件使其具有結(jié)構(gòu)性的標記語言,可以用來標記數(shù)據(jù)、定義數(shù)據(jù)類型,是一種允許用戶對自己的標記語言進行定義的源語言。 XML使用DTD(document type definition)文檔類型定義來組織數(shù)據(jù);格式統(tǒng)一,跨平臺和語言,早已成為業(yè)界公認的標準。
XML是標準通用標記語言 (SGML) 的子集,非常適合 Web 傳輸。XML 提供統(tǒng)一的方法來描述和交換獨立于應(yīng)用程序或供應(yīng)商的結(jié)構(gòu)化數(shù)據(jù)。
(2).JSON定義
JSON(JavaScript Object Notation)一種輕量級的數(shù)據(jù)交換格式,具有良好的可讀和便于快速編寫的特性。可在不同平臺之間進行數(shù)據(jù)交換。JSON采用兼容性很高的、完全獨立于語言文本格式,同時也具備類似于C語言的習(xí)慣(包括C, C++, C#, Java, JavaScript, Perl, Python等)體系的行為。這些特性使JSON成為理想的數(shù)據(jù)交換語言。
JSON基于JavaScript Programming Language , Standard ECMA-262 3rd Edition - December 1999 的一個子集。
2.XML和JSON優(yōu)缺點
(1).XML的優(yōu)缺點
<1>.XML的優(yōu)點
A.格式統(tǒng)一,符合標準;
B.容易與其他系統(tǒng)進行遠程交互,數(shù)據(jù)共享比較方便。
<2>.XML的缺點
A.XML文件龐大,文件格式復(fù)雜,傳輸占帶寬;
B.服務(wù)器端和客戶端都需要花費大量代碼來解析XML,導(dǎo)致服務(wù)器端和客戶端代碼變得異常復(fù)雜且不易維護;
C.客戶端不同瀏覽器之間解析XML的方式不一致,需要重復(fù)編寫很多代碼;
D.服務(wù)器端和客戶端解析XML花費較多的資源和時間。
(2).JSON的優(yōu)缺點
<1>.JSON的優(yōu)點:
A.數(shù)據(jù)格式比較簡單,易于讀寫,格式都是壓縮的,占用帶寬小;
B.易于解析,客戶端JavaScript可以簡單的通過eval()進行JSON數(shù)據(jù)的讀取;
C.支持多種語言,包括ActionScript, C, C#, ColdFusion, Java, JavaScript, Perl, PHP, Python, Ruby等服務(wù)器端語言,便于服務(wù)器端的解析;
D.在PHP世界,已經(jīng)有PHP-JSON和JSON-PHP出現(xiàn)了,偏于PHP序列化后的程序直接調(diào)用,PHP服務(wù)器端的對象、數(shù)組等能直接生成JSON格式,便于客戶端的訪問提取;
E.因為JSON格式能直接為服務(wù)器端代碼使用,大大簡化了服務(wù)器端和客戶端的代碼開發(fā)量,且完成任務(wù)不變,并且易于維護。
<2>.JSON的缺點
A.沒有XML格式這么推廣的深入人心和喜用廣泛,沒有XML那么通用性;
B.JSON格式目前在Web Service中推廣還屬于初級階段。
3.XML和JSON的優(yōu)缺點對比
(1).可讀性方面。
JSON和XML的數(shù)據(jù)可讀性基本相同,JSON和XML的可讀性可謂不相上下,一邊是建議的語法,一邊是規(guī)范的標簽形式,XML可讀性較好些。
(2).可擴展性方面。
XML天生有很好的擴展性,JSON當然也有,沒有什么是XML能擴展,JSON不能的。
(3).編碼難度方面。
XML有豐富的編碼工具,比如Dom4j、JDom等,JSON也有json.org提供的工具,但是JSON的編碼明顯比XML容易許多,即使不借助工具也能寫出JSON的代碼,可是要寫好XML就不太容易了。
(4).解碼難度方面。
XML的解析得考慮子節(jié)點父節(jié)點,讓人頭昏眼花,而JSON的解析難度幾乎為0。這一點XML輸?shù)恼媸菦]話說。
(5).流行度方面。
XML已經(jīng)被業(yè)界廣泛的使用,而JSON才剛剛開始,但是在Ajax這個特定的領(lǐng)域,未來的發(fā)展一定是XML讓位于JSON。到時Ajax應(yīng)該變成Ajaj(Asynchronous Javascript and JSON)了。
(6).解析手段方面。
JSON和XML同樣擁有豐富的解析手段。
(7).數(shù)據(jù)體積方面。
JSON相對于XML來講,數(shù)據(jù)的體積小,傳遞的速度更快些。
(8).數(shù)據(jù)交互方面。
JSON與JavaScript的交互更加方便,更容易解析處理,更好的數(shù)據(jù)交互。
(9).數(shù)據(jù)描述方面。
JSON對數(shù)據(jù)的描述性比XML較差。
(10).傳輸速度方面。
JSON的速度要遠遠快于XML。
4.XML與JSON數(shù)據(jù)格式比較
(1).關(guān)于輕量級和重量級
輕量級和重量級是相對來說的,那么XML相對于JSON的重量級體現(xiàn)在哪呢?應(yīng)該體現(xiàn)在解析上,XML目前設(shè)計了兩種解析方式:DOM和 SAX。
<1>.DOM
DOM是把一個數(shù)據(jù)交換格式XML看成一個DOM對象,需要把XML文件整個讀入內(nèi)存,這一點上JSON和XML的原理是一樣的,但是XML要考慮父節(jié)點和子節(jié)點,這一點上JSON的解析難度要小很多,因為JSON構(gòu)建于兩種結(jié)構(gòu):key/value,鍵值對的集合;值的有序集合,可理解為數(shù)組;
<2>.SAX
SAX不需要整個讀入文檔就可以對解析出的內(nèi)容進行處理,是一種逐步解析的方法。程序也可以隨時終止解析。這樣,一個大的文檔就可以逐步的、一點一點的展現(xiàn)出來,所以SAX適合于大規(guī)模的解析。這一點,JSON目前是做不到得。
所以,JSON和XML的輕/重量級的區(qū)別在于:
JSON只提供整體解析方案,而這種方法只在解析較少的數(shù)據(jù)時才能起到良好的效果;
XML提供了對大規(guī)模數(shù)據(jù)的逐步解析方案,這種方案很適合于對大量數(shù)據(jù)的處理。
(2).關(guān)于數(shù)據(jù)格式編碼及解析難度
<1>.在編碼方面。
雖然XML和JSON都有各自的編碼工具,但是JSON的編碼要比XML簡單,即使不借助工具,也可以寫出JSON代碼,但要寫出好的XML代碼就有點困難;與XML一樣,JSON也是基于文本的,且它們都使用Unicode編碼,且其與數(shù)據(jù)交換格式XML一樣具有可讀性。
主觀上來看,JSON更為清晰且冗余更少些。JSON網(wǎng)站提供了對JSON語法的嚴格描述,只是描述較簡短。從總體來看,XML比較適合于標記文檔,而JSON卻更適于進行數(shù)據(jù)交換處理。
<2>.在解析方面。
在普通的web應(yīng)用領(lǐng)域,開發(fā)者經(jīng)常為XML的解析傷腦筋,無論是服務(wù)器端生成或處理XML,還是客戶端用 JavaScript 解析XML,都常常導(dǎo)致復(fù)雜的代碼,極低的開發(fā)效率。
實際上,對于大多數(shù)Web應(yīng)用來說,他們根本不需要復(fù)雜的XML來傳輸數(shù)據(jù),XML宣稱的擴展性在此就很少具有優(yōu)勢,許多Ajax應(yīng)用甚至直接返回HTML片段來構(gòu)建動態(tài)Web頁面。和返回XML并解析它相比,返回HTML片段大大降低了系統(tǒng)的復(fù)雜性,但同時缺少了一定的靈活性。同XML或 HTML片段相比,數(shù)據(jù)交換格式JSON 提供了更好的簡單性和靈活性。在Web Serivice應(yīng)用中,至少就目前來說XML仍有不可動搖的地位。
*請認真填寫需求信息,我們會在24小時內(nèi)與您取得聯(lián)系。