fighting_12
fighting_12

客户端存储

 

第20章 客户端存储

Web应用允许使用浏览器提供的API实现将数据存储到用户的电脑上。这种客户端存储相当于赋予了Web浏览器记忆功能。比方说，Web应用就可以用这种方式来“记住”用户的配置信息甚至是用户所有的状态信息，以便准确地“回忆”起用户上一次访问时候的状态。客户端存储遵循“同源策略”，因此不同站点的页面是无法互相读取对方存储数据的，而同一站点的不同页面之间是可以互相共享存储数据的，它为我们提供了一种通信机制，例如，一个页面上填写的表单数据可以显示在另外一个页面中。Web应用可以选择它们存储数据的有效期：比如采用临时存储可以让数据保存至当前窗口关闭或者浏览器退出；采用永久存储，可以将数据永久地存储到硬盘上，永不失效。

客户端存储有以下几种形式：

Web存储

Web存储最初作为HTML5一部分被定义成API形式，但是后来被剥离出来作为独立的一份标准了。该标准目前还在草案阶段，但其中一部分内容已经被包括IE8在内的所有主流浏览器实现了。Web存储标准所描述的API包含了 localStorage 对象和 sessionStorage 对象，这两个对象实际上是持久化关联数组，是名值对的映射表，“名”和“值”都是字符串。Web存储易于使用、支持大容量（但非无限量）数据存储同时兼容当前所有主流浏览器，但是不兼容早期浏览器。§20.1 会对 localStorage 和 sessionStorage 这两个对象作详细介绍。

Cookies

Cookie是一种早期的客户端存储机制，起初是针对服务器端脚本设计使用的。尽管在客户端提供了非常繁琐的JavaScript API来操作Cookie，但却难用之极，而且只能存储少量文本数据。不仅如此，任何以Cookie形式存储的数据，不论服务器端是否需要，每一次HTTP请求都会把这些数据传输到服务器端。Cookie目前仍然被客户端开发者大量使用的一个重要原因是：所有浏览器都支持它。但是，随着Web Storage的普及，Cookie终将会回归到最初的形态：作为一种被服务端脚本使用的客户端存储机制。§20.2会详细介绍Cookie。

IE User Data

微软在IE5及之后的IE浏览器中实现了它专属的客户端机制——”userData”。userData可以实现一定量的文本数据存储，对于IE8以前的IE浏览器中，可以将其用作是Web存储的替代方案。关于userData的API会在§20.3中作相应介绍。

离线Web应用

HTML5标准中定义了一组“离线Web应用”API，用以缓存web页面以及相关资源（脚本、CSS文件、图片等等）。它实现的是将web应用整体存储在客户端，而不仅仅是存储数据。它能够让web应用“安装”在客户端，这样一来，哪怕网络不可用的时候web应用依然是可用的。离线web应用相关的内容会在§20.4中作介绍。

Web数据库

为了能够让开发者像使用数据库那样来操作大量数据，很多主流的浏览器纷纷开始集成客户端数据库的功能。Safari、Chrome和Opera都内置了SQL数据库的客户端API。不幸的是，这类API的标准化工作以失败告终，并且Firefox和IE看样子也都不打算实现这种API。目前还有一种正在标准化的数据库API，称为“索引数据库API（Indexed Database API）”。调用该API返回的是一个不包含查询语言的简单数据库对象。这两种客户端数据库API都是异步的，都使用了事件处理机制（译注：类似DOM事件机制），这样的方式多多少少会显得有些复杂。本章中不会对他们做介绍，但是 §22.8 中会对索引数据库API作概要介绍同时会提供一些例子。

文件系统API

本书第8章介绍过现在主流浏览器都支持一个文件对象，用以将择的文件通过XMLHttpRequest上传到服务端。与之相关的规范（草案阶段）定义了一组API，用于操作一个私有的本地文件系统。在该文件系统中可以进行对文件的读写操作。这些内容正在紧锣密鼓标准化当中，这些API将在§22.7中作介绍。随着这些API被广泛地实现和支持，web应用可以使用类似基于文件的存储机制，这对于大部分程序员来说再熟悉不过了。

存储、安全和隐私

Web浏览器通常会提供“记住密码”功能，这些密码会以加密的形式安全地存储到硬盘上。然而，本章介绍的任何形式的客户端数据存储都不牵涉加密：任何存储在用户硬盘上的数据都是未加密的。这样一来，对于拥有电脑访问权限的恶意用户以及恶意软件（比如：间谍软件）同样也可以获取到存储的数据。因此，客户端存储不应该用来保存密码、商业账号或者其他类似的敏感信息。记住：尽管用户访问你的网站时，愿意在表单中输入一些信息，但绝不代表用户愿意将这些信息保存到硬盘上。就拿信用卡卡号来举例好了，这是用户的隐私，用户并不愿意公开，如果你利用客户端存储永久将该信息存储起来，这无异于你将信用卡号写在一张便签纸上，随后黏在用户的键盘上，让所有人都看到。 还有要谨记的一点：很多web用户不信任那些使用cookie和其他客户端存储机制来做类似“跟踪‘功能的网站。所以，尽量尝试用本章讨论的存储机制来为你的网站提升用户体验；而不是用它们来收集和侵犯隐私相关的数据。如果网站滥用客户端存储，用户将会禁用该功能，这样一来不仅起不到效果，还会导致依赖客户端存储的网站完全不可用。

20.1 localStorage 和 sessionStorage

实现了”Web存储“草案标准的浏览器在window对象上定义了两个属性：localStorage和sessionStorage。这两个属性都代表同一个Storage对象——一个持久化关联数组，数组使用字符串来索引，存储的值也都是字符串形式的。Storage对象在使用上和一般的JavaScript对象没什么区别：设置对象的属性为字符串值，随后浏览器会将该值存储起来。localStorage和sessionStorage两者的区别在于存储的有效期和作用域的不同：数据可以存储多长时间以及谁拥有数据的访问权。

下面，我们会对存储的有效期和作用域作详细的解释。不过，在此之前，让我们先来看些例子。下面的代码使用的是localStorage，但是它对sessionStorage也同样适用：

var name = localStorage.username; // 查询一个存储的值。
name = localStorage["username"]; // 等价于数组表示法
if (!name) {
    name = prompt("What is your name?"); // 询问用户一个问题。
    localStorage.username = name; // 存储用户的答案。
}

// 迭代所有存储的name/value对
for(var name in localStorage) { // 迭代所有存储的名字
    var value = localStorage[name]; // 查询每个名字对应的值
}

Storage对象还定义了一些诸如存储、获取、遍历和删除的方法。这些方法会在§20.1.2中作介绍。

”Web存储”草案标准指出，我们既可以存储结构化的数据（对象和数组），也可以存储原始类型数据，还可以存储诸如日期、正则表达式甚至文件对象在内的内置类型的数据。但是，截止至本书截稿时，浏览器仅仅支持存储字符串类型数据。如果想要存储和获取其他类型的数据，不得不自己手动进行编码和解码。如下例子所示：

// 当存储一个数字的时候，它会被自动转换成字符串。
// 但是，当获取该值的时候别忘记了手动将其转换成数字类型。
localStorage.x = 10;
var x = parseInt(localStorage.x);

// 同样地，存储一个日期类型数据的时候进行编码，获取的时候进行解码
localStorage.lastRead = (new Date()).toUTCString();
var lastRead = new Date(Date.parse(localStorage.lastRead));

// 使用JSON可以使得对基本数据类型编码的工作变得很方便
localStorage.data = JSON.stringify(data); // 编码然后存储。
var data = JSON.parse(localStorage.data); // 获取数值之后再解码。

20.1.1 存储有效期和作用域

localStorage和sessionStorage的区别在于存储的有效期和作用域的不同。通过localStorage存储的数据是永久性的，除非web应用刻意删除存储的数据，或者用户通过设置浏览器配置（浏览器提供的配置界面）来删除，否则数据将一直保留在用户的电脑上，永不过期。

localStorage的作用域是限定在文档源（document origin）级别的。正如§13.6.2所介绍的，文档源是通过协议、主机名以及端口三者来确定的，因此，下面每个URL都拥有不同的文档源：

http://www.example.com              // 协议: http; 主机名: www.example.com
https://www.example.com            // 不同协议
http://static.example.com              // 不同主机名
http://www.example.com:8000      // 不同端口

同源的文档间共享同样的localStorage数据（不论该源的脚本是否真正地操作localStorage）。它们可以互相读取对方的数据，甚至可以覆盖对方的数据。但是，非同源的文档间互相都不能读写对方数据（即使它们运行的脚本是来自同一台第三方服务器也不行）。

需要注意的是localStorage的作用域也受浏览器供应商限制。如果你使用Firefox访问站点，那么下次用另一个浏览器比方说是Chrome再次访问的时候，那么本次是无法获取上次存储的数据的。

通过sessionStorage存储的数据和通过localStorage存储的数据的有效期也是不同的：前者有效期和存储数据的脚本所在的最顶层的窗口或者是浏览器标签页是一样的。一旦窗口或者标签页被永久关闭了，那么所有通过sessionStorage存储的数据也都被删除了。（当时要注意的是，现代浏览器已经具备了重新打开最近关闭的标签页随后恢复上一次浏览的session功能，因此，这些标签页以及与之相关的sessionStorage的有效期可能会更加长些）。

与localStorage一样，sessionStorage的作用域也是限定在文档源中，因此非同源文档间都是无法共享sessionStorage的。不仅如此，sessionStorage 的作用域还被限定在窗口中。如果同源的文档渲染在不同的浏览器标签页中，那么他们互相之间拥有的是各自的sessionStorage数据，无法共享；一个标签页中的脚本是无法读取或者覆盖由另一个标签页脚本写入的数据，哪怕这两个标签页渲染的是同一个页面，运行的是同一个脚本也不行。

要注意的是：这里提到的基于窗口作用域的sessionStorage指的窗口只是顶级窗口。如果一个浏览器标签页包含两个