四種有能力取代Cookies的客戶端Web存儲方案

目前在用戶的網絡瀏覽器中保存大量數據須要遵循幾大現有標準，每一種標準都擁有本身的優點、短板、獨特的W3C標準化狀態以及瀏覽器支持級別。但不管如何，這些標準的實際表現都優於普遍存在的cookies機制。

今天的Web應用程序開始在客戶端中執行大量數據處理工做，甚至可能須要以脫機方式完成任務。能夠說，客戶端數據存儲對於下一代Web應用程序的發展起到了相當重要的做用。

然而直到如今，cookies仍然是用戶瀏覽器中最多見的數據存儲機制。若是一款Web應用須要重複訪問某些數據，則只有兩種方式可供選擇：要麼再次向服務器發送請求以獲取數據，要麼讀取保存在cookies中的內容。

cookies機制只能提供有限的存儲空間——最多4K或者4096字節——所以總量較大的數據會被拆分紅4K大小的塊從而加以明確而直接地管理。

但這種方式對於存儲的協做及管理而言顯然並不可行，所以咱們須要拿出一套新的替代性方案。

cookies的承受能力太過孱弱

網絡瀏覽器最初只是經過HTTP並解析HTML實現應用程序對文檔內容的加載。但在此後不久，第一款網景瀏覽器出現了，它知足了用戶的一系列實際需求，但卻須要利用本質上無狀態的HTTP協議來經過某些機制實現狀態追蹤。面對這一問題，Lou Montulli於1994年創造了瀏覽器cookie（當初被稱爲‘magic cookie’），並首次亮相於Mosiac網景瀏覽器0.9b版本之上。

在通用網關接口（簡稱CGI）提供的服務器端腳本訪問功能與cookies的共同輔助下，最先的Web應用程序終於變成現實。最終，咱們開始沿着這條小路將瀏覽器轉化成爲一種通用的應用程序平臺。

然而cookies機制存在着嚴重缺陷。正如前面所提到，它只能存儲極少許數據，並且很容易受到各種攻擊活動的影響，這樣的情況讓咱們很難利用其存儲我的信息及敏感數據、從而極大限制了它的使用範圍。

cookies會介入到從瀏覽器發向服務器端的每一條HTTP請求當中。假設一個網頁中包含的四張圖片、一個外部CSS文檔外加JavaScript文檔。系統會爲該域設置一個4K的cookie，瀏覽器則分四次將該cookie轉發至服務器端——一次針對HTML頁面、一次針對每張圖片、一次針對CSS文檔再加上一次針對JavaScript文檔。

令問題進一步複雜化的緣由在於，這個理論上爲4K大小的cookie須要從瀏覽器端傳輸至服務器端；因爲大部分用戶使用的是異步互聯網鏈接，即上傳速度低於下載速度，所以在HTTP響應頭中傳輸cookie數據必定會形成沒必要要的帶寬佔用。

因爲上述限制因素的存在，大部分cookies的體積都要遠小於4K。谷歌建議每一個cookie的實際大小不要超過400字節（或者200個字符），從而實現最佳性能表現。他們還建議稱，在圖片、CSS以及JavaScript等來自獨特域的靜態文件應該禁用cookies機制。

因爲cookies機制在本地存儲領域存在諸多問題，目前已經出現一系列新興方案，旨在撥亂反正、保質保量完成任務。近幾個月以來，已經有兩款方案走上正軌、獲得W3C的強烈推薦——它們可以很好、甚至比咱們預想中更好地幫助瀏覽器支持本地存儲功能。

目前咱們能夠從四種主流客戶端數據存儲機制中作出選擇，它們分別是：Web SQL、IndexedDB、Web Storage以及Application Cache。下面咱們就逐一對每套方案加以評述，並探討它們在運做及效果方面的各自特性。

Web SQL: 擅長（可是否有些過期？）數據庫建立與執行

Web SQL是一種利用數據庫進行數據存儲並利用SQL處理檢索任務的API。最近，Safari、Chrome以及Opera等知名瀏覽器紛紛在Web SQL與IndexedDB的競爭之中選擇了前者。不過2010年時，SQLite仍是唯一一款可以與Web SQL協做的數據庫，而W3C出於安裝基礎較小的理由而中止對這套方案進行支持。

Web SQL的工做機制至關新奇，下面咱們就一塊兒來看示例代碼。

Web SQL數據庫的使用感覺與關係類數據庫及SQL很是類似。使用這款數據庫的第一步在於建立並打開。若是你們不但願額外建立一套數據庫，那麼徹底能夠直接開始使用，API自己會自動完成建立工做。

下面咱們來看一部分用於數據庫建立的代碼：

1. var db = openDatabase('cats', '1.0', 

• 'a catalog of my cats'

, 2 *1024 * 1024); 

按照從左到右的順序，openDatabase後面的參數依次表明着數據庫名稱、版本號、文字說明以及預計數據庫大小。

數據庫建立完成以後，你們就能夠着手使用了。在WebSQL數據庫上執行SQL與建立事務對象並加以執行同樣簡單：

1. db.transaction(

function

 (tx) { 

• tx.executeSql('CREATE TABLE cats (id unique, name)'

); 

• tx.executeSql('INSERT INTO cats (id,name) VALUES (1,"Mr. Jones")'

); 

• }); 

儘管Safari、Chrome、Opera以及Mobile Safari都支持這款API，但自2010年以來Web SQL就沒有發生過任何變化，所以它不太可能成爲本地存儲的新型標準。

Web Storage: 取cookies所長、去cookies所短

Web Storage利用一種簡單的方法在用戶的瀏覽器中存儲鍵/值對。但它與cookies之間的類似之處也就僅此而已了。

•Web Storage是一套持久性方案。一旦某個值被存儲以後就不會再消失或者終止，除非被應用程序或用戶明確刪除。

•Web Storage可以處理大量數據。目前瀏覽器的整體存儲區域大小最高爲5MB。

•Web Storage無需依賴於服務器，並且沒必要向服務器端發送數據。固然，你們能夠隨意實現本地化數據存儲並將其與服務器進行異步式同步，但Web Storage的表現始終出色並且在離線與在線情況下都能正常生效。

•Web Storage提供四種主要方法——getItem（鍵）；setItem（鍵、值）；removeItem（鍵）以及clear（）。

最後，Web Storage包含兩種徹底不一樣的存儲類型：SessionStorage以及LocalStorage。

SessionStorage的做用在於保證被保存在當前瀏覽器窗口當中的數據僅做用於該窗口。舉例來講，當你們使用電子商務類應用程序時，利用SessionStorage來記錄用戶的購物車信息可以避免誤操做所帶來的二次購買情況。

下面再來看LocalStorage，它專門負責保存可同時做用於同一瀏覽器之下各窗口及標籤之間的數據。所以，若是你們在Chrome當中打開了三個關於同一網站的窗口，那麼三者可以共同使用同一套LocalStorage容器。相比之下，若是咱們打開三個內容彼此獨立的網站窗口，那麼每個都將使用彼此獨立的容器。一樣，若是你們在不一樣的瀏覽器當中打開同一個網站，那麼每種瀏覽器都須要使用屬於本身的容器，所以沒法共享同一套通用的運行環境。

要設置一套新的鍵-值對並進行檢索，你們可使用下列JavaScript命令：

1. //first set firstname equal to Sparky. 

• localStorage.setItem( "firstname"

, 

"Sparky"

 ); 

•  
• //next, get the value of firstname (hint, it will be Sparky).

 

• localStorage.getItem( "firstname"

 ); 

今年夏天，Web Storage API正式得到W3C推薦標準這一殊榮。展望將來，Web Storage徹底有可能在一切本來cookies發揮做用的舞臺上成爲新的處理方案。

但Web Storage能作的還不少。若是你們的數據集並不太大，Web Storage還提供另外一種多是最爲簡便的處理辦法——甚至比cookies更簡便——從而順利搞定瀏覽器中鍵-值對的設置與檢索工做。

IndexedDB：可搜索且不存在文件大小限制

Indexed Database是一款利用索引化事務性數據庫對用戶計算機上的數據進行保存與索引的API。IndexedDB帶來更快速、更精妙的數據存儲與檢索效果，在這方面採用簡單鍵-值對存儲機制的cookies以及Web Storage都只能甘拜下風。

與Web Storage同樣，IndexedDB API在今年夏天（也就是2013年7月）向Web標準邁進了一大步，成爲W3C候選推薦名單中的一員。

與Web Storage相比，IndexedDB帶來四項具體提高：

1. 可以對索引數據進行高效搜索。

• 數據庫可以將多個值保存爲一個鍵，而鍵-值機制則要求每一個鍵都必須唯一。
• 事務型數據庫提供多項針對系統及應用程序故障的保護措施。若是事務流程未能正常完成，則將經過回滾方式進行恢復。
•  IndexedDB數據庫對數據內容的大小不加限制。在火狐當中，瀏覽器會要求利用權限將數據庫的容量提高到超過50MB，而IndexedDB的實際數據存儲量限制直接取決於分卷或者磁盤驅動器自己的容量極限。

除了Safari以外的全部主流瀏覽器都已經支持IndexedDB。不過因爲Safari支持Web SQL，所以咱們徹底能夠利用IndexedDB夾層（或者被稱爲shim）經過Web SQL實現IndexedDB的功能與語法。

要使用IndexedDB，第一步須要打開一套數據庫。

1. var

 request = indexedDB.open(

"myDatabase"

); 

在數據庫建立完成以後，你們能夠建立一個存儲對象（與表格很是相似）並向其中添加數據。假設咱們須要向其中添加以下數據：

 

• const petData = [ 

• { id: "00-01"

, firstname: 

"Butters"

, age: 2, type: 

"dog"

 }, 

• { id: "00-02"

, firstname: 

"Sammy"

, age: 2, type: 

"dog"

 } 

• ]; 

接下來，咱們能夠建立數據存儲機制並經過下列代碼加以使用。請注意onupgradeneeded的處理方式：咱們在改變數據庫結構時須要用到這一方法。

1. request.onupgradeneeded = 

function

(event) { 

• var

 db = event.target.result; 

• var

 objectStore = db.createObjectStore(

"customers"

, {keyPath: 

"id"

}); 

• for

 (

var

 i 

in

 customerData) { 

• objectStore.add(customerData[i]); 
• } 
• } 

IndexedDB擅長於搜索大型數據庫集，並可以經過將結構化數據移動至客戶端來提升Web應用程序的性能表現。目前它已經很是接近W3C的推薦級別，並且可以被用於所有瀏覽器平臺——儘管具體實施方式有所區別，如前文所述，在Safari中須要借用夾層機制。

Application Cache: 讓離線客戶端存儲成爲現實

Application Cache與前面提到的其它客戶端數據存儲APi都不同，但它一樣值得關注，由於它已經成爲離線客戶端Web應用程序的重要組成部分。

Application Cache使用的是一套緩存列表。所謂列表，只是一個很是簡單的文本文檔，其中列舉了全部應該或不該該經過緩存機制處理的資源條目，從而指導瀏覽器下載特定文件、加以保存並在必要時予以使用——而沒必要再向服務器發出重複請求。目前全部主流網絡瀏覽器都支持Application Cache機制。

要使用Application Cache，咱們須要首先在包含有緩存對象文件的網站中保存一個擴展名爲爲.appcache的文本文件。根據所使用Web服務器的具體類型，咱們可能須要爲.appcache文件建立一個自定義MIME類型以確保它們可以正確做用於瀏覽器並可被做爲應用程序緩存文件讀取。

下面咱們列舉一個緩存列表文件做爲範例：

1. CACHE MANIFEST 

•  
• CACHE: 
• /css/styles.css 
• /js/javascript.css 
• /img/logo.gif 
•  
• FALLBACK: 
• /img/weathertoday.png /img/weathernotavailable.png 
•  
• NETWORK: 

如今咱們來詳細解讀其中的內容：

• CACHE部分用於告知瀏覽器哪些資源須要進入緩存以實現離線查看。這些文件會一直保留於緩存當中中，直到緩存列表發生變化。請記住這項要求，很是重要。

• FALLBACK部分則用於告知瀏覽器哪些要顯示的文件會取代非緩存資源。舉例來講，在上面的FALLBACK部分中，咱們能夠推測若是latestweather.png圖片沒法被正確下載，那麼當前天氣情況沒法在離線狀態下實現圖片顯示。
• NETWORK部分用於告知瀏覽器哪些資源只能經過在線模式進行獲取。結尾部分的星號表示目前緩存中不存在任何一種網絡資源。

Application Cache是一款出色的工具，只要使用得當、它幾乎沒有什麼缺點。其實正確使用是一門學問：若是你們單純把網站上的全部內容都添加到緩存當中，那麼訪問者們會很快發現網站內容永遠不會發生變化。若是你們只把變化頻率不高的內容保存在緩存當中，或者努力保證緩存列表始終處於最新並在上傳文件後及時發佈新的列表版本，那麼Application Cache將帶來幾乎與在線模式無異的出色離線應用程序運行效果。

本地瀏覽器存儲在過去幾年中迎來了一輪重大變革。不一樣API及推薦項目所使用的多種多樣並且彼此相近的名稱讓咱們很難弄清哪些能夠繼續使用、而哪些應該及時淘汰。總而言之，瀏覽器數據存儲領域擁有多種不一樣方式可供選擇，並且每一種都有很是充分的存在價值。

不管如何，開發人員們努力經過cookies向服務器發送簡單的小型名-值對的時代已經結束。今天，咱們擁有更多優秀的方案可供使用。