支持离线 Web 应用开发是 HTML5 的另一个重点。所谓离线 Web 应用，就是在设备不能上网的情况下仍然可以运行的应用。
开发离线Web 应用需要几个步骤。首先是确保应用知道设备是否能上网，以便下一步执行正确的操作。然后，应用还必须能访问一定的资源（图像、Javascript、CSS等），只有这样才能正常工作。最好，必须有一块本地空间用户保存数据，无论能否上网都不妨碍读写。
HTML5 及其相关的 API让开发离线应用成为现实。
离线检测
要知道设备是否在线还是离线，HTML5 定义了一个 navigator.onLine 属性，这个属性值为 true 表示设备能上网，值为 false 表示设备离线。
1 2 3 4 5 |
|
由于 navigator.onLine 存在一定的兼容性问题，因此除了 navigator.onLine 属性之外，为了更好地确定网络是否可用，HTML5 还定义了两个事件 online 和 offline。
当网络在离线和在线之间切换时在 window 对象上触发这两个事件：
1 2 3 4 5 6 7 |
|
在实际应用中，最好在页面加载后，最好先通过 navigator.onLine 取得初始的状态。然后通过上述两个事件来确定网络连接状态是否变化。当上述事件触发时，navigator.onLine 属性的值也会改变，不过必须要手工轮询这个属性才能检测到网络状态的变化。
应用缓存
HTML5 的应用缓存（application cache），或者简称为 appcache，是专门为开发离线 Web 应用而设计的。Appcache 就是从浏览器的缓存中分出来的一块缓存区。要想在这个缓存中保存数据，可以使用一个描述文件（manifest file），列出要下载和缓存的资源。描述文件示例：
1 2 3 4 5 |
|
然后在 html 中引用：
1 |
|
xxx.manifest 文件的 MIME 类型必须是 text/cache-manifest。
该 API 的核心是 applicationCache 对象，这个对象有一个 status 属性，属性的值是常量，表示应用缓存的如下当前状态：
0： 无缓存，即没有与页面相关的应用缓存
1： 闲置，即应用缓存未得到更新
2： 检查中，即正在下载描述文件并检查更新
3： 下载中，即应用缓存正在下载描述文件中指定的资源
4： 更新完成，即应用缓存已经更新了资源，而且所有资源都已下载完毕，可以通过 swapCache() 来使用了
5： 废弃，即应用缓存的描述文件已经不存在了，因此页面无法再访问应用缓存
相关事件：
checking： 在浏览器为应用缓存查找更新时触发
error： 在检查更新或者下载资源期间发生错误时触发
noupdate： 在检查描述文件发现文件无变化时触发
downloading： 在开始下载应用缓存资源时触发
progress： 在文件下载应用缓存的过程中持续不断地触发
updateready： 在页面新的应用缓存下载完毕且可以通过 swapCache() 使用时触发
cached： 在应用缓存完整可用时触发
一般来讲，这些事件会随着页面加载按上述顺序依次触发。也可以通过调用 update() 方法手动触发上述事件。
数据存储
Cookie
HTTP Cookie，通常直接叫做 cookie，是在客户端用于存储会话信息的。该标准要求服务器对任意 HTTP 请求发送 Set-Cookie HTTP 头信息作为响应的一部分，其中包含会话信息。服务器响应头示例：
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value
Other-header: other-header-value
然后浏览器 Set-Cookie 的会话信息，之后为每个请求添加 Cookie HTTP 头将信息发送回服务器，如下所示：
GET /index.html HTTP/1.1
Cookie: name=value
Other-header: other-header-value
发送回服务器的额外信息可以用于唯一验证客户来自于发送的哪个请求。
完整的 cookie 包括：
名称： 一个唯一确定 cookie 的名称。必须被 URL 编码。
值： 存储在 cookie 中的字符串值。必须被 URL 编码。
域： cookie 对于哪个域是有效的。
路径： 对于指定域中的那个路径，应该向服务器发送 cookie。
失效时间： 表示 cookie 何时应该被删除的时间戳。
安全标志： 指定后，cookie 只有在使用 SSL 连接的时候才发送到服务器。
复制代码
代码如下:
1 |
|
基本用法
在 JavaScript 中操作 cookie 有些复杂，这是因为 document.cookie 属性在不同的使用方式中表现出不同的行为。
当用来获取属性值时，document.cookie 返回当前页面可用的所有 cookie 字符串，一系列由分号隔开的键值对，如下所示：
1 2 |
|
当用来设置值时，document.cookie 属性会设置一个新的 cookie 字符串添加到现有的 cookie 集合中，并不会像普通对象设置属性一样覆盖原 cookie 的值，除非设置的 cookie 的名称已经存在，如下所示：
1 2 3 4 5 6 7 |
|
从上面的代码我们可以看出，我们要读取或者修改或者删除指定 cookie 的值都不是很直观方便，因此我们可以封装一些方法，方便我们对 cookie 的操作：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 |
|
使用方法：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
大小限制
每个域的 cookie 总数是有限，不同浏览器之间所有不同，IE6 以下是最多 20 个，IE7 以上最多 50 个，Firefox最多 50 个，Opera 最多 30 个，Safari 和 Chrome 不限制。
cookie 的尺寸也有限制，大多数浏览器有大约 4096B。
Web Storage
Web Storage 的目的是克服由 cookie 带来的一些限制，当数据需要被严格控制在客户端上时，无须持续地将数据发回服务器。Web Storage 的两个主要目标是：
提供一种在 cookie 之外存储会话数据的路径。
提供一种存储大量可以跨会话存在的数据的机制。
Web Storage 主要定义了两种对象：sessionStorage 和 localStorage，是 Storage 对象的实例，这两个对象区别如下：
sessionStorage： 存储特定于某个会话的数据，也就是该数据只保持到浏览器关闭。存储数据大小大多数限制在 2.5M，少数浏览器限制在 5M 或者不限制。
localStorage： 数据保存到通过 JavaScript 删除或者是用户清除浏览器缓存。存储数据大小大多数限制在 5M，少数浏览器限制在 2.5M 或者不限制。
Storage 类型有如下方法：
clear()： 删除所有值。
getItem(name)： 根据指定的名字 name 获取对应的值。
key(index)： 获取 index 位置处的值的名字。
removeItem(name)： 删除由 name 指定的键值对。
setItem(name, value)： 为指定的 name 设置一个对应的值，值为字符串。
对 sessionStorage 和 localStorage 进行操作都会触发 storage 事件，该事件对象有以下属性：
domain： 发生变化的存储空间的域名。
key： 设置或者删除的键名。
newValue： 如果是设置值，则是新值；如果是删除键，则是null。
oldValue： 键被更改之前的值。
IndexedDB
Indexed Database API，简称为 IndexedDB，是在浏览器中保存结构化数据的一种数据库。其思想是创建一套 API，方便保存和读取 JavaScript 对象，同时还支持查询和搜索。
IndexedDB 设计的操作完全是异步进行的。因此，大多数操作会以请求方式进行。
基本用法
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 |
|
限制
和 Web Storage类似，只能由同源（相同协议、域名和端口）页面操作，因此不能跨域共享信息。
Firefox 大小上限为 50M，移动端的 Firefox 大小上限为 5M，不允许本地文件访问。
Chrome 大小上限为 5M，允许本地文件访问。
以上就是HTML5离线应用与客户端存储的实现的详细内容，更多请关注php中文网其它相关文章！
