长久以来本地存储能力一直是桌面应用区别于Web应用的一个主要优势.对于桌面应用（或者原生应用)，操作系统一般都提供了一个抽象层用来帮助应用程序保存其本地数据

例如（用户配置信息或者运行时状态等). 常见的存放这些数据的方式有许多： 注册表，INI文件，XML文件等等。 除了上面这些比较简单的用来存放 键值对的存储形式，如果你需要使用更加复杂强大的存储，那么你还可以进一步在应用程序中嵌入小型数据库，或者开发出特定的数据文件格式。

遗憾的是，上面这些本地存储方法对Web应用来说都是不适用的。在Web的发展史上，在很长时间里 Cookies是唯一可以使用的在用户本地存储少量数据的方法。 但Cookies有一些非常明显的缺陷，限制了它的应用:

1. cookie会被附加在每个HTTP请求中，所以无形中增加了流量。

2. 由于在HTTP请求中的cookie是明文传递的，所以安全性成问题。 （除非你的整个应用都是使用SSL来构建的)

3. Cookie的大小限制在4 KB左右。 对于复杂的存储需求来说是不够用的。

对于开发者来说，他们真正需要的是

1. 不受限的存储空间

2. 数据保存在客户端

3. 数据的生命周期可以跨越页面的刷新（甚至浏览器关闭重新打开)

4. 本地数据不必每次都被重复的传回服务器而导致流量增加

在HTML5之前，为了达成上述目标，人们开发出了许多方法，但是总是有一些不尽人意之处。

在HTML5之前的本地存储的简史

在互联网发展早期，浏览器市场还很单一（处在领先地位的只有Netscape浏览器和IE）。在第一次浏览器大战中，微软的IE为了争取更大的份额，它自己发明了许多额外附加的功能。 这些功能就包括动态HTML （DHTML） ， 而动态HTML中就包含了一种称为userData的技术。

userData 允许网页存储最大64KB的基于XML的结构化数据（每个站点） 。获信的站点，例如内网站点，可使用的存储量可以增大到10倍，也即640K。 在使用userData时，IE不会弹出任何形式的对话框来要求用户授权，也不允许程序增加本地存储的容量。

在2002年，Adobe（译者：那个时候其实应该是Macromedia) 在Flash6中引入了一个新的本地存储功能，并命名为“Flash Cookies"。 这个名称十分具有迷惑性，其实跟cookie没什么关系。 在Flash中，这个功能被称作 Local Shared Objects 。 简单来说，这个技术允许Flash 对象存储100KB的数据（每个站点 ）。 基于此， Brad Neuberg 开发了一个称为 AMASS(AJAX Massive Storage System) Ajax大容量存储系统)的 Flash到JavaScript的桥接原型接口,允许开发者在JavaScript中调用LSO，但是由于Flash的种种技术局限，这个原型并不大好用。 到2006年，随着Flash 8 引入了ExternalInterface技术，在JavaScript中访问LSO对象变得简化了许多。这时Brad重写了AMASS并把它整合到了流行的Dojo Toolkit 框架中， 并正式命名为dojox.storage。 Flash的这种技术允许每个站点存储100KB的数据，超过100KB，则每增加超过一个数量级（如1MB， 10MB 等），它就会弹出对话框来要用户确认并授权。

在2007年，Google启动了著名的Gears项目， Gears是一个通过插件技术来增强浏览器功能的开源项目。 Gears提供了一套API来访问一个基于SQLite的嵌入式SQL数据库， 在获得用户的一次性授权后，应用程序可以通过Gears存储不限数量的本地数据。

与此同时, Brad Neuberg 和其他人继续开发dojox.storage ， 希望能够提供一套统一的JavaScript接口来封装上面各种插件和接口。 到2009年时， dojox.storage 已经可以做到自动的侦测用户浏览器所支持的本地存储技术，并提供统一的访问接口，包括Adobe Flash, Adobe AIR, Gears 以及早期 Firefox浏览器所提供的HTML5 存储功能。

从我们前面的介绍可以看到这些五花八门的技术都有一个问题，他们要么是某个浏览器所特有的技术，要么依赖于某个第三方插件(flash或Gears). 虽然Dojox.storage非常有远见的试图去封装这些区别，但是用户仍然会因为底层技术的限制而在用户体验，允许存储的数据量等方面无法统一。 这时，只有HTML5标准的出现才能彻底解决这些问题: 提供一套标准化的API, 被绝大多数浏览器支持，不用依赖任何第三方插件。

HTML5 本地存储简介

这里我们称为HTML Storage的实际上是一个称为 Web Storage 的标准， 它原来曾是HTML5标准的一部分，但由于某些政治因素，现在它被独立出来。 某些浏览器厂商也称它为 本地存储(local storage)，或者DOM存储 (DOM Storage)

那么究竟什么是HTML5本地存储 ？ 简单来说，它就是一种让网页可以把键值对存储在用户浏览器客户端的方法。像Cookie一样，这些数据不会因为你打开新网站，刷新页面，乃至关闭你的浏览器而消失。 而与Cookie不同的时，这些数据不会每次随着HTTP请求被发送到服务器端(当然如果你需要这么做，你可以自己编程实现 ）. 因为这是HTML5规范的一部分，这一接口会被浏览器原生支持，不用依赖任何第三方插件。

那么，现在有哪些浏览器支持这一接口呢？ 在这篇文章写作时（译者:2011年2月） 差不多所有主流浏览器的最新版都支持了，连IE8都支持了。

在你的JS代码中，你可以通过winow.localStorage 对象来访问HTML5 本地存储功能. 当然，考虑到浏览器兼容性，你在使用前应该先侦测一下你的用户的浏览器是否支持.

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

另一种方式是使用Modernizr (译者：一个开源的用来侦测用户浏览器对HTML5支持度的工具) 来侦测

if (Modernizr.localstorage) {
  // window.localStorage is available!
} else {
  // 浏览器不支持HTML5 storage :(
  // 可以考虑使用dojox.storage 或其他方法
} 

如何使用HTML5 存储

HTML5 存储是基于键值对的。数据存储在一个键里，访问数据时可以根据同样的键获得上次存储的数据. 键是一个字符串. 而数据则可以是任何类型的JavaScript基本数据类型，包括 字符串，Boolean，整数，和浮点数. 不过需要注意的是，这些数据在存储时实际上是以字符串保存的。 因此在访问数据时你需要利用parseInt() 或 parseFloat()方法来做数据类型的转换。

interface Storage {
  getter any getItem(in DOMString key);
  setter creator void setItem(in DOMString key, in any data);
};

如果在调用setItem 时使用一个已经存在的键，将会直接覆盖掉该键上保存的值。而调用getItem时传入一个不存在的键，则会返回一个null ，不会抛出异常。

就像其他JavaScript对象一样，你也可以将localStorage对象当成是关联数组使用(associative map) ,除了使用getItem和setItem之外，你可以使用中括号的方式来引用数据. 例如

var foo = localStorage.getItem("bar");
// ...
localStorage.setItem("bar", foo);
//和下面代码是等价的：
var foo = localStorage["bar"];
// ...
localStorage["bar"] = foo;

该接口还提供了方法来删除某个键和清空整个存储区域(删除所有的键和值)

interface Storage {
  deleter void removeItem(in DOMString key);
  void clear();
};

如果removeItem传入一个不存在的key则无操作，也不会有异常。

最后，还提供了一个length属性来指示存储区域中所包含的所有键值对的数量 以及遍历所有键的key方法

interface Storage {
  readonly attribute unsigned long length;
  getter DOMString key(in unsigned long index);
};

如果你向key方法传入了一个越界的值（不在0到length-1 之间），则该方法返回null。

追踪HTML5 存储区域中的数据变化

除了常用的存取数据的方法，开发者还需要能够侦测数据变化的编程接口。这就是存储事件（storage event ）
当setItem(),removeItem()或者clear() 方法被调用，并且数据真的发生了改变时，storage事件就会被触发。注意这里的的条件是数据真的发生了变化。也就是说，如果当前的存储区域是空的，你再去调用clear()是不会触发事件的。或者你通过setItem()来设置一个与现有值相同的值，事件也是不会触发的。

所有支持localStorage对象的浏览器都支持存储事件，也包括IE8。 不过由于IE8不支持W3C标准的addEventListener （IE9 支持）。因此要在不同浏览器中侦听存储事件，仍然需要一些代码来兼顾浏览器之间事件处理机制的不同。

当然你也可以使用jQuery，Dojo 或者其他Javacript类库来帮你注册事件处理函数，存储事件也是可以支持的。

if (window.addEventListener) {
  window.addEventListener("storage", handle_storage, false);
} else {
  window.attachEvent("onstorage", handle_storage);
};

上面代码中handle_storage 是在存储事件发生时被调用的回调函数，传入参数是StorageEvent。 在IE中，该event对象会被保存在window.event 中。

function handle_storage(e) {
  if (!e) { e = window.event; }
}

StorageEvent对象会包含下列的属性。

* 注意: url 属性早期的规范中为uri属性。有些浏览器发布较早，没有包含这一变更。为兼容性考虑，使用url属性前，你应该先检查它是否存在，如果没有url属性，则应该使用uri属性

要注意一点，在存储事件的处理函数中是不能取消这个存储动作的。存储事件只是浏览器在数据变化发生之后给你的一个通知。

目前技术的局限

前面的章节中， 我提到了过去许多用来实现浏览器本地存储的技术和插件的缺点，例如存储容量的限制。其实HTML5本地存储标准也有它自身的局限。简单来说就是这几个关键词，“5M容量"和 “QUOTA_EXCEEDED_ERR“ 。

“5M容量",是每个来源（origin)（http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#origin-0）允许存储容量的默认限制。在HTML5 存储标准中，5M只不过是作为一个建议的数值出现的，但是这个建议被所有的浏览器所采用。挺奇怪的，不是吗？　　需要注意的是，存储的数据都是以字符串形式保存的。因此如果你存储了大量整型数或浮点数，这些数也会以字符串形式保存。浮点数的每一位都需要一个字符来表示。 这大大增加了所需要的存储空间。

第二个关键词“QUOTA_EXCEEDED_ERR” 是一个异常，如果你使用的存储容量超过了5M，你就会碰到它。

接下来你自然会要问那如果我想使用超过5M的容量，是不是可以通过弹出对话框让用户授权的方式来增加允许容量么？很遗憾，答案是”不行！“ 在这篇文章写作时,(2月 2011), 没有浏览器支持允许程序向用户请求更大存储空间的机制。 有些浏览器（例如Opera）允许用户自己来控制每个站点可使用的存储容量，但是这必须由用户自己主动发起才行，作为开发者你没有办法来发起这样的请求。

HTML5 本地存储 实战

这一节让我们来实际操作一下HTML5 本地存储。 回忆一下我们在canvas章节中开发的Halma 游戏。由于没有加入本地存储支持，每次关闭浏览器这个游戏的进度就会丢失。现在我们可以用HTML5 本地存储技术在浏览器中保存玩家的游戏进度。这里是一个演示。

试试看，在游戏中操作一些步骤，然后关闭该标签页然后在新标签页中再打开该游戏页面。如果你的浏览器支持HTML5本地存储，你会发现关闭前的游戏进度和状态被神奇的记录下来了。

这是怎么实现的呢？ 在游戏中，每次发生状态变化，我们都会调用下面的方法:

 function saveGameState() {
    if (!supportsLocalStorage()) { return false; }
    localStorage["halma.game.in.progress"] = gGameInProgress;
    for (var i = 0; i < kNumPieces; i++) {
    localStorage["halma.piece." + i + ".row"] = gPieces[i].row;
    localStorage["halma.piece." + i + ".column"] = gPieces[i].column;
    }
    localStorage["halma.selectedpiece"] = gSelectedPieceIndex;
    localStorage["halma.selectedpiecehasmoved"] = gSelectedPieceHasMoved;
    localStorage["halma.movecount"] = gMoveCount;
    return true;
}

首先保存一个标志变量”gGameInProgress"用来指示当前是否有一个游戏正在进行。 然后是保存正在进行中的游戏的状态，包括哪些棋子被选中了，当前一共走的总步数等等 。

在每次页面加载时，我们会调用resumeGame()方法，这个方法会先检查本地存储中的halma.game.in.progress"标志，如果是true，则会恢复上次保存的游戏状态。如果false，则调用newGame开始新游戏。

function resumeGame() {
    if (!supportsLocalStorage()) { return false; }
    gGameInProgress = (localStorage["halma.game.in.progress"] == "true");
    if (!gGameInProgress) { return false; }
    gPieces = new Array(kNumPieces);
    for (var i = 0; i < kNumPieces; i++) {
    var row = parseInt(localStorage["halma.piece." + i + ".row"]);
    var column = parseInt(localStorage["halma.piece." + i + ".column"]);
    gPieces[i] = new Cell(row, column);
    }
    gNumPieces = kNumPieces;
    gSelectedPieceIndex = parseInt(localStorage["halma.selectedpiece"]);
    gSelectedPieceHasMoved = localStorage["halma.selectedpiecehasmoved"] == "true";
    gMoveCount = parseInt(localStorage["halma.movecount"]);
    drawBoard();
    return true;
} 

在上面resumeGame中最重要的一点就是“ 所有HTML5 本地存储中的数据都是以字符串形式保存的，如果你保存了其他数据类型，在访问这些数据时一定要自己对这些数据做强制类型转换"。 例如我们保存的标志变量gGameInProgress是一个Boolean类型。 在saveGameState()中我们不需要做任何特别操作

localStorage["halma.game.in.progress"] = gGameInProgress;

但是在resumeGame中，我们要访问这个数据时，则必须做从string到Boolean的强制转换

gGameInProgress = (localStorage["halma.game.in.progress"] == "true");

类似的，处理数值类型，例如gMoveCount 变量，在saveGameStat中我们用下面的语句保存一个整型变量

localStorage["halma.movecount"] = gMoveCount;

但在resumeGame方法中，则要使用JavaScript的parseInt函数来将这个值从字符串转换为整型

MoveCount = parseInt(localStorage["halma.movecount"]);

比键值对更强大的未来

相比HTML5标准成型前的混乱状态，今天HTML5本地存储的情形前所未有的令人振奋。 新的API被标准化，并且被所有的主流浏览器平台和设备所支持。 作为看惯了各种不兼容的Web程序员，很少有机会看到如此美妙一致的现实。 不过5M的存储容量以及仅仅能存储键值对这种简单数据结构对于较复杂的应用来说仍然是远远不够的。所以客户端持久化的未来仍然有许多发展的空间。而现在我们已经能看到许多互相竞争的技术在浮现。

其中一种技术的大名你也许早就听到过 "SQL". （译者: 这句笑话很冷啊） 2007年，Google发布Gears项目。Gears是一个跨浏览器的插件，其中就包含了一个基于SQLite的嵌入式数据库。 这一早期原型后来影响了Web SQL DataBase 规范的建立.

WebSQLDataBase (之前也称作 WebDB） 在SQL DB之上提供了一层简单封装，从而允许你在JavaScript中使用下面的代码： (这可不是伪代码，下面的代码在4个浏览器里是真的可以工作的！）

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);
}); 

这段代码的核心就是传入 executeSql方法的SQL 语句。这里它能够支持所有的SQL语句，包括SELECTUPDATE, INSERT 和 DELETE。 一切都和后台的数据库编程没什么区别，唯一不同的是你是在JavaScript里调用的！ 太欢乐了！

Web SQL Database 标准已经在4个浏览器（以及对应的平台）中被实现了。

Web SQL Database supportIE Firefox Safari Chrome Opera iPhone Android

· · 4.0+ 4.0+ 10.5+ 3.0+ 2.0+

当然，如果你对SQL略微有所了解的话，你就会明白其实“SQL” 这个词更多只是一个常用术语而不是一个真正统一的标准。（ 这其实和HTML5 这个词是一样的 ） 当然，我们读书时都学过一个SQL-92 标准，遗憾的是在现实世界里，没有一款产品能真正的严格符合这套标准。因此我们知道有甲骨文的SQL，微软的SQL，MySQL的SQL， PostgreSQL的SQL， SQLite的SQL。 每个厂商都在自己的数据库产品中加入了特有的SQL新特性。甚至在一个厂商的产品中，不同的版本间SQL的用法也会产生变化。

这些SQL业界的纷争就导致了我们看到在Web SQL Database 规范中出现了如下的免责声明:

本规范现在碰到了一个难题： 所有的感兴趣的厂商目前都使用了同样的SQL后台(Sqllite), 但是我们还需要有更多独立的实现来使本规范成为一个标准。目前本规范中所使用的SQL语法(SQL dialect)只是一个基于Sqlite所支持的SQL语法的参考，并不会作为将来标准的一部分。

另一个与此竞争的技术是 索引数据库(Indexed Database API )， 之前也称作WebSimpleDB, 不过现在更多人叫它IndexedDB

索引数据库API主要的概念是对象存储容器(object store),对象存储容器很像SQL中的数据库概念。每个数据库（object store）中都有很多记录（对象），每个记录都有很多字段（fields)。每个字段都有其预定义好的数据类型。 你可以选择所有记录的子集，使用游标来遍历所有记录， 也提供了事务的概念来保证数据完整性和一致性。

所有这些概念都和传统SQL数据库编程很相似。最主要的区别在于，Object Store之上不能使用SQL语句这种结构化的查询语言。 你用不着构建像SELECT * from USERS where ACTIVE = 'Y' 这样的查询。 你要做的是通过object store 提供的方法在名为USERS的数据库上打开一个游标指针（cursor）来遍历所有记录，然后过滤掉那些不满足条件的记录，最后在剩下的记录上使用数据访问方法获取你所需要的数据。 这篇索引数据库入门是一篇很好的教程，里面 详细比较了索引数据库和Web SQL 数据库

在本文写作时，索引数据库只是在FF4 的beta版中被实现了。 Mozilla已经声明他们永远不会去实现Web SQL 数据库. Google 则说他们正考虑在Chromium和Google Chrome上支持索引数据库,连微软也说索引数据库是"很好互联网解决方案"

那么你究竟能用索引数据库干点什么呢？ 在目前的状况下，除了一些演示之外几乎什么也做不了。 但是谁知道1年之后会不会就大不一样了呢。