JavaScript权威指南--客户端存储

客户端存储web应用容许使用浏览器提供的API实现将数据存储在用户电脑上。

客户端存储遵循“同源策略”，所以不一样站点的页面是没法读取对于存储的数据。而同一站点的不一样的页面之间是能够互相共享存储数据的。

同源策略能够拿localStorage来说，以下：

打开http://www.w3school.com.cn/

打开http://www.w3school.com.cn/html5/index.asp

数据都是保存在对应的域名http://www.w3school.com.cn/下的，当域名同源的时候，是能够访问到保存下来的数据的。

web应用能够选择他们存储数据的有效期：有临时存储的，可让数据保存至当前窗口关闭或浏览器退出；也有永久存储，能够将数据永久地存储在硬盘上，数年或者数月不失效。

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

web存储

　　先是HTML5的一个API，后来成了标准了。目前包含IE8在内的主流浏览器（可交互地）都实现了。包含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事件的机制），这样的方式多多少少都显得复杂。

文件系统API

　　前面介绍过现代的浏览器都支持一个文件对象，用以将选择的文件经过xmlHttPRequest上传到服务器。与之相关的规范（草案阶段）定义了一组API，用于操做一个私有的本地文件系统。该系统中，能够进行对文件的读写操做。目前正在标准化当中。

 

存储、安全和隐私

　　web浏览器一般会提供“记住密码”功能，这些密码会以加密的形式安全地存储在硬盘上。然而本章介绍的任何形式客户端数据存储都不牵扯加密：任何存储在用户硬盘上的数据都是未加密形式。这样一来，对于拥有电脑访问权限的恶意用户或者恶意软件一样也能够得到存储的数据。所以，任何形式的客户端存储都不该该用来保存密码、商业帐号或者相似的敏感信息。

      还要记住一点：不少web用户不信任那些使用cookie和其它客户端存储机制来作相似“跟踪”功能的网站。因此，尽可能尝试本章讨论的存储机制来网站升级用户体验；而不是用它们来收集和侵犯隐私相关的数据。若是网站滥用客户端存储，用户将禁用该功能。这样一来不只达不到效果，还会致使依赖客户端存储的网站彻底不可用。

1.localStorage和sessionStorage

      实现了“web存储”草案标准的浏览器在window对象上定义了两个属性，localStorage和sessionStorage。在控制台输入window.localStrage能够得到页面所存储的数据。

      这两个属性表明同一个Storage对象——一个持久化关联数组，数组使用字符串来索引，存储的值也是字符串形式的，Storage对象在使用上和通常的Javascript没有什么两样，设置对象的属性为字符串值，随后浏览器会将值存储起来。lcoalStorage和sessionStorage二者的区别在于存储的有效期和做用域不一样：数据能够存储多长时间及拥有数据的访问权。

示例：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)//获取数值后再解码

1.1.存储有效期和做用域

经过localStorage存储的数据是永久性的，除非web应用马上删除存储的数据。或者用户经过设置浏览器配置（浏览器提供的特定UI）来删除，不然数据将一直保留在用户电脑上，永不过时。

localStorage的做用域是限定在文档源（document origin）级别的。文档源是经过协议、主机名及端口三者来肯定的。所以，每一个url都有不一样的文档源。

同源文档间共享localStorage数据（不论该源的脚本是否真正的访问的localStorage）。它们能够互相读取对方的数据，甚至能够覆盖对方的数据。可是，非同源的文档见互相都不能读取和共享或覆盖对方的数据（即便它们的脚原本自同一台第三方服务器也不行）。

须要注意的是localStorage的做用域也收到浏览器供应商的限制。若是你使用的Firefox访问站点那么下一次用另一个浏览器打开的时候，那么本次是没法获取上次的数据的。

 

sessionStorage的有效期和存储数据的脚本所在最顶层的窗口或者是浏览器标签页是同样的。一旦窗口或者标签页被永久关闭了，那么全部经过sessionStorage存储的数据也被删除了（须要注意的是，现代的浏览器具有了一些关闭标签页随后恢复上一次浏览器回话的功能，可能预知相关的sessionStorage会更长些）。

做用域也是限定在文档源中，所以，非同源的文档之间是没法贡献sessionStorage的。不只如此，sessionStorage的做用域还被限定在窗口中。若是同源的文档渲染在不一样的浏览器标签页中，那么他们互相之间拥有的是各自的sessionStorage数据，没法共享。就是说，同个浏览器下两个相同的标签页也不能共享数据。

须要注意的是：这里提到的基于窗口做用域的sessionStorage指的窗口是顶级窗口。若是一个浏览器标签包含两个<iframe>元素，它们是同源的，那么二者之间是能够共享的sessionStorage的。

1.2.存储API

localStorage和sessionStorage一般是被当作普通的javascript对象使用。经过设置属性来存储字符串值，查询该属性来读取该值。这两个对象还提供了两个正式的API。

setItem()

getItem()

removeItem()（在非IE8的浏览器中，还可使用delete操做符来删除数据，就和普通对象使用的delete操做符同样）

clear()（不须要参数）

使用length和key()方法，传入0~length~1的数字，能够枚举全部存储数据的名字。

示例：

localStorage.setItem("x", 1); //以"x"的名字存储一个数值 localStorage.getItem("x"); //获取x的数值 
//枚举全部的存储的名字/值对 
for(var i = 0;i<localStorage.length;i++){//length 表示了全部名字/值对       
  var name = localStorage.key(i); //获取第i对的名字 
  var value = localStorage.getItem(name);//获取该对的值 
} 
localStorage.removeItem("x")//删除"x"项 
localStorage.clear();//所有删除

若是浏览器提供商彻底实现了“web存储”的标准，只对对象和数组类型的数据存储，那么就会又多了一个使用相似用setItem()和getItem()这类方法的理由。对象和数组的值一般是可变的，所以存储对象要求存储它们的副本，以确保以后对任何这类对象的改变不影响到存储的对象。一样的 ，在获取该对象的时候，也要求获取是该对象的副本，以确保已获取的对象的改动不会影响到存储的对象。而这类操做若是若是使用基于属性的API就会使人困惑。考虑以下这段代码（假设浏览器已经支持告终构化数据存储）。

localStorage.o = {x:1};//存储一个带有"x"属性的对象 
localStorage.o.x = 2; //试图设置该对象的属性值 
localStorage.o.x; //=>undefined x没有改变

......

目前还没彻底实现这个标准呢。

1.三、存储事件

不管何时，存储在localStorage或者sessionStorage的数据发生改变，浏览器都会在其它对该数据可见的窗口对象上出发存储事件（可是在对数据改变的窗口上是不出发的）。若是浏览器有两个标签页都打开了来自于同源的页面，其中一个在localStorage上存储了数据，那么在另一个标签页就会接受到一个存储事件。要记住，sessionStorage的做用域是限制在顶层窗口的，所以对于sessionStorage的改变只有相关牵连的窗口才会触发存储事件。像给已经存在的存储项设置一个如出一辙的值，或者是删除一个原本就不存在的项存储都是不会触发存储事件的。

为存储事件注册处理程序能够经过addEventListener()方法，（或者在IE下使用attachEvent方法）。在绝大多浏览器中，还能够给Window对象设置onstorage属性的方法，不过Firefox不支持该属性。

与事件相关的事件对象有5个很是重要的属性（遗憾的是IE8不支持他们）

key：被设置或移除项的键名。若是调用clear()函数，那么该属性值就为null.

newValue：保存该项新值；或者调用removeItem()时，该属性值为null。

oldvalue：改变或删除该项前，保存该项的原先值；当插入一个新项的时候，该属性值为null

storageArea：这个属性值就比如目标window对象上的locaStorage属性或者是sessionStorgae属性

url：触发该存储变化脚本所在的文档URL

最后，要注意的是：localStorage和sessionStorage存储机制都是广播机制的，浏览器会对目前正在访问的同源站点全部窗口发送消息。举个例子：若是一个用户要求网站中止动画效果时，那么该站点可能会在localStorage中存储该用户的首选项，这样依赖，之后再访问该站点的时候自动中止该动画效果了。由于存储了首选项，致使触发的一个存储事件让其它的同源页面也得到了一个用户请求。再好比，一个机遇web的图片编辑应用，一般容许在其它窗口中展示工具条。当用户选择一个工具的时候，应用就可使用localStorage来存储用户的当前状态，而后通知其它的窗口用户选择了新的工具。

 

2.cookies

cookie是指web浏览器存储少许的数据，同时它是与具体的web页面或者站点相关的。cookie是最先是设计为被服务端全部的，从底层来看，做为HTTP协议的一种扩展实现它。cookie数据会自动在web浏览器和web服务器之间传输的，所以服务端脚本就能够读、写客户端的cookie值。 

能够经过document.cookie来获取cookie值。

为何叫“cookie”？

并没太多含义。在javascript中，cookie用于保存状态以及可以为web浏览器提供一种身份识别（密码等）。可是，javascript中使用cookie不会采起任何加密机制，所以是不安全的。（可是经过https传说cookie数据是安全的，不过这和cookie自己无关，而和https：协议相关）。

操做cookie的api很早就已经定义和实现了，所以该API的兼容性很好。可是，该API几乎形同虚设。根本没有提供诸如查询、设置、删除cookie对象的方法，全部这些操做都要经过特殊格式的字符串形式读写Document对象的cookie属性来完成。每一个cookie的有效期和做用域均可以经过cookie属性分别指定。这些属性也是经过在同一个cookie上以特殊的字符串来设定的。

检测cookie是否可用

因为滥用第三方cookie（如cookie是和网页上的图片相关而非网页自己相关。第三方cookie指的是来自于当前访问站点觉得的站点设置的cookie）的缘故，致使cookie在大多数web用户心中有很差的印象。好比，广告公司能够利用第三方cookie来实现跟踪用户的访问行为和习惯，而用户为了禁止这种“窥探”用户隐私的行为会在它们的浏览器中禁用cookie。所以在使用avascript操做cookie前，首先要确保cookie是启用的。在绝大多数浏览器中，可用通检测过navigator.cookieEnabled这个属性来实现，若为true则代表cookie是启用的。由于该属性不是一个标准的属性，因此在不支持该属性的浏览器上，要用下面介绍的cookie技术来读、写和删除cookie数据来测试是否支持cookie。

2.1.cookie属性：有效期和做用域

除了名（name）和值（value），cookie还有一些可选的属性来控制cookie的有效期和做用域。cookie的默认有效期很短暂；它只在持续在web会话期间，一旦关闭浏览器，cookie的保存数据就丢失。须要注意的是这与sessionStorage有效期仍是有区别的，cookie的做用域并非限在浏览器的单个窗口中，它的有效期和整个浏览器进程不是单个浏览器窗口的有效期一一致。若是要延长cookie有效期，能够经过设置max-age属性，但必需要明确告诉cookie的有效期是多长，单位是秒。

一旦设置了有效期，浏览器就会将cookie数据存储在一个文件中，而且知道过了指定的有效期才会删除该文件。

和localStorage以及sessionStorage相似，cookie的做用域是经过文档源和文档路径来肯定的。该做用域经过cookie的path和domain属性配置的。在默认的状况下，cookie和建立它的web页面有关，并对该web页面及和该web页面同目录或者子目录其它的页面可见。好比web页面http://www.a.com/a/index.html页面建立了一个cookie，那么该cookie对http://www.a.com/a/b.html和页面http://www.a.com/a/b/index.html页面都是可见的。但对http://www.a.com/c.html是不可见的。

默认的cookie的可见性行为知足了最多见的需求。不过，有的时候，你可能但愿整个网站都使用cookie的值，而无论是那个页面建立它的。好比用户在一个页面表单上输入了它的邮件地址，你想把它保存下来，为了避免让用户下次回到这个页面上将其做为默认的邮件地址。要知足这样的需求，能够设置cookie的路径（设置cookie的path属性）。

将cookie的路径设置成"/"等因而让cookie和localStorage拥有一样的做用域，同时当它请求该站点上任何一个web页面的时候，浏览器都必须将cookie的名字和值传递给服务器。可是须要注意的是，cookie的path属性不能被用作访问控制机制。若是一个web页面想要读取同一站点其它页面的cookie，只须要将其余页面隐藏<iframe>形式加载进来，随后读取对应文档的cookie就能够了。同源策略限制了跨站的cookie窥探，可是对同一站点的文档是彻底合法的。

cookie的做用域默认由文档源限制。可是，有的大型网站想要子域之间可以相互通讯cookie，这个时候就须要设置coolkie的domian属性来达到目的。若是http://well.a.com的域下建立了一个cookie，并将其path属性设置成"/"，其domian属性设置成".a.com",那么这个cookie就对全部good.a.com，other.a.com以及任何其它a.com域下任何其它服务器均可见。若是没有为一个cookie设置域属性，那么domian属性的默认值是当前web服务器的主机名。要注意的是，cookie域只能设置当前服务器的域。

最后要介绍的cookie的属性是secure,它是一个布尔值属性，用来代表cookie的值是以何种网络传输。cookie默认是以不安全的形式（经过普通的、不安全的HTTP链接）传递的。一旦cookie被标识为“安全的”，那就只能当前浏览器和服务器经过https或者其它安全协议链接的时候才能传递它。

2.2.保存cookie

要给当前文档设置有效的cookie值，很是简单，只需将cookie属性设置为一个字符串的形式的值；

name = value;

以下：

document.cookie = "version=" + encodeURIComponent(document.lastModified);

下次读取cookie属性的时候，以前存储的名/值对的数据就在cookie列表中。因为cookie的名/值中不容许包含分号、逗号和空白符，所以，在存储以前通常能够采用javascript核心的全局函数encodeURIComponent()进行编码。相应的，读取cookie值的时候须要采用decodeURICompoent()函数解码。

以简单的名/值对形式存储的cookie数据有效期只在当前的web浏览器会话内，一但用户关闭浏览器，cookie数据就丢失了。若是小要延长cookie的有效期，就须要设置max-age属性来指定cookie的有效期（单位是秒）。按照下面的字符串形式设置cookie的属性便可。

name = value; max-age = seconds

下面设置一个cookie值，并提供一个max-age属性

//以名/值对形式存储cookie
//同时采用encodeURIComponet()函数进行编码，来转义分号、逗号和空白符
//若是dayTolive是一个数字，设置max-age属性为该数值表示cookie知道指定的天数
//到了才会过时。若是daysTolive是0就表示删除cookie
function setcookie(name, value, daysTolive) {
     var cookie = name + "=" + encodeURIComponent(value);
     if (typeof daysTolive === "number")
          cookie += "; max-age =" + (daysTolive * 60 * 60 * 24);
     document.cookie = cookie;
}
setcookie("cook","cool",0);

一样地，若是要设置cookie的path、domian和secure属性，只需以下的字符串追加在cookie的值的后面

;path = path
;domain = domian
;secure

要改变cookie的值，须要使用相同的名字、路径和域，可是新的值从新设置cookie的值。一样地，设置新max-age属性就能够改变cookie的有效期。

要删除一个cookie，须要使用相同的名字、路径和域，而后制定一个任意（非空）的值，并将max-age属性指定为0，再次设置cookie。

2.3.读取cookie

使用javascript表达式来读取cookie属性的时候，其返回的值是一个字符串，该字符串都是由一系列的名/值对组成，不一样名/值对之间经过“分号/空格”分开，其内容包含了全部做用在当前文档的cookie。可是当它不包含其它设置的cookie属性。经过document.cookie属性能够获取cookie的值，可是为了更好地查看cookie值，通常会采用split()的方法将cookie值中的名/值对都分离出来。

把cookie的值从cookie属性分离出来以后，必需要采用相应的解码方式（取决于以前存储cookie值时的采用的编码方式），把值还原出来。好比，先采用decodeURIComponent()方法把cookie的值解码出来，以后再利用JSON.parse()方法转换成json对象。

下面的例子定义了一个getcookie()函数，该函数将document.cookie属性的值解析出来，将对应的名/值存储到一个对象中，函数最后返回该对象。

/**解析document.cookie属性的值**/
//将document.cookie的值以名/值对组成一个对象返回
//假设存储cookie的值的时候是采用encodeURIComponent()编码的
function getcookie() {
    var cookie = {}; //初始化要返回的对象
    var all = document.cookie; //在一个大写的字符串中获取全部的cookie值
    if (all === "") //若是cookie为空字符串
        return cookie; //返回一个空对象
    var list = all.split(";"); //分离出名/值对
    for (var i = 0; i < list.length; i++) { //遍历每一个cookie
        var cookie = list[i];
        var p = cookie.indexOf("="); //查找第一个"="符号
        var name = cookie.substring(0, p); //获取cookie名字
        var value = cookie.substring(p + 1); //获取cookie对应的值
        value = decodeURIComponent(value); //对其值进行解码
        cookie[name] = value; //将名/值对存储到对象中
    }
    return cookie;
}

在wamp下测试，不能用，结果都会直接等于list而不是对象。cookie不能直接用啦，修改以下：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Document</title>
</head>
<body>
    <script type="text/javascript">
        
        function setcookie(name, value, daysTolive) {
            var cookie = name + "=" + encodeURIComponent(value);
            if (typeof daysTolive === "number")
                cookie += "; max-age =" + (daysTolive * 60 * 60 * 24);
            document.cookie = cookie;
        }
        setcookie("cook","cool",60);

        function getcookie() {
            var cookie = {}; //初始化要返回的对象
            var all = document.cookie; //在一个大写的字符串中获取全部的cookie值
            if (all === "") //若是cookie为空字符串
                return cookie; //返回一个空对象
            var list = all.split(";"); //分离出名/值对
            for (var i = 0; i < list.length; i++) { //遍历每一个cookie
                var cookieEle = list[i];
                var p = cookieEle.indexOf("="); //查找第一个"="符号
                var name = cookieEle.substring(0, p); //获取cookie名字
                var value = cookieEle.substring(p + 1); //获取cookie对应的值
                value = decodeURIComponent(value); //对其值进行解码
                cookie[name] = value; //将名/值对存储到对象中
            }
            return cookie;
        }
        console.log(getcookie());
    </script>
</body>
</html>

2.4.cookie的局限性

cookie的设计初衷是给服务端脚本用来存储少许的数据的，该数据会在每次请求一个相关的URL时传递到服务器中。RFC2965鼓励浏览器供应商对cookie的数据大小不作限制。但是，要知道，该标准不容许浏览器保存超过300个cookie，为每一个web服务器保存的cookie数不能超过20个（是对整个服务器而言，而不只仅指服务器上的页面和站点），并且，每一个cookie保存的数据不能超过4k。实际上，现代浏览器容许cookie总数超过300个，可是部分浏览器对单个cookie大小仍然有4k的限制。

2.5.cookie相关存储

例：定义一个cookieStorage函数，经过将max-age和path属性传递给该构造函数，经过将max-age和path属性传递给该构造函数，就会返回一个对象，而后就能够像使用localStorage属性或sessionStorage同样来使用这个对象。可是要注意的是，该例并无实现存储事件，所以，当设置和查询cookieStorage对象的属性的时候，不会实现自动保存和获取对应的值。

实现基于cookie的API。

 

3.利用IE userdata持久化数据

IE以及IE5以上的浏览器是经过在document元素后附件一个专属的"DHTML行为"来实现客户端存储的。以下代码所示：

var memory = document.createElement("div"); //建立一个元素
memory.id = "_memory";
memory.style.display = "none";
memory.style.behavior = "url('default#userData')"; //附加userData行为
document.body.appendChild(memory); //添加到document元素中

一旦元素赋予了"userData"行为，该元素就拥有load()和save()方法。load()方法用于载入存储的数据。使用它的时候必须传递一个字符串做为参数--相似一个文件名，该参数用来指定要载入的存储数据。当数据载入后，就能够经过该元素的属性来访问这些名/值对形式的数据，可使用gettAttribute()来查询摄像数据。经过setAttribute()方法设置属性。而后调用save()方法能够存储新的数据；而要删除数据，经过使用removeAttribute()方法而后调用save()方法便可。以下所示（该例使用了此前例子中初始化的那个memory元素）：

memory.load("mySoredData"); //根据指定名，载入对于的数据
var name = memory.getAttribute("username"); //获取其中数据片断
if (!name) { //若是没有指定的数据片断
    name = prompt("请输入"); //
    memory.setAttribute("username", name); //将其设置成memory元素的一个属性
    memory.save("mySoredData")
}

默认状况下，经过userData存储的数据，除非手动去删除它不然永不失效。可是，也能够经过设置expires属性来指定它的过时时间。就拿上面的例子来讲，能够给存储的数据设置时长为100天的有效期，以下所示：

var now = (new.Date()).getTime(); //获取当前时间，以毫秒为单位
var expires = now + 100 * 24 * 60 * 60 * 1000; //100天的毫秒算法
expires = new Date(expires).toUTCString(); //将其转换为字符串。
memory.expires = expires; //设置userData的过时时间

IE userData的做用域限制在和当前文档同目录的文档中。它的做用域没有cookie宽泛，cookie对其所在目录下的子目录也有效。userData的机制并无像cookie那样，经过设置path和domain属性来控制或改变其做用域的方式。

userData容许存储的数据量要比cookie大，可是却比localStorage和sessionStorage容许的存储量的数据量要小。

下面的例子基于IE的userData实现存储了API提供的getItem(),setItem()以及removeItem()方法（可是它没有实现key()或者clear()方法，缘由是userData并无定义遍历全部存储项的一种方法）。

。。。。。。

因为上述代码只在IE浏览器下有效，最好使用IE条件注释来避免其余浏览器载入上述代码。

<!--[if IE]>
<script src="userDataStorage.js"></script>
<![endif]-->

 4.应用程序存储和离线Web应用

HTML5中新增了“应用程序缓存”，容许web应用程序自身本地保存到用户的浏览器中。不像localStorage和sessionStorage只是保存web应用程序相关的数据，它是将应用程序自身保存起来----应用程序所需运行的全部文件（HTML、CSS、JavaScript、图片等）。“应用程序缓存”和通常的浏览器缓存不一样：它不会随着用户清除浏览器缓存而被清除。同时，缓存起来的应用程序也不会像通常固定大小的缓存那样，老数据会被最近一次访问的新数据代替掉。它其实不是临时存储在缓存中：应用程序更像是被“安装”在那里，除非被用户“卸载”或“删除”它们，不然，它们就会一直“驻扎”在那里。因此说，“应用程序缓存”在真正意义上不是“缓存”更好的说法应该称之为“应用程序存储”。

让web应用可以实现“本地安装”的目的是要保证它们可以在离线状态（好比，当在飞机或者手机没信号的时候）下依然可访问。将本身“安装”到应用程序缓存中的Web应用，在离线状态下使用localStorage来保存应用相关的数据，同时还具有一套同步机制，在再次回到在线状态的时候，可以将存储的数据传输给服务器。

4.1.应用程序缓存清单

想要将应用程序“安装”到应用程序缓存中，首先要建立一个清单：包含全部应用程序依赖的全部url列表。而后，经过在应用程序主HTML页面的<html>标签中设置manifest属性，指向到清单文件就能够了：

 <!DOCTYPE HTML>
 <html manifest=”myapp.appcache”>
 <head>…</head>
 <body>…</body>
 </html>

清单文件中的首行内容必须以”CACHE MANIFEST”字符串开始。其他就是要缓存的文件URL列表，一行一个URL。相对路径的URL都相对于清单文件的URL  。会忽略内容中的空行，会做为注释而忽略以”#”开始的行。注释前面能够有空格，但同在同一行注释后面是不容许有非空字符串的。

好比：

CACHE MANIFEST
#上面一行标识此文件是一个清单文件。本行是注释
# 下面的内容都是应用程序依赖的资源文件的URL
myapp.html
myapp.js
myapp.css
images/background.png

补充：

缓存清单的MIME类型：
应用程序缓存清单文件约定以.appcache做为文件扩展名。可是，这也仅仅只是约定而已，web服务器真正识别清单文件的方式是经过”text/cache-manifest”这个MIME类型的一个清单。若是服务器将清单文件的Content-Type的头信息设置成其余MIME类型，那么就不会缓存应用程序了。所以，可能须要对web服务器作必定的配置来使用这个MIME类型，好比，在Web应用目录下建立Apache服务器的一个.htaccess文件

清单文件包含要缓存的应用的标识。若是一个Web应用有不少web页面，那么每一个html页面就须要设置<html manifest=>属性来指向清单文件。事实上，将这些不一样的页面都指向同一个清单文件，可能很清楚地表达出它们都是须要缓存起来的，同时它们又是来自同一个web应用的。若是一个应用只有少许的html页面，那么通常会把这些页面都显示地列在清单文件中。但这不是强调的，会认为任何连接到清单文件的文件都是web应用的一部分，并会随着应用一块儿缓存起来。

像以前提到的，一个简单的清单必须列出web应用依赖的全部资源。一旦一个Web应用首次下载下来并缓存，以后的任何加载请求都来自缓存。从缓存中去载入一个应用资源的时候，就要求它请求的资源务必要在清单中。不会载入不在清单的资源。这种政策有点离线的味道。若是一个简单的缓存起来的应用可以从缓存中载入并运行，那么它也能够在浏览器的离线状态下运行。一般状况下，不少复杂的web应用没法将它们依赖的全部资源都缓存起来。可是，若是它们同时也有一个复杂的清单的话，它们仍然可能使用应用程序缓存。

复杂的清单

清单文件还有比这更复杂的语法，列举资源的方式也还有另外两种。在清单文件中可使用特殊的区域头（译者注：相似于HTTP头）来标识该头信息以后清单项的类型。像该例中列举的简单缓存项事实上都属于“CACHE:”区域，这也是默认的区域。另外两种区域是以“Network:”和”FALLBACK:” 头信息开始的（一个清单文件能够有任意数量的区域，并且能够相邻两个区域之间能够根据须要相互切换）。

“NETWORK:”区域标识了该区域中的资源从不缓存，总要经过网络获取。一般，会将一些服务端的脚本资源放在”NETWORK:”区域中，而通常该区域中的资源的URL都只是URL前缀，用来表示以此URL前缀开头的资源都应该要经过网络加载。”NETWORK:”区域中的URL还支持”*”通配符。该通配符表示对任何不在清单中的资源，浏览器都将经过网络去获取。这实际上违背了这样一条规则：缓存应用程序必需要在清单中列举全部应用相关的资源！

“FALLBACK:”区域中的清单项每行都包含两个URL。第二个URL是指须要缓存起来的资源，第一个URL是一个前缀。任何可以匹配到该前缀的资源都不会缓存起来，可是可能的话，他们会从网络中载入。若是从网络中载入失败的话，会使用第二个URL指定的资源来代替，从缓存中获取。想象一个应用包含了必定数量的视频教程。这些视频都很大，显然把他们缓存到本地是不合适的。所以，在离线状态下，经过清单文件中的fallback区域，就可使用一些文本类的帮助文档来代替了。

示例

CACHE MANIFEST

CACHE: 
myapp.html 
myapp.css 
myapp.js

FALLBACK: 
videos/ offline_help.html

NETWORK: 
cgi/

4.2.缓存的更新

当一个web应用从缓存中载入的时候，全部与之相关的文件也是直接从缓存中获取。在线状态下，浏览器会异步检查是否清单文件有更新。若是有更新，新的清单文件以及全部清单中列举的文件都会下载下来从新保存到应用程序缓存中。可是，要注意的是，浏览器只是检查清单文件，而不会去检查缓存的文件是否有更新：只检查清单文件。比方说，你修改了一个缓存的JavaScript文件，要想让该文件生效，就必须去更新下清单文件。因为应用程序依赖的文件列表其实并无变化，所以最简单的方式就是更新版本号：

CACHE MANIFEST 
# MyApp version 1 (更改这个数字以便让浏览器从新下载这个文件)        
MyApp.html 
MyApp.js

一样的，若是想要让web应用从缓存中“卸载”，要在服务器端删除清单文件，使得请求该文件的时候返回HTTP 404 没法找到 的错误，同时，修改HTML文件与该清单列表“断开连接”。

要注意的是，浏览器检查清单文件以及更新缓存的操做是异步的，多是在从缓存中载入应用以前，也有可能同时进行。所以，对于简单的web应用而言，在你更新清单文件以后，用户必须载入应用两次才能保证最新的版本生效：第一次是从缓存中载入老版本随后更新缓存，第二次才从缓存中载入最新的版本。

浏览器在更新缓存过程当中会触发一系列事件，你能够经过注册处理程序来跟踪这个过程同时提供反馈给用户。 

......

4.3.离线web应用

离线web应用指的是将本身“安装”在应用程序缓存中的程序，使得哪怕在浏览器处于离线状态时候依然可访问。举个最简单的例子——相似时钟和万花筒生成器这样的应用——这是web应用要离线可用须要作的事情。可是，大多数web用也须要向服务器上传数据：哪怕是简单的游戏应用都有可能须要上传用户的最高得分到服务器。这类应用也能够成为离线应用。他们可使用localStorage来存储应用数据，而后当在线的时候再将数据上传到服务器。在本地存储和服务器端同步数据是将Web应用转变为离线应用最巧妙的环节，特别是当用户须要从多台设备获取数据的时候。

为了在离线状态可用，web应用须要能够告知别人本身是离线仍是在线，同时当网络链接的状态发生改变时候也能“感知”到。经过navigator.onLine属性，能够检测浏览器是否在线，同时，在Window对象上注册在线和离线事件处理程序，能够检测网络链接状态的改变。

一个简单的记事本程序

 

20170420补充

浏览器对于存储数据的大小有限制，限制的大小广泛在5M/域，超出则会报Uncaught QuotaExceededError错误。所以在开发时应注意控制存储数据保持在限制大小内，并定时清除无用的数据。若要手动删除数据，Chrome浏览器可至chrome://settings/cookies 查看不一样网站已使用本地存储的占用空间状况，并进行删除操做。