HTML5存储的过去，现在，未来 [译]

原文链接：HTML5 Browser Storage: the Past, Present and Future

其实，之前已经翻过一篇关于HTML5存储的文章了，这一篇是更加深入一些的，个人觉的，下面，走你了。

为啥要把数据存在Client?

主要原因是出于最佳实践方面的考虑。跑在浏览器客户端的Js代码不需要将所有的信息往server端发送，这就有了把数据存在client端的需求。有如下几种情况：

提高性能：通过将data缓存（cache）在客户端，这样data可以在无需发起多余的server端请求的情况下被获取。
对于数量巨大的且只在客户端用的到的数据，比如，HTML字符串 或者 组件配置设置信息等。
离线应用的情况

Js变量的过去，现在和未来

最简单的一种实现本地存储的方法当属JavaScript变量了。你可以像如下代码一样，创建一个全局变量来保存你应用的相关数据。

// global application storage
var appDataStore = {};

// set values
appDataStore.hello = "Hello World!";
appDataStore.info = { a:1, b:2, c:3 };

// get values
console.log(appDataStore.hello);
console.log(appDataStore.info.b);

比上面稍微复杂点的是，你可以把数据作为页面DOM节点的 attributes 或者 properties 进行存储。这种方式对于那些 与view组件相关的数据 尤其有用。但是它相较于Js变量来说更慢，而且风险性更高。不同的浏览器或者别的库可能在解析这种数据时采用的是意想不到的策略，从而导致了难以预料的后果。

// store data in node
var mywidget = document.getElementById("mywidget");
mywidget.setAttribute("data-myvalue", "Hello World!");

// retrieve values
mywidget.textContent = mywidget.getAttribute("data-myvalue");

通过对以上两种方式的描述，我们可以大致得到Js变量实现的本地存储的优缺点：

优点：
- 更快，更简单
- 无需将data序列化/解序列化
- 对于单页面应用非常理想
弱点：
- 非常脆弱：因为是全局的，在页面哪里都可以取到，但是一旦用户按 F5 或者关闭当前的网页Tab，就杯具了
- 全局变量很容易通过第三方脚本被改写

cookies的过去，现在和未来

cookie是和特定域名相关的文本数据，怎么说呢，就是你上网，对应于一个域名，浏览器会维护一个chunk的cookie数据。cookie这个名字听起来非常可口，但是如果你有用过Js去进行相关的cookie操作的话，我保证你会觉的它相当DT，因为 document.cookie 这个字符串必须进行解析处理。见以下代码：

// store cookie data
document.cookie = "hello=" + escape("Hello World") + "; path=/";

// retrieve value
cookies = document.cookie.split(";");
value = null;
regexp = new RegExp("^\s*hello=(.*)$");
for (var c=0; c < cookies.length && !value; c++) {
    var match = cookies1.match(regexp);
    if (match.length == 2)
        value = unescape(match[1]);
}

console.log(value);

看了上面的代码，应该是有些地方有问题，可以试着找找哈。接下来说一下cookie的优缺点吧。

优点：
- 首先它是一种可靠有效的保持客户端与server端状态同步的一种方法
- 通过给cookie设置过期日，即使用户F5或是关闭Tab，再也不用担心数据会丢了
- 所有现代浏览器都支持
弱点：
- 笨拙的Js实现，你可能会需要一个小库来做cookie操作
- 数据都是按字符串存储，非字符串数据必须经过序列化，比如通过 JSON.stringify 和 JSON.parse
- 存储空间是有限制的
- 用户可以删除或者阻止cookie开启
- 安全问题

另外补充一点，cookie的client/server共享的这个方案的另一面（flip-side）是引起了最大的技术难题。由于cookie是存在htpp请求的头部进行发送的，这就意味着，你每发起一次http请求或者每次htpp响应中，HTML页面，iamge，css文件，js文件，ajax调用等，每个文件都会携带cookie，因为cookie是只要发起了http请求/响应，cookie就会被传递，就算它其实没有发生变化。这就很不好了，会造成大量冗余的根本就毫无意义的网络带宽的占用。举个例子，你有一个50kb的cookie数据，你现在要下10个1KB的图片，就相当于10次http请求，那也就会有10次http response，那样cookie总共传递了20次，那这个过程中总共发生了50*20Kb + 1KB的网络流量，这是多么大的浪费呀，因为实际上，我只是想要10KB的图像。

window.name的过去和现在

window.name 属性有些奇怪，它支持的是你可以为它设置一个字符串当作值，这个值会在你刷新、点击链接又重新返回时始终存在。

window.name = "Hello World!";
console.log(window.name);

优点：
- 简单易用
- data只存在client，永远不会发送至server端
- 可以有达到及格megabytes的数据容量
- 宽泛的浏览器支持
缺点：
- 用户关闭tab或浏览器时，数据丢失
- 只能存字符串，这就意味着别的类型数据必须序列化
- 其他域名下的页面可以读/写该属性，不能用作敏感性数据，安全性不佳

window.name 本身就不是被设计来用作数据存储的，它只不过是一个hack，浏览器厂商随时都有可能停止对它的支持。所以，最好还是改用别的选项吧。如以下链接：

How to Write a Cookie-less Session Library for JavaScript

HTML5过去的存储方式：Web SQL DB

HTML5之前采用的存储策略是：Web SQL数据库。Web SQL是浏览器厂商将基于SQL的关系型数据库带到浏览器上的尝试。其中，chrome、safari、和opera15+都支持，但是Mozilla和Microsoft不支持，它们支持了IndexedDB。

优点：
- 为了健壮的客户端数据存储而设计
- 像大多数server端的应用那样使用SQL
- 在webkit/blink的桌面及移动浏览器上支持
弱点：
- SQL不利于客户端开发
- 有可能被弃用
- 设计不合理
- w3c在2010年的时候放弃它了

总的就一句话，不要再用Web SQL的DB了。

HTML5将来的存储方式之一：HTML5 Web Storage

HTML5的Web存储提供了两个拥有一致的API的对象：window.localStorage 和 window.sessionStorage 这两个。前者是用来在本地存储永久数据的，后者则是用来存储会话数据的（也就是tab不关闭时的数据）。这两个对象存储的都是 name/value 。而且与cookie不同，Web存储的大小大多了（最少5MB），而且通过这个策略存储的数据是永远不会传输至server的。

废话一句，纵使：Cookie的大小是受限的，并且每次你请求一个新的页面的时候Cookie都会被发送过去，这样无形中浪费了带宽，另外cookie还需要指定作用域，不可以跨域调用。但是Cookie也是不可以或缺的：Cookie的作用是与服务器进行交互，作为HTTP规范的一部分而存在，而Web Storage仅仅是为了在本地“存储”数据而生。

具体的API详见w3c文档：W3C Web Storage Specification

优点：
- 使用“键值对”进行存储非常简单
- 提供了两种选项（两个对象）
- 提供了一个事件模型让浏览器的其他标签和窗口保持数据同步
- 桌面和移动端浏览器的广泛支持，包括IE8+
- 通过Web Storage Polyfills提供对老旧浏览器的支持
缺点：
- 只支持字符串值，所以需要序列化
- 不支持索引，搜索等非结构化数据的事务
- 如果数据集巨大，将表现极差的性能