四种有能力取代Cookies的客户端Web存储方案
- 2013-10-22 09:19:59 | 新闻来源：叶凡网络 | 点击量：690
浏览器数据存储领域拥有多种不同方式可供选择，外地浏览器存储在过去几年中迎来了一轮重大变革。不同API及推荐项目所使用的多种多样而且相互相近的名称让我很难弄清哪些可以继续使用、而哪些应该及时淘汰。总而言之。而且每一种都有非常充分的存在价值。
每一种规范都拥有自己的优势、短板、独特的W3C规范化状态以及浏览器支持级别。但无论如何，目前在用户的网络浏览器中保存大量数据需要遵循几大现有标准。这些规范的实际表示都优于广泛存在cooki机制。
甚至可能需要以脱机方式完成任务。可以说，今天的Web应用顺序开始在客户端中执行大量数据处置工作。客户端数据存储对于下一代Web应用顺序的发展起到至关重要的作用。
则只有两种方式可供选择：要么再次向服务器发送请求以获取数据，然而直到现在cooki仍然是用户浏览器中最常见的数据存储机制。如果一款Web应用需要重复访问某些数据。要么读取保管在cooki中的内容。
cooki机制只能提供有限的存储空间—最多4K或者4096字节—因此总量较大的数据会被拆分成4K大小的块从而加以明确而直接地管理。
因此我需要拿出一套新的替代性方案。但这种方式对于存储的协作及管理而言显然并不可行。
cooki接受能力太过孱弱
第一款网景浏览器呈现了满足了用户的一系列实际需求，网络浏览器最初只是通过HTTP并解析HTML实现应用顺序对文档内容的加载。但在尔后不久。但却需要利用实质上无状态的HTTP协议来通过某些机制实现状态追踪。面对这一问题，LouMontulli于1994年创造了浏览器cooki当初被称为‘magiccooki并首次亮相于Mosiac网景浏览器0.9b版本之上。
最早的Web应用顺序终于变成现实。最终，通用网关接口（简称CGI提供的服务器端脚本访问功能与cooki共同辅助下。开始沿着这条小路将浏览器转化成为一种通用的应用顺序平台。
而且很容易受到各类攻击活动的影响，然而cooki机制存在着严重缺陷。正如前面所提到只能存储极少量数据。这样的状况让我很难利用其存储个人信息及敏感数据、从而极大限制了使用范围。
cooki会介入到从浏览器发向服务器端的每一条HTTP请求当中。假设一个网页中包含的四张图片、一个外部CSS文档外加JavaScript文档。系统会为该域设置一个4Kcooki浏览器则分四次将该cooki转发至服务器端—一次针对HTML页面、一次针对每张图片、一次针对CSS文档再加上一次针对JavaScript文档。
这个理论上为4K大小的cooki需要从浏览器端传输至服务器端；由于大部分用户使用的异步互联网连接，令问题进一步复杂化的原因在于。即上传速度低于下载速度，因此在HTTP响应头中传输cooki数据一定会造成不必要的带宽占用。
图片、CSS以及JavaScript等来自独特域的静态文件应该禁用cooki机制。由于上述限制因素的存在大部分cooki体积都要远小于4K谷歌建议每个cooki实际大小不要超越400字节（或者200个字符）从而实现最佳性能表示。还建议称。
目前已经出现一系列新兴方案，由于cooki机制在外地存储领域存在诸多问题。旨在拨乱反正、保质保量完成任务。近几个月以来，已经有两款方案走上正轨、得到W3C强烈推荐—能够很好、甚至比我预想中更好地协助浏览器支持外地存储功能。
分别是WebSQLIndexedDBWebStorag以及ApplicatCach下面我就逐一对每套方案加以评述，目前我可以从四种主流客户端数据存储机制中做出选择。并探讨它运作及效果方面的各自特性。
WebSQL:擅长（但是否有些过时？数据库创建与执行
SafariChrome以及Opera等知名浏览器纷纷在WebSQL与IndexedDB竞争之中选择了前者。不过2010年时，WebSQL一种利用数据库进行数据存储并利用SQL处置检索任务的API最近。SQLite还是惟一一款能够与WebSQL协作的数据库，而W3C出于装置基础较小的理由而停止对这套方案进行支持。
下面我就一起来看示例代码。WebSQL工作机制相当新奇。
那么完全可以直接开始使用，WebSQL数据库的使用感受与关系类数据库及SQL非常相似。使用这款数据库的第一步在于创建并打开。如果大家不希望额外创建一套数据库。API自身会自动完成创建工作。
下面我来看一局部用于数据库创立的代码：
var db = openDatabas'cats', '1.0',
- 'a catalog of my cats', 2 *1024 * 1024;
openDatabas后面的参数依次代表着数据库名称、版本号、文字说明以及预计数据库大小。依照从左到右的顺序。
大家就可以着手使用了WebSQL数据库上执行SQL与创建事务对象并加以执行一样简单：数据库创建完成之后。
db.transactfunction tx {- tx.executeSql'CREA TE TA BLE cats id unique, nam'; tx.executeSql'INSERT INTO cats id,nam VA LUES 1,"Mr. Jones"';
- };
因此它不太可能成为外地存储的新型规范。尽管SafariChromeOpera以及MobilSafari都支持这款API但自2010年以来WebSQL就没有发生过任何变化。
WebStorage:取cooki所长、去cooki所短
WebStorag利用一种简单的方法在用户的浏览器中存储键/值对。但它与cooki之间的相似之处也就仅此而已了
除非被应用顺序或用户明确删除。?WebStorag一套耐久性方案。一旦某个值被存储之后就不会再消失或者终止。
?WebStorag能够处置大量数据。目前浏览器的总体存储区域大小最高为5MB
而且不必向服务器端发送数据。当然，?WebStorag无需依赖于服务器。大家可以随意实现外地化数据存储并将其与服务器进行异步式同步，但WebStorag表示始终逊色而且在离线与在线状况下都能正常生效。
?WebStorag提供四种主要方法—getItem键）setItem键、值）removeItem键）以及clear
WebStorag包括两种完全不同的存储类型：SessionStorag以及LocalStorag最后。
当大家使用电子商务类应用顺序时，SessionStorag作用在于保证被保存在当前浏览器窗口当中的数据仅作用于该窗口。举例来说。利用SessionStorag来记录用户的购物车信息能够防止误操作所带来的二次购买状况。
如果大家在Chrome当中打开了三个关于同一网站的窗口，下面再来看LocalStorag专门负责保管可同时作用于同一浏览器之下各窗口及标签之间的数据。因此。那么三者能够共同使用同一套LocalStorag容器。相比之下，如果我打开三个内容相互独立的网站窗口，那么每一个都将使用相互独立的容器。同样，如果大家在不同的浏览器当中打开同一个网站，那么每种浏览器都需要使用属于自己的容器，因此无法共享同一套通用的运行环境。
大家可以使用下列JavaScript命令：要设置一套新的键-值对并进行检索。
//first set firstname equal to Sparky.- localStorage.setItem "firstname", "Sparky" ;
- //next, get the value of firstname hint, it will be Sparki. localStorage.getItem "firstname" ;
WebStoragAPI正式获得W3C推荐规范这一殊荣。展望未来，今年夏天。WebStorag完全有可能在一切原本cooki发挥作用的舞台上成为新的处置方案。
WebStorag还提供另一种可能是最为简便的处置方法—甚至比cooki更简便—从而顺利搞定浏览器中键-值对的设置与检索工作。但WebStorag能做的还很多。如果大家的数据集并不太大。
IndexedDB可搜索且不存在文件大小限制
这方面采用简单键-值对存储机制的cooki以及WebStorag都只能甘拜下风。IndexDatabas一款利用索引化事务性数据库对用户计算机上的数据进行保管与索引的APIIndexedDB带来更快速、更精妙的数据存储与检索效果。
IndexedDBAPI今年夏天（也就是2013年7月）向Web规范迈进了一大步，与WebStorag一样。成为W3C候选推荐名单中的一员。
IndexedDB带来四项具体提升：与WebStorag相比。
- 能够对索引数据进行高效搜索。
- 数据库能够将多个值保管为一个键，而键-值机制则要求每个键都必须惟一。
- 事务型数据库提供多项针对系统及应用顺序故障的维护措施。如果事务流程未能正常完成，则将通过回滚方式进行恢复。
- IndexedDB数据库对数据内容的大小不加限制。火狐当中，浏览器会要求利用权限将数据库的容量提升到超越50MB而IndexedDB实际数据存储量限制直接取决于分卷或者磁盘驱动器自身的容量极限。
除了Safari之外的所有主流浏览器都已经支持IndexedDB不过由于Safari支持WebSQL因此我完全可以利用IndexedDB夹层（或者被称为shim通过WebSQL实现IndexedDB功能与语法。
要使用IndexedDB第一步需要打开一套数据库。
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" }
- ];
可以创建数据存储机制并通过下列代码加以使用。请注意onupgradeneed处置方式：改变数据库结构时需要用到这一方法。接下来。
request.onupgradeneeded = functionevent {- var db = event.target.result; var objectStore = db.createObjectStor"customers", {keyPath: "id"};
- for var i in customerData { objectStore.addcustomerData[i];
- } }
并能够通过将结构化数据移动至客户端来提高Web应用顺序的性能表示。目前它已经非常接近W3C推荐级别，IndexedDB擅长于搜索大型数据库集。而且能够被用于全部浏览器平台—尽管具体实施方式有所区别，如前文所述，Safari中需要借用夹层机制。
A pplicatCache:让离线客户端存储成为现实
但它同样值得关注，A pplicatCach与前面提到其它客户端数据存储APi都不一样。因为它已经成为离线客户端Web应用顺序的重要组成局部。
只是一个非常简单的文本文档，A pplicatCach使用的一套缓存列表。所谓列表。其中列举了所有应该或不应该通过缓存机制处理的资源条目，从而指导浏览器下载特定文件、加以保管并在必要时予以使用—而不必再向服务器发出重复请求。目前所有主流网络浏览器都支持ApplicatCach机制。
可能需要为.appcach文件创建一个自定义MIME类型以确保它能够正确作用于浏览器并可被作为应用顺序缓存文件读取。要使用ApplicatCach需要首先在包括有缓存对象文件的网站中保存一个扩展名为为.appcach文本文件。根据所使用Web服务器的具体类型。
下面我列举一个缓存列表文件作为范例：
CA CHE MA NIFEST- CA CHE:
- /css/styles.css /js/javascript.css
- /img/logo.gif
- FA LLBA CK: /img/weathertoday.png /img/weathernotavailable.png
- NETWORK:
现在来详细解读其中的内容：
- CA CHE局部用于告知浏览器哪些资源需要进入缓存以实现离线查看。这些文件会一直保管于缓存当中中，直到缓存列表发生变化。请记住这项要求，非常重要。
- FA LLBA CK局部则用于告知浏览器哪些要显示的文件会取代非缓存资源。举例来说，上面的FA LLBA CK局部中，可以推测如果latestweather.png图片无法被正确下载，那么当前天气状况无法在离线状态下实现图片显示。
- NETWORK局部用于告知浏览器哪些资源只能通过在线模式进行获取。结尾局部的星号表示目前缓存中不存在任何一种网络资源。
只要使用得当、几乎没有什么缺点。其实正确使用是一门学问：如果大家单纯把网站上的所有内容都添加到缓存当中，A pplicatCach一款出色的工具。那么访问者们会很快发现网站内容永远不会发生变化。如果大家只把变化频率不高的内容保管在缓存当中，或者努力保证缓存列表始终处于最新并在上传文件后及时发布新的列表版本，那么ApplicatCach将带来几乎与在线模式无异的逊色离线应用顺序运行效果。
上一篇：美国内华达州一初中生校园开枪 致师生2死2伤
下一篇：中俄总理会晤公报：反对颠覆别国合法政权
- 'a catalog of my cats', 2 *1024 * 1024;