[譯] Web Storage 初探

Web Storage 是相對比較新的一種可以將數據存儲在用戶電腦（客戶端）的一種方式。

Web Storage給網站/應用提供了很多好處。比如，Web Storage可以用來跨網站/應用監測用戶的行為而不需要服務端腳本和數據庫。Web Storage也能在用戶即使突然斷網的情況下保存一部分web應用的能力，讓你不會因為網絡連接的問題受到影響

Web Storage vs. Cookies

傳統的用來在客戶端保存數據的方式是通過HTTP cookies。

Web Storage和cookies之間存在著很多的區別。讓我們把注意力放在這兩種客戶端數據存儲的方法的真正的區別上。

存儲原理

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的存儲大小限制）

Storage的種類

Web Storage有兩種方式來存儲客戶端數據：sessionStorage和localStorage.

sessionStorage

sessionStorage是設計用來保存瀏覽器會話這個時間段的客戶端數據的。換句話說數據只在用戶還在網站瀏覽的時候才保存起來。

sessionStorage在實踐中主要用來暫時的數據 存儲。比如說，用戶在網頁表單上的輸入能夠在用戶瀏覽器會話的階段保存在sessionStorage對象當中。這樣的話，數據就能夠在瀏覽的整個過程中獲得到而不需要把數據存儲到服務器當中。也就是說，當用戶不小心關閉或者刷新瀏覽器窗口，暫時的數據存儲可以防止用戶不得不重復輸入數據。

localStorage

從實現的角度來說，localStorage和sessionStorage的實現方式是基本類似的。

localStorage和sessionStorage分享一套javascript方法（比如說：getItem,setItem等等），并且它也以鍵值對的方式存儲數據。

但是，把數據存儲在localStorage對象上意味著數據可以在用戶的會話之間一直保存著。換句話說，數據可以在用戶下一次訪問這個網站的時候依然可以獲取到。

Web Storage的瀏覽器支持

Caniuse.com的結論是Web Storage有良好的瀏覽器支持。

Web Storage瀏覽器支持表

目前，Web Storage標準是 W3C Candidate Recommendation .總共有五個級別的推薦。"Candidate Recommendation"是這五個級別中的第三個級別。目前的Web Storage已經相當成熟因為這已經不是一個工作草案啦，但是與此同時，這個也不是最終的方案。

支持舊的沒有Web Storage這個特性的瀏覽器可以通過使用polyfill來支持。對于localStorage的支持可以選擇 Store.js 。

數據隱私和安全考慮

Ｗeb Storage和cookies有一樣的禁止跨域的策略。這意味著一個網站的Web Storage不能被其他網站訪問。這對于數據安全來說是有益的。但是這也導致了我們在需要子域的時候出現問題。對于這個問題，有其他的解決方案，比如由 Zendesk開發的一個開源包 Cross-Storage 。

就像任何其他的客戶端數據存儲機制一樣，保護存儲的數據也是一個很重要的需要考慮的點。保存用戶私密或者敏感的數據是不推薦的。這也讓能夠接觸設備的人更方便的獲取到本地數據。尤其是在一些其他人可以用公共的網絡環境比如大學，圖書館，工作電腦等訪問你的網站的地方更應該格外小心。

數據完備性也是一個考慮因素。必須要有在存儲事務失敗的時候的解決方案。當用戶的Web Storage被關閉時候，或者當用戶的存儲空間不足的時候，或者超過瀏覽器的Web Storage限制的時候都有可能造成失敗。Web Storage規范說明了當觸發存儲失敗事件的標準的錯誤/警告輸出，比如QuotaExceededError異常。

IndexedDB怎么樣呢？

對于客戶端存儲來說， 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。