目前在用戶的網(wǎng)絡(luò)瀏覽器中保存大量數(shù)據(jù)需要遵循幾大現(xiàn)有標(biāo)準(zhǔn)，每一種標(biāo)準(zhǔn)都擁有自己的優(yōu)勢、短板、獨(dú)特的W3C標(biāo)準(zhǔn)化狀態(tài)以及瀏覽器支持級別。但無論如何，這些標(biāo)準(zhǔn)的實(shí)際表現(xiàn)都優(yōu)于廣泛存在的cookies機(jī)制。

今天的Web應(yīng)用程序開始在客戶端中執(zhí)行大量數(shù)據(jù)處理工作，甚至可能需要以脫機(jī)方式完成任務(wù)?？梢哉f，客戶端數(shù)據(jù)存儲對于下一代Web應(yīng)用程序的發(fā)展起到了至關(guān)重要的作用。

然而直到現(xiàn)在，cookies仍然是用戶瀏覽器中最常見的數(shù)據(jù)存儲機(jī)制。如果一款Web應(yīng)用需要重復(fù)訪問某些數(shù)據(jù)，則只有兩種方式可供選擇：要么再次向服務(wù)器發(fā)送請求以獲取數(shù)據(jù)，要么讀取保存在cookies中的內(nèi)容。

cookies機(jī)制只能提供有限的存儲空間——最多4K或者4096字節(jié)——因此總量較大的數(shù)據(jù)會被拆分成4K大小的塊從而加以明確而直接地管理。

但這種方式對于存儲的協(xié)作及管理而言顯然并不可行，因此我們需要拿出一套新的替代性方案。

cookies的承受能力太過孱弱

網(wǎng)絡(luò)瀏覽器最初只是通過HTTP并解析HTML實(shí)現(xiàn)應(yīng)用程序?qū)ξ臋n內(nèi)容的加載。但在此后不久，第一款網(wǎng)景瀏覽器出現(xiàn)了，它滿足了用戶的一系列實(shí)際需求，但卻需要利用本質(zhì)上無狀態(tài)的HTTP協(xié)議來通過某些機(jī)制實(shí)現(xiàn)狀態(tài)追蹤。面對這一問題，Lou Montulli于1994年創(chuàng)造了瀏覽器cookie（當(dāng)初被稱為‘magic cookie’），并首次亮相于Mosiac網(wǎng)景瀏覽器0.9b版本之上。

在通用網(wǎng)關(guān)接口（簡稱CGI）提供的服務(wù)器端腳本訪問功能與cookies的共同輔助下，最早的Web應(yīng)用程序終于變成現(xiàn)實(shí)。最終，我們開始沿著這條小路將瀏覽器轉(zhuǎn)化成為一種通用的應(yīng)用程序平臺。

然而cookies機(jī)制存在著嚴(yán)重缺陷。正如前面所提到，它只能存儲極少量數(shù)據(jù)，而且很容易受到各類攻擊活動的影響，這樣的狀況讓我們很難利用其存儲個人信息及敏感數(shù)據(jù)、從而極大限制了它的使用范圍。

cookies會介入到從瀏覽器發(fā)向服務(wù)器端的每一條HTTP請求當(dāng)中。假設(shè)一個網(wǎng)頁中包含的四張圖片、一個外部CSS文檔外加JavaScript文檔。系統(tǒng)會為該域設(shè)置一個4K的cookie，瀏覽器則分四次將該cookie轉(zhuǎn)發(fā)至服務(wù)器端——一次針對HTML頁面、一次針對每張圖片、一次針對CSS文檔再加上一次針對JavaScript文檔。

令問題進(jìn)一步復(fù)雜化的原因在于，這個理論上為4K大小的cookie需要從瀏覽器端傳輸至服務(wù)器端；由于大部分用戶使用的是異步互聯(lián)網(wǎng)連接，即上傳速度低于下載速度，因此在HTTP響應(yīng)頭中傳輸cookie數(shù)據(jù)一定會造成不必要的帶寬占用。

由于上述限制因素的存在，大部分cookies的體積都要遠(yuǎn)小于4K。谷歌建議每個cookie的實(shí)際大小不要超過400字節(jié)（或者200個字符），從而實(shí)現(xiàn)最佳性能表現(xiàn)。他們還建議稱，在圖片、CSS以及JavaScript等來自獨(dú)特域的靜態(tài)文件應(yīng)該禁用cookies機(jī)制。

由于cookies機(jī)制在本地存儲領(lǐng)域存在諸多問題，目前已經(jīng)出現(xiàn)一系列新興方案，旨在撥亂反正、保質(zhì)保量完成任務(wù)。近幾個月以來，已經(jīng)有兩款方案走上正軌、得到W3C的強(qiáng)烈推薦——它們能夠很好、甚至比我們預(yù)想中更好地幫助瀏覽器支持本地存儲功能。

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

Web SQL: 擅長（但是否有些過時？）數(shù)據(jù)庫創(chuàng)建與執(zhí)行

Web SQL是一種利用數(shù)據(jù)庫進(jìn)行數(shù)據(jù)存儲并利用SQL處理檢索任務(wù)的API。最近，Safari、Chrome以及Opera等知名瀏覽器紛紛在Web SQL與IndexedDB的競爭之中選擇了前者。不過2010年時，SQLite還是惟一一款能夠與Web SQL協(xié)作的數(shù)據(jù)庫，而W3C出于安裝基礎(chǔ)較小的理由而停止對這套方案進(jìn)行支持。

Web SQL的工作機(jī)制相當(dāng)新奇，下面我們就一起來看示例代碼。

Web SQL數(shù)據(jù)庫的使用感受與關(guān)系類數(shù)據(jù)庫及SQL非常相似。使用這款數(shù)據(jù)庫的第一步在于創(chuàng)建并打開。如果大家不希望額外創(chuàng)建一套數(shù)據(jù)庫，那么完全可以直接開始使用，API本身會自動完成創(chuàng)建工作。

下面我們來看一部分用于數(shù)據(jù)庫創(chuàng)建的代碼：

var db = openDatabase('cats', '1.0', 
'a catalog of my cats', 2 *1024 * 1024); 

按照從左到右的順序，openDatabase后面的參數(shù)依次代表著數(shù)據(jù)庫名稱、版本號、文字說明以及預(yù)計(jì)數(shù)據(jù)庫大小。

數(shù)據(jù)庫創(chuàng)建完成之后，大家就可以著手使用了。在WebSQL數(shù)據(jù)庫上執(zhí)行SQL與創(chuàng)建事務(wù)對象并加以執(zhí)行一樣簡單：

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都支持這款A(yù)PI，但自2010年以來Web SQL就沒有發(fā)生過任何變化，因此它不太可能成為本地存儲的新型標(biāo)準(zhǔn)。

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

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

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

• Web Storage能夠處理大量數(shù)據(jù)。目前瀏覽器的總體存儲區(qū)域大小最高為5MB。

• Web Storage無需依賴于服務(wù)器，而且不必向服務(wù)器端發(fā)送數(shù)據(jù)。當(dāng)然，大家可以隨意實(shí)現(xiàn)本地化數(shù)據(jù)存儲并將其與服務(wù)器進(jìn)行異步式同步，但Web Storage的表現(xiàn)始終出色而且在離線與在線狀況下都能正常生效。

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

最后，Web Storage包含兩種完全不同的存儲類型：SessionStorage以及LocalStorage。

SessionStorage的作用在于保證被保存在當(dāng)前瀏覽器窗口當(dāng)中的數(shù)據(jù)僅作用于該窗口。舉例來說，當(dāng)大家使用電子商務(wù)類應(yīng)用程序時，利用SessionStorage來記錄用戶的購物車信息能夠避免誤操作所帶來的二次購買狀況。

下面再來看LocalStorage，它專門負(fù)責(zé)保存可同時作用于同一瀏覽器之下各窗口及標(biāo)簽之間的數(shù)據(jù)。因此，如果大家在Chrome當(dāng)中打開了三個關(guān)于同一網(wǎng)站的窗口，那么三者能夠共同使用同一套LocalStorage容器。相比之下，如果我們打開三個內(nèi)容彼此獨(dú)立的網(wǎng)站窗口，那么每一個都將使用彼此獨(dú)立的容器。同樣，如果大家在不同的瀏覽器當(dāng)中打開同一個網(wǎng)站，那么每種瀏覽器都需要使用屬于自己的容器，因此無法共享同一套通用的運(yùn)行環(huán)境。

要設(shè)置一套新的鍵-值對并進(jìn)行檢索，大家可以使用下列JavaScript命令：

//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推薦標(biāo)準(zhǔn)這一殊榮。展望未來，Web Storage完全有可能在一切原本cookies發(fā)揮作用的舞臺上成為新的處理方案。

但Web Storage能做的還很多。如果大家的數(shù)據(jù)集并不太大，Web Storage還提供另一種可能是最為簡便的處理辦法——甚至比cookies更簡便——從而順利搞定瀏覽器中鍵-值對的設(shè)置與檢索工作。

#p#

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

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

與Web Storage一樣，IndexedDB API在今年夏天（也就是2013年7月）向Web標(biāo)準(zhǔn)邁進(jìn)了一大步，成為W3C候選推薦名單中的一員。

與Web Storage相比，IndexedDB帶來四項(xiàng)具體提升：

1. 能夠?qū)λ饕龜?shù)據(jù)進(jìn)行高效搜索。
2. 數(shù)據(jù)庫能夠?qū)⒍鄠€值保存為一個鍵，而鍵-值機(jī)制則要求每個鍵都必須惟一。
3. 事務(wù)型數(shù)據(jù)庫提供多項(xiàng)針對系統(tǒng)及應(yīng)用程序故障的保護(hù)措施。如果事務(wù)流程未能正常完成，則將通過回滾方式進(jìn)行恢復(fù)。
4.  IndexedDB數(shù)據(jù)庫對數(shù)據(jù)內(nèi)容的大小不加限制。在火狐當(dāng)中，瀏覽器會要求利用權(quán)限將數(shù)據(jù)庫的容量提升到超過50MB，而IndexedDB的實(shí)際數(shù)據(jù)存儲量限制直接取決于分卷或者磁盤驅(qū)動器本身的容量極限。

除了Safari之外的所有主流瀏覽器都已經(jīng)支持IndexedDB。不過由于Safari支持Web SQL，因此我們完全可以利用IndexedDB夾層（或者被稱為shim）通過Web SQL實(shí)現(xiàn)IndexedDB的功能與語法。

要使用IndexedDB，第一步需要打開一套數(shù)據(jù)庫。

var request = indexedDB.open("myDatabase"); 

在數(shù)據(jù)庫創(chuàng)建完成之后，大家可以創(chuàng)建一個存儲對象（與表格非常類似）并向其中添加數(shù)據(jù)。假設(shè)我們需要向其中添加如下數(shù)據(jù)：

const petData = [ 
{ id: "00-01", firstname: "Butters", age: 2, type: "dog" }, 
{ id: "00-02", firstname: "Sammy", age: 2, type: "dog" } 
]; 

接下來，我們可以創(chuàng)建數(shù)據(jù)存儲機(jī)制并通過下列代碼加以使用。請注意onupgradeneeded的處理方式：我們在改變數(shù)據(jù)庫結(jié)構(gòu)時需要用到這一方法。

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擅長于搜索大型數(shù)據(jù)庫集，并能夠通過將結(jié)構(gòu)化數(shù)據(jù)移動至客戶端來提高Web應(yīng)用程序的性能表現(xiàn)。目前它已經(jīng)非常接近W3C的推薦級別，而且能夠被用于全部瀏覽器平臺——盡管具體實(shí)施方式有所區(qū)別，如前文所述，在Safari中需要借用夾層機(jī)制。

Application Cache: 讓離線客戶端存儲成為現(xiàn)實(shí)

Application Cache與前面提到的其它客戶端數(shù)據(jù)存儲APi都不一樣，但它同樣值得關(guān)注，因?yàn)樗呀?jīng)成為離線客戶端Web應(yīng)用程序的重要組成部分。

Application Cache使用的是一套緩存列表。所謂列表，只是一個非常簡單的文本文檔，其中列舉了所有應(yīng)該或不應(yīng)該通過緩存機(jī)制處理的資源條目，從而指導(dǎo)瀏覽器下載特定文件、加以保存并在必要時予以使用——而不必再向服務(wù)器發(fā)出重復(fù)請求。目前所有主流網(wǎng)絡(luò)瀏覽器都支持Application Cache機(jī)制。

要使用Application Cache，我們需要首先在包含有緩存對象文件的網(wǎng)站中保存一個擴(kuò)展名為為.appcache的文本文件。根據(jù)所使用Web服務(wù)器的具體類型，我們可能需要為.appcache文件創(chuàng)建一個自定義MIME類型以確保它們能夠正確作用于瀏覽器并可被作為應(yīng)用程序緩存文件讀取。

下面我們列舉一個緩存列表文件作為范例：

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

 現(xiàn)在我們來詳細(xì)解讀其中的內(nèi)容：

• CACHE部分用于告知瀏覽器哪些資源需要進(jìn)入緩存以實(shí)現(xiàn)離線查看。這些文件會一直保留于緩存當(dāng)中中，直到緩存列表發(fā)生變化。請記住這項(xiàng)要求，非常重要。
• FALLBACK部分則用于告知瀏覽器哪些要顯示的文件會取代非緩存資源。舉例來說，在上面的FALLBACK部分中，我們可以推測如果latestweather.png圖片無法被正確下載，那么當(dāng)前天氣狀況無法在離線狀態(tài)下實(shí)現(xiàn)圖片顯示。
• NETWORK部分用于告知瀏覽器哪些資源只能通過在線模式進(jìn)行獲取。結(jié)尾部分的星號表示目前緩存中不存在任何一種網(wǎng)絡(luò)資源。

Application Cache是一款出色的工具，只要使用得當(dāng)、它幾乎沒有什么缺點(diǎn)。其實(shí)正確使用是一門學(xué)問：如果大家單純把網(wǎng)站上的所有內(nèi)容都添加到緩存當(dāng)中，那么訪問者們會很快發(fā)現(xiàn)網(wǎng)站內(nèi)容永遠(yuǎn)不會發(fā)生變化。如果大家只把變化頻率不高的內(nèi)容保存在緩存當(dāng)中，或者努力保證緩存列表始終處于最新并在上傳文件后及時發(fā)布新的列表版本，那么Application Cache將帶來幾乎與在線模式無異的出色離線應(yīng)用程序運(yùn)行效果。

本地瀏覽器存儲在過去幾年中迎來了一輪重大變革。不同API及推薦項(xiàng)目所使用的多種多樣而且彼此相近的名稱讓我們很難弄清哪些可以繼續(xù)使用、而哪些應(yīng)該及時淘汰。總而言之，瀏覽器數(shù)據(jù)存儲領(lǐng)域擁有多種不同方式可供選擇，而且每一種都有非常充分的存在價(jià)值。

無論如何，開發(fā)人員們努力通過cookies向服務(wù)器發(fā)送簡單的小型名-值對的時代已經(jīng)結(jié)束。今天，我們擁有更多優(yōu)秀的方案可供使用。

原文鏈接：http://www.cio.com/article/739064/4_Client_Side_Web_Storage_Options_That_Replace_Cookies