HTML5本地存储不完全指南

历史

在HTML5本地存储之前，如果我们想在客户端保存持久化数据，有这么几个选择：

HTTP cookie。HTTP cookie的缺点很明显，最多只能存储4KB的数据，每个HTTP请求都会被传送回服务器，明文传输（除非你使用SSL）。
IE userData。userData是微软在上世纪90年代的浏览器大战时推出的本地存储方案，借助DHTML的behaviour属性来存储本地数据，允许每个页面最多存储64K数据，每个站点最多640K数据，userData的缺点显而易见，它不是Web标准的一部分，除非你的程序只需要支持IE，否则它基本没什么用处。
Flash cookie。Flash cookie的名字有些误导，它实际上和HTTP cookie并不是一回事，或许它的名字应该叫做"Flash本地存储”，Flash cookie默认允许每个站点存储不超过100K的数据，如果超出了，Flash会自动向用户请求更大的存储空间，借助Flash的 ExternalInterface接口，你可以很轻松地通过Javascript操作Flash的本地存储。Flash的问题很简单，就是因为它是 Flash。
Google Gears。Gears是Google在07年发布的一个开源浏览器插件，旨在改进各大浏览器的兼容性，Gears内置了一个基于SQLite的嵌入式 SQL数据库，并提供了统一API对数据库进行访问，在取得用户授权之后，每个站点可以在SQL数据库中存储不限大小的数据，Gears的问题就是 Google自己都已经不用它了。

现状

我们现在通常所说的HTML5本地存储，一般指的是Web Storage规范，这个标准曾经是HTML5规范的一部分，但后来因为种种原因从HTML5规范中分离了出来。但是除了Web Storage，HTML5的本地存储标准还有另外2个竞争者：Web SQL Database和IndexedDB。下面就让我们依次来看看这3个规范吧。

Web Storage

Web Storage是目前得到支持最广泛的HTML5本地存储规范：IE 8+、FF 3.5+、Safari 4+、Chrome 4+、Opera 10.5+，以及iPhone 2+和Android 2+都已经支持Web Storage，要判断你的浏览器是否支持Web Storage，可以使用下面这个函数：

代码

function supports_html5_storage() {
        try {
            return 'localStorage' in window && window['localStorage'] !== null;
        } catch (e) {
            return false;
        }
    }

HTML5 Storage的使用非常简单：

代码

var foo = localStorage.getItem("bar");
    // ...
    localStorage.setItem("bar", foo);

你也可以写成下面这样：

代码

var foo = localStorage["bar"];
    // ...
    localStorage["bar"] = foo;

如果要将某个key从存储空间删除，可以调用removeItem：

代码

localStorage.removeItem('foo');

你也可以像遍历数组那样遍历存储的所有键值对象：

代码

for(var i=0; ivar key = localStorage.key(i);
        console.log(key + ":" + localStorage[key]);
    }

如果你的程序需要在不同页面访问同一个值，你可能需要了解这个值是否已经被其他页面改变了，这可以通过向浏览器注册storage事件来实现：

代码

window.addEventListener('storage', function(e) {
        console.log(e.key + "'s value is changed from '" +
            e.oldValue + "' to '" + e.newValue + "' by " + e.url);
    }, false);

    //A页面
    localStorage['foo'] = 'bar';

    //B页面
    localStorage['foo'] = 'newBar';

这时你应该会在A页面的Console中看到：

foo’s value is changed from ‘bar’ to ‘newbar’ by http://localhost/test.html

要注意的是，storage事件仅仅只是通知你某个键对应的值已经发生了改变，你没有办法在回调中阻止这个改变发生。

HTML5 Storage看起来不错，那它有没什么缺点呢？好问题。要说HTML5 Storage的缺点，唯一的问题就是它默认的QUOTA只有5MB，并且你没办法通过程序自行或是提示用户来增加存储空间。唯一的办法就是用户自己打开浏览器的设置，并手动修改QUOTA的大小，如果超出了5MB的限制，你将会遇到一个“QUOTA_EXCEEDED_ERR”的错误。

Web SQL Database

Web SQL Database是一个已经废弃的规范，但是鉴于除了IE和Firefox，其他浏览器都已经实现了Web SQL Database，并且它还具有一些HTML5 Storage所不具有的特性，所以还是值得了解一下的。

Web SQL Database就像它的名字那样，就是一个让你可以在Web上直接使用的SQL数据库，你要做的就是打开数据库，然后执行SQL，和你对Mysql做的事情没什么两样：

代码

openDatabase('documents', '1.0', 'Local document storage', 5*1024*1024,
    function (db) {
        db.changeVersion('', '1.0', function (t) {
            t.executeSql('CREATE TABLE docids (id, name)');
        }, error);
    });

关于Web SQL Database的更多介绍，可以参看这篇指南。

但是它的缺点也同样明显。最大的问题就出在SQL上，实际上并不存在一种叫做SQL的标准结构化查询语言，我们平常使用的实际上是MS SQL、Oracle SQL、MySQL SQL、postgre SQL或者SQLite SQL（尽管有一个叫做SQL-92的规范，但它基本形同虚设），更进一步，甚至都不存在SQLite SQL，我们使用的实际上是SQLite x.y.z SQL，而这也就是Web SQL Database最大的问题，它无法统一各个浏览器厂商实现的SQL语言，如果你的某条Web SQL查询只能在Chrome上运行，这还能叫做标准吗？

所以，如果你现在访问Web SQL Database的规范页面，你会在顶部看到这样一则声明：
这个规范已经陷入了一个僵局：目前的所有实现都是基于同一个SQL后端（SQLite），但是我们需要更多的独立实现来完成标准化，所以除非有厂商愿意独立实现这个规范，否则当前的SQL规范只能采用SQLite的SQL方言，而作为一个标准，这是不可接受的。

IndexedDB

最后我们要介绍的就是IndexedDB了，相比其他两个规范，目前只有Firefox实现了IndexedDB（顺便提一下，Mozilla表示它们永远不会去实现Web SQL Database），不过Google已经表示正在考虑在Chrome中加入IndexDB支持。

IndexedDB引入了一个object store的概念，这有点像是一个SQL Database，你可以在“数据库”中存储“记录”，并且每条“记录”可以拥有很多“字段"，每个字段都有一个特定的数据类型，你可以选择记录的子集，并使用“光标”进行遍历，同时object store中的所有变更都是基于“事务”的。

下面让我们来看一个小例子：

代码