原文:Web Storage: A Primerjavascript
Web Storage是相對比較新的一種能夠將數據存儲在用戶電腦(客戶端)的一種方式。java
Web Storage給網站/應用提供了不少好處。好比,Web Storage能夠用來跨網站/應用監測用戶的行爲而不須要服務端腳本和數據庫。Web Storage也能在用戶即便忽然斷網的狀況下保存一部分web應用的能力,讓你不會由於網絡鏈接的問題受到影響git
傳統的用來在客戶端保存數據的方式是經過HTTP cookies。github
Web Storage和cookies之間存在着不少的區別。讓咱們把注意力放在這兩種客戶端數據存儲的方法的真正的區別上。web
Cookies是一種結構化的數據,是由web服務器返回給請求的一個服務器響應的一部分。Cookie能夠經過設置HTTP響應頭來進行設置。不管何時發送請求,瀏覽器都會把cookie做爲請求頭的一部分返回給服務器。數據庫
簡單的來講,請求發送的目的是爲了可以更新cookie裏面的值。同時,不管數據有沒有改變,cookies也老是會佔據HTTP響應頭的一部分。跨域
另外一方面,Web Storage的建立和管理徹底是由客戶端控制的。所以,儘管有服務器的參與有不少其餘的優點,但Web Storage仍是避免了web服務器的參與。這個方法產生了不少有益的結果,最明顯的莫過於理論上致使了更好的web性能。(相關:Web性能文章)瀏覽器
同時,由於Web Storage能夠在沒有HTTP請求/響應的狀況下工做(擺脫了網頁初始與服務器的交互),在良好的實現狀況下,存儲在用戶瀏覽器的數據能夠在失去網絡鏈接的狀況下也能安全的更新和修改。安全
Web Storage可以解決用戶開啓多個瀏覽器窗口/標籤的同步問題。在一個瀏覽器窗口在存儲或者更新數據可以同時在其餘瀏覽器窗口上同步,只要其餘瀏覽器窗口在同一個網站上。服務器
Cookies,相反,設計之初就不是用來處理設計多個瀏覽器窗口的狀況。
HTTP cookies和Web Storage對存儲大小的限制在不一樣瀏覽器之間是不一樣的。可是,通常爲了可以好的跨瀏覽器支持把存儲大小限制在4.0KB左右是最佳的實踐方案。
(這裏有一種cookie測試工具可讓你測試瀏覽器的cookie的存儲大小限制)
W3C Web Storage標準並無推薦一個默認的存儲限制,讓瀏覽器本身決定。可是,現實中Web Storage完虐cookies的4.0KB的限制,通常狀況下對於Web Storage對象的限制時5MB左右。
也就是說,Web Storage的大小限制是cookies的124527%倍那麼大。
(這裏也有一種Web Storage測試工具可讓你測試瀏覽器Web Storage的存儲大小限制)
Web Storage有兩種方式來存儲客戶端數據:sessionStorage和localStorage.
Web Storage | 存儲數據的生命週期 | 數據結構 | 數據類型 |
---|---|---|---|
sessionStorage | 只在回話中保存 | 鍵值對 | 字符串 |
localStorage | 持久保存 | 鍵值對 | 字符串 |
sessionStorage是設計用來保存瀏覽器會話這個時間段的客戶端數據的。換句話說數據只在用戶還在網站瀏覽的時候才保存起來。
sessionStorage在實踐中主要用來暫時的數據 存儲。好比說,用戶在網頁表單上的輸入可以在用戶瀏覽器會話的階段保存在sessionStorage對象當中。這樣的話,數據就可以在瀏覽的整個過程當中得到到而不須要把數據存儲到服務器當中。也就是說,當用戶不當心關閉或者刷新瀏覽器窗口,暫時的數據存儲能夠防止用戶不得不重複輸入數據。
從實現的角度來講,localStorage和sessionStorage的實現方式是基本相似的。
localStorage和sessionStorage分享一套javascript方法(好比說:getItem
,setItem
等等),而且它也以鍵值對的方式存儲數據。
可是,把數據存儲在localStorage對象上意味着數據能夠在用戶的會話之間一直保存着。換句話說,數據能夠在用戶下一次訪問這個網站的時候依然能夠獲取到。
Caniuse.com的結論是Web Storage有良好的瀏覽器支持。
Web Storage瀏覽器支持表
瀏覽器 | 版本 |
---|---|
Internet Explorer | IE8及IE8以上 |
Mozilla Firefox | Firefox 3.5及以上 |
Google Chrome | Chrome 4及以上 |
Apple Safari | Safari 4及以上 |
Opera | Opera 11.5及以上 |
目前,Web Storage標準是W3C Candidate Recommendation.總共有五個級別的推薦。"Candidate Recommendation"是這五個級別中的第三個級別。目前的Web Storage已經至關成熟由於這已經不是一個工做草案啦,可是與此同時,這個也不是最終的方案。
支持舊的沒有Web Storage這個特性的瀏覽器能夠經過使用polyfill來支持。對於localStorage的支持能夠選擇Store.js。
Web Storage和cookies有同樣的禁止跨域的策略。這意味着一個網站的Web Storage不能被其餘網站訪問。這對於數據安全來講是有益的。可是這也致使了咱們在須要子域的時候出現問題。對於這個問題,有其餘的解決方案,好比由Zendesk開發的一個開源包Cross-Storage。
就像任何其餘的客戶端數據存儲機制同樣,保護存儲的數據也是一個很重要的須要考慮的點。保存用戶私密或者敏感的數據是不推薦的。這也讓可以接觸設備的人更方便的獲取到本地數據。尤爲是在一些其餘人能夠用公共的網絡環境好比大學,圖書館,工做電腦等訪問你的網站的地方更應該格外當心。
數據完備性也是一個考慮因素。必需要有在存儲事務失敗的時候的解決方案。當用戶的Web Storage被關閉時候,或者當用戶的存儲空間不足的時候,或者超過瀏覽器的Web Storage限制的時候都有可能形成失敗。Web Storage規範說明了當觸發存儲失敗事件的標準的錯誤/警告輸出,好比QuotaExceededError異常。
對於客戶端存儲來講,Indexed Database API(IndexedDB)提供了不少能夠從Web Storage衍生出來的相同的有點。可是IndexedDB不是Web Storage規範的一部分因此這也超出了咱們所要討論的範圍。
可是。IndexedDB也很值得咱們簡單的聊一下,由於它和Web Storage實現有不少共享的特色以及將來可能有聯繫的可能。
經過IndexedDB存儲數據相對於Web Storage來講可能會更加複雜一些。可是,它也打開了通往更加複雜數據結構和關係的大門。
經過IndexedDB,數據會像你喜歡的客戶端數據管理系統好比MYSQL
,MSSQL
,PostgreSQL
等等數據庫同樣經過索引存儲起來。(相關:最好的五中數據庫管理工具)
除此以外,若是你實現了一個能夠處理IndexedDB數據庫的查詢語言,你也能夠想服務端數據庫同樣檢索數據庫。
相對於IndexedDB來講,Web Storage的數據獲取能力是很基礎的。Web Storage只有兩個內置的獲取數據的方法:.getItem
和.key
。(除了可以能夠獲取Web Storage對象的length
屬性)。所以,當你考慮到須要更加複雜的數據存儲的時候,你能夠考慮IndexedDB而不是Web Storage。