原文:Web Storage: A Primerjavascript
Web Storage是相对比较新的一种能够将数据存储在用户电脑(客户端)的一种方式。java
Web Storage给网站/应用提供了不少好处。好比,Web Storage能够用来跨网站/应用监测用户的行为而不须要服务端脚本和数据库。Web Storage也能在用户即便忽然断网的状况下保存一部分web应用的能力,让你不会由于网络链接的问题受到影响git
传统的用来在客户端保存数据的方式是经过HTTP cookies。github
Web Storage和cookies之间存在着不少的区别。让咱们把注意力放在这两种客户端数据存储的方法的真正的区别上。web
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的存储大小限制)
Web Storage有两种方式来存储客户端数据:sessionStorage和localStorage.
Web Storage | 存储数据的生命周期 | 数据结构 | 数据类型 |
---|---|---|---|
sessionStorage | 只在回话中保存 | 键值对 | 字符串 |
localStorage | 持久保存 | 键值对 | 字符串 |
sessionStorage是设计用来保存浏览器会话这个时间段的客户端数据的。换句话说数据只在用户还在网站浏览的时候才保存起来。
sessionStorage在实践中主要用来暂时的数据 存储。好比说,用户在网页表单上的输入可以在用户浏览器会话的阶段保存在sessionStorage对象当中。这样的话,数据就可以在浏览的整个过程当中得到到而不须要把数据存储到服务器当中。也就是说,当用户不当心关闭或者刷新浏览器窗口,暂时的数据存储能够防止用户不得不重复输入数据。
从实现的角度来讲,localStorage和sessionStorage的实现方式是基本相似的。
localStorage和sessionStorage分享一套javascript方法(好比说:getItem
,setItem
等等),而且它也以键值对的方式存储数据。
可是,把数据存储在localStorage对象上意味着数据能够在用户的会话之间一直保存着。换句话说,数据能够在用户下一次访问这个网站的时候依然能够获取到。
Caniuse.com的结论是Web Storage有良好的浏览器支持。
Web Storage浏览器支持表
浏览器 | 版本 |
---|---|
Internet Explorer | IE8及IE8以上 |
Mozilla Firefox | Firefox 3.5及以上 |
Google Chrome | Chrome 4及以上 |
Apple Safari | Safari 4及以上 |
Opera | Opera 11.5及以上 |
目前,Web Storage标准是W3C Candidate Recommendation.总共有五个级别的推荐。"Candidate Recommendation"是这五个级别中的第三个级别。目前的Web Storage已经至关成熟由于这已经不是一个工做草案啦,可是与此同时,这个也不是最终的方案。
支持旧的没有Web Storage这个特性的浏览器能够经过使用polyfill来支持。对于localStorage的支持能够选择Store.js。
Web Storage和cookies有同样的禁止跨域的策略。这意味着一个网站的Web Storage不能被其余网站访问。这对于数据安全来讲是有益的。可是这也致使了咱们在须要子域的时候出现问题。对于这个问题,有其余的解决方案,好比由Zendesk开发的一个开源包Cross-Storage。
就像任何其余的客户端数据存储机制同样,保护存储的数据也是一个很重要的须要考虑的点。保存用户私密或者敏感的数据是不推荐的。这也让可以接触设备的人更方便的获取到本地数据。尤为是在一些其余人能够用公共的网络环境好比大学,图书馆,工做电脑等访问你的网站的地方更应该格外当心。
数据完备性也是一个考虑因素。必需要有在存储事务失败的时候的解决方案。当用户的Web Storage被关闭时候,或者当用户的存储空间不足的时候,或者超过浏览器的Web Storage限制的时候都有可能形成失败。Web Storage规范说明了当触发存储失败事件的标准的错误/警告输出,好比QuotaExceededError异常。
对于客户端存储来讲,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。