四种有能力取代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向服务器发送简单的小型名-值对的时代已经结束。今天，咱们拥有更多优秀的方案可供使用。