客户端存储web应用允许使用浏览器提供的API实现将数据存储在用户电脑上。这种客户端存储相当于赋予了web浏览器记忆功能。
客户端存储遵循“同源策略”,因此不同站点的页面是无法读取对于存储的数据。而同一站点的不同的页面之间是可以互相共享存储数据的。
web应用可以选择他们存储数据的有效期:有临时存储的,可以让数据保存至当前窗口关闭或浏览器退出;也有永久存储,可以将数据永久地存储在硬盘上,数年或者数月不失效。
web存储
web存储最初作为HTML5的一部分被定义为API形式,但是后来被剥离出来作为独立的一份标准了。目前包含IE8在内的主流浏览器(可交互地)都实现了。web储存标准所描述的API包含localStorage和sessionStorage对象,这两个对象实际上是持久化的关联数组,是名值对的映射表,“名”和“值”都是字符串。web存储易于使用,支持大容量(但非无限量)数据存储同时兼容当前所有主流浏览器(但不兼容早期浏览器)
cookie
cookie是一种早期的客户端存储机制,期初是为征对服务器端脚本设计使用的。尽管在客户端提供了非常繁琐的javascript API来操作cookie,但它们难用至极,而且只适合少量的文本存储。不仅如此,任何以cookie形式存储的数据,不论服务器端是否需要,每一次HTTP请求都要把这些数据传输到服务器端。cookie目前仍然被大量的客户端程序员使用的一个重要的原因是:所有新旧浏览器都支持它。但是,随着Web Storage的普及,cookie将最终回归到最初的形态:作为一种被服务端脚本使用的客户存储机制。
IE User Data
微软在IE5之后的IE浏览器实现了专属它的客户端存储机制-“User Data”。userData可以实现一定量的字符串数据存储,对于IE8前的IE浏览器,可以将其用做是Web存储的替代方案。
离线web应用
HTML5标准定义了一组“离线web应用”API,用于缓存web页面以及相关资源(图片,脚本,CSS文件等)。它的现实是将web应用整体存储在客户端,而不仅是存储数据。它能够让web应用“安装”在客户端。这样一来,哪怕网络不可用的时候web应用依然是可用的。
web数据库
为了能够让开发者像使用数据那样操作大量的数据,很多主流浏览器纷纷实现在其中开始集成客户端数据库功能。Safari,Chrome,和Opera都内置了SQL数据库的客户端API。遗憾的是这类的API标准化最终以失败而告终,并且,Firefox和IE看来不打算实现这类API。目前还有一种正在标准化的API,称为“索引数据库API”。调用该API返回的是一个不包含查询术语的简单数据库对象。这两种客户端数据库API都是异步的,都使用了事件处理机制(类似DOM事件的机制),这样的方式多多少少都显得复杂,本章不会对它们做介绍。在20章第8节会简要介绍所有索引数据库API同时提供一些例子。
文件系统API
在第8章介绍过现代的浏览器都支持一个文件对象,用以将选择的文件通过xmlHttPRequest上传到服务器。与之相关的规范(草案阶段)定义了一组API,用于操作一个私有的本地文件系统。该系统中,可以进行对文件的读写操作。目前正在标准化当中。这些API在20章第7节中做介绍。这些API被广泛地实现和支持,web应用可以使用类似文件的存储机制,这对大部分程序员来说再熟悉不过了。
web浏览器通常会提供“记住密码”功能,这些密码会以加密的形式安全地存储在硬盘上。然而本章介绍的任何形式客户端数据存储都不牵扯加密:任何存储在用户硬盘上的数据都是未加密形式。这样一来,对于拥有电脑访问权限的恶意用户或者恶意软件同样也可以获得存储的数据。因此,任何形式的客户端存储都不应该用来保存密码、商业账号或者类似的敏感信息。
还要记住一点:很多web用户不信任那些使用cookie和其它客户端存储机制来做类似“跟踪”功能的网站。所以,尽量尝试本章讨论的存储机制来网站升级用户体验;而不是用它们来收集和侵犯隐私相关的数据。如果网站滥用客户端存储,用户将禁用该功能。这样一来不仅达不到效果,还会导致依赖客户端存储的网站完全不可用。
实现了“web存储”草案标准的浏览器在window对象上定义了两个属性,localStorage和sessionStorage。在控制台输入window.localStrage可以获得页面所存储的数据。
这两个属性代表同一个Storage对象——一个持久化关联数组,数组使用字符串来索引,存储的值也是字符串形式的,Storage对象在使用上和一般的Javascript没有什么两样,设置对象的属性为字符串值,随后浏览器会将值存储起来。lcoalStorage和sessionStorage两者的区别在于存储的有效期和作用域不同:h数据可以存储多长时间及拥有数据的访问权。
示例:localStorage和sessionStorage类似
var name = localStorage.username; //查询一个存储的值 name = localStorage["username"]; //等于数组表示法 if (!name) { name = prompt("请输入你的名字"); //询问用户一个答案 localStorage.username = name; //存储用户的答案 } //迭代所有存储的name/value对 for (var name in localStorage) { //迭代所有存储的名字 var value = localStorage[name]; //查询每个名字对应的值 }
Storage对象还定义了一些诸如存储、获取、遍历和删除的方法。
“web存储”草案标准指出,我们既可以存储结构话的数据(对象和数组),也可以存储原始类型数据,还可以存储诸如日期、正则表达式甚至是文件对象在内的内置类型和数据。(在一些浏览器中,仅仅支持存储字符串类型数据,如果要存储和其它类型的书,不得不自己手动进行和编码解码),如下例子所示:
//当存储一个数字的时候,会自动转换成一个字符串 //但是,当获取该值的时候,别忘了手动转换成数字类型 localStorage.x = 10; var x = parseInt(localStorage.x); //同样,存储一个日期类型数据的时候进行编码,获取的时候进行解码 localStorage.lastRead = (new Date()).toUTCString(); var lastdate = new Date(Date.parse(localStorage.lastRead)); //使用JSON可以使得对基本数据类型的编码规则变得很方法 var data = new Date(); localStorage.data = JSON.stringify(data)//编码后存储 var data = JSON.parse(localStorage.data)//获取数值后再解码
通过localStorage存储的数据是永久性的,除非web应用立刻删除存储的数据。或者用户通过设置浏览器配置(浏览器提供的特定UI)来删除,否则数据将一直保留在用户电脑上,永不过期。
localStorage的作用域是限定在文档源(document origin)级别的。正如11章6节ii小节描述的,文档源是通过协议、主机名及端口三者来确定的。因此,每个url都有不同的文档源。
同源文档间共享localStorage数据(不论该源的脚本是否真正的访问的localStorage)。它们可以互相读取对方的数据,甚至可以覆盖对方的数据。但是,非同源的文档见互相都不能读取和共享或覆盖对方的数据(即使它们的脚本来自同一台第三方服务器也不行)。
需要注意的是localStorage的作用域也收到浏览器供应商的限制。如果你使用的Firefox访问站点那么下一次用另外一个浏览器打开的时候,那么本次是无法获取上次的数据的。
sessionStorage的有效期存储数据的脚本所在最顶层的窗口或者是浏览器标签页是一样的。一旦窗口或者标签页被永久关闭了,那么所有通过sessionStorage存储的数据也被删除了(需要注意的是,现代的浏览器具备了一些关闭标签页随后恢复上一次浏览器回话的功能,可能预知相关的sessionStorage会更长些)。
作用域也是限定在文档源中,因此,非同源的文档之间是无法贡献sessionStorage的。
需要注意的是:这里提到的基于窗口作用域的sessionStorage指的窗口是顶级窗口。如果一个浏览器标签包含两个<iframe>元素,它们是同源的,那么两者之间是可以共享的sessionStorage的。
原文:http://www.cnblogs.com/Chen-XiaoJun/p/6437741.html