Client-Side Storage
Web applications can use browser APIs to store data locally on the userrsquo;s computer.
This client-side storage serves to give the web browser a memory. Web apps can store
user preferences, for example, or even store their complete state, so that they can resume
exactly where you left off at the end of your last visit. Client-side storage is segregated
by origin, so pages from one site canrsquo;t read the data stored by pages from another site.
But two pages from the same site can share storage and can use it as a communication
mechanism. Data input in a form on one page can be displayed in a table on another
page, for example. Web applications can choose the lifetime of the data they store: data
can be stored temporarily so that it is retained only until the window closes or the
browser exits, or it can be saved to the hard drive and stored permanently, so that it is
available months or years later.
There are a number of forms of client-side storage:
Web Storage
Web Storage is an API that was originally defined as part of HTML5 but was spun
off as a standalone specification. That specification is still in draft form, but it is
partially (and interoperably) implemented in all current browsers including IE8.
This API consists of the localStorage and sessionStorage objects, which are essentially
persistent associative arrays that map string keys to string values. Web
Storage is very easy to use, is suitable for storing large (but not huge) amounts of
data, and is available on all current browsers, but it is not supported by older
browsers. localStorage and sessionStorage are covered in sect;20.1.
Cookies
Cookies are an old client-side storage mechanism that was designed for use by
server-side scripts. An awkward JavaScript API makes cookies scriptable on the
client-side, but they are hard to use and are suitable only for storing small amounts
of textual data. Also, any data stored as cookies is always transmitted to the server
with every HTTP request, even if the data is only of interest to the client. Cookies
continue to be of interest to client-side programmers because all browsers, old and
new, support them. Once Web Storage is universally available, however, cookies
will revert to their original role as a client-side storage mechanism for server-side
scripts. Cookies are covered in sect;20.2.
IE User Data
Microsoft implements its own proprietary client-side storage mechanism, known
as “userData,” in IE5 and later. userData enables the storage of medium amounts
of string data and can be used as an alternative to Web Storage in versions of IE
before IE8. The userData API is covered in sect;20.3.
Offline Web Applications
HTML5 defines an “Offline Web Applications” API that allows the caching of web
pages and their associated resources (scripts, CSS files, images, and so on). This is
client-side storage for web applications themselves rather than just their data, and
it allows web apps to install themselves so that they are available even when there
is no connection to the Internet. Offline web apps are covered in sect;20.4.
Web Databases
Developers who need to work with really huge amounts of data like to use data-
bases, and the most recent browsers have started to integrate client-side database
functionality into their browsers. Safari, Chrome, and Opera include a client-side
API to a SQL database. The standardization effort for that API has failed, however,
and it is unlikely to be implemented by Firefox or IE. An alternative database API
is being standardized under the name “Indexed Database API.” This is an API to
a simple object database without a query language. Both of the client-side database
APIs are asynchronous and require the use of event handlers, which makes them
somewhat complicated. They are not documented in this chapter, but see sect;22.8
for an overview and an example of the IndexedDB API.
Filesystem API
We saw in Chapter 18 that modern browsers support a File object that allows user-
selected files to be uploaded through an XMLHttpRequest. Related draft standards
define an API for obtaining a private local filesystem and for reading and writing
files from and to that filesystem. These emerging APIs are described in sect;22.7. When
they are more widely implemented, web applications will be able to use the kind
of file-based storage mechanisms that are already familiar to many programmers.
Storage, Security, and Privacy
Web browsers often offer to remember web passwords for you, and they store them
safely in encrypted form on the disk. But none of the forms of client-side data storage
described in this chapter involve encryption: anything you save resides on the userrsquo;s
hard disk in unencrypted form. Stored data is therefore accessible to curious users who
share access to the computer and to malicious software (such as spyware) that exists
on the computer. For this reason, no form of client-side storage should ever be used
for passwords, financial account numbers, or other similarly sensitive information. Re-
member: just because a user types something into a form field when interacting with
your website doesnrsquo;t mean that he wants a copy of that value stored on disk. Consider
a credit card number as an example. This is sensitive information that people keep hidden in their wallets. If you save this information using client-side persistence, it is almost as if you wrote the credit card number on a sticky note and stuck it to the userrsquo;s keyboard.
Also, bear in mind that many web users mistrust websites that use cookies or other
clien
全文共32715字，剩余内容已隐藏，支付完成后下载完整资料
客户端存储
Web应用程序可以使用浏览器提供的API将数据存储在用户的计算机上。这种客户端存储用于向Web浏览器提供了记忆功能。例如，Web应用可以存储用户偏好，甚至存储他们的完整状态，以便完全恢复用户最后一次访问时访问的页面。客户端存储的信息根据它的来源被隔离，所以来自一个站点的页面无法读取来自另一个站点的页面存储的数据。但是同一网站的两个页面可以共享存储数据，并可将其用作通信机制。例如一个页面上表单中的数据输入可以显示在另一个页面的表单中，Web应用程序可以选择其存储的数据的有效期：数据可以临时存储，以便仅在窗口关闭或浏览器退出，或者它可以保存到硬盘驱动器永久存储，这样就可以了使用数月或数年。
这里有几种客户端存储的方式。
- Web存储
Web存储是一种API，最初被定义为HTML5的一部分，但是被剥离后作为一个独立的规范。该规范仍然是草案形式，但它的一部分已经在所有当前的浏览器（包括IE8）中实现了。该API由localStorage和sessionStorage对象组成，它们是持续化的关联数组，将字符串的键映射到字符串的值。Web存储非常易于使用，适合存储大量（但不是巨大）的数量数据，并且在所有当前浏览器上可用，但不支持旧版本浏览器。localStorage和sessionStorage在20.1中有介绍。
- Cookie
Cookie是一种旧的客户端存储机制，为服务器端脚本而专门设计的。在客户端这种尴尬的JavaScript API可以操作cookie，但它们很难使用，仅适用于存储少量的文字资料。 此外，任何以Cookie存储的数据在每次HTTP请求时都会传输到服务器，即使数据只是客户感兴趣的。Cookie仍被客户端程序员使用是因为所有的浏览器，不管是旧的还是新的都支持它。然而，随着Web存储的普及，Cookie将作为服务器端的客户端存储机制，即恢复到其原始角色中。Cookies在20.2中有介绍。
- IE user Data
Microsoft在IE5及更高版本中实现了自己专有的客户端存储机制——“userData”。 userData可以存储中等数量的字符串数据，可以在IE8之前的版本中用作Web存储的替代品。 userData API在20.3中有所描述。
- 离线Web应用
HTML5中定义了一个“离线Web应用程序”的API页面，用于缓存Web页面及其相关资源（脚本，CSS文件，图像等）。这种客户端存储实现的是Web应用程序本身，而不仅仅是它们的数据，所以它允许网络应用程序即使没有连接到互联网也能自己安装。20.4涵盖了离线网络应用程序。
- Web数据库
需要使用真正大量数据的开发人员喜欢使用数据库，所以很多最新的浏览器已经开始整合客户端数据库功能进入他们的浏览器。Safari，Chrome和Opera都包括了SQL数据库的客户端API。然而，该API的标准化工作失败了，并且它不太可能被Firefox或IE实现。 另一种数据库API正在以“Indexed Database API”的形式进行标准化，这是一个没有查询语言的简单对象数据库的API。两个客户端数据库API是异步的，需要使用事件处理程序，这使得它们的实现可能有点复杂。本章对它没有记载，但是22.8章包含有关概述和索引数据库 API的示例。
- 文件系统API
我们在第18章看到，现代浏览器支持一个File对象，它允许通过XMLHttpRequest上传所选文件。相关草案标准定义了一个API，用于实现一个私有的本地文件系统，以及从这个文件系统上读写文件。这些新兴API在22.7中有描述。随着他们被更加广泛的实现，网络应用程序将能够使用这种许多程序员已经熟悉的基于文件的存储机制。
存储、安全和隐私
Web浏览器通常提供记住您的网络密码的功能，并将其以加密形式安全地存储在磁盘上。但是，本章中描述的客户端数据存储没有一种形式涉及加密：您保存的任何内容都以未加密的形式驻留在用户的硬盘上。因此拥有计算机的访问权限和计算机上存在的恶意软件（如间谍软件）可以访问存储的数据。因此，不应将任何形式的客户端存储用于保存密码，财务帐号或其他类似的敏感信息。记住：用户在与网站进行交互时将信息输入到表单中，并不意味着他想要把信息存储在硬盘上。以信用卡号码为例，这是人们隐藏在钱包中的敏感信息。如果您使用客户端持久性保存此信息，则几乎就像在便笺上写入信用卡号码，并将其粘贴到用户的键盘上。
另外，请记住许多Web用户不信任那些使用Cookie或其他客户端存储机制进行类似于“跟踪”的任何操作的网站。所以尝试使用本章讨论的存储机制来增强用户在您的站点的体验;不要将其用作侵犯隐私的数据收集机制。如果太多的站点滥用客户端存储，用户将禁用它或频繁地清除它，这不仅完成不了目的并使依赖于它的站点不可用。
20.1 localStorage 和 sessionStorage
实现“Web存储”草案规范的浏览器定义了Window对象上的两个属性：localStorage和sessionStorage。这两个属性都指的是一个Storage对象，一个将字符串键映射到字符串值的持久关联数组。 存储对象的工作方式与常规JavaScript对象非常相似：只需将对象的属性设置为字符串，浏览器将为您存储该字符串。 localStorage和sessionStorage之间的区别与生命周期和范围有关，即数据的保存时间和数据可访问的时间。
下面更详细地说明存储寿命和范围。首先，我们来看一些例子。以下代码使用localStorage，但它也可以对sessionStorage使用：
var name = localStorage.username; // 查询一个存储的值
name = localStorage['username']; // 等价于数组表示法
if (!name) {
name = prompt('What is your name?'); // 询问用户一个问题
localStorage.username = name; // 存储用户的答案
}
//迭代所有存储的name/value 对
for(var name in localStorage) { // 迭代所以存储的名字
var value = localStorage[name]; // 查询每个名字对应的值
}
存储对象还定义了存储，检索，迭代和删除数据的方法。这些方法在20.1.2中有所描述。
Web Storage草案规范说，我们应能存储结构化数据（对象和数组）以及原始数据类型和如日期、正则表达式甚至File对象在内的内置类型。然而，在撰写本文时，浏览器只允许存储字符串。如果要存储和检索其他类型的数据，则必须对其进行编码和解码。
20.1.1 存储有效期和作用域
localStorage和sessionStorage之间的区别涉及存储的使用寿命和范围。通过localStorage存储的数据是永久性的：它不会过期，并保留在用户的计算机上，直到Web应用程序删除它或用户要求浏览器（通过某些特定于浏览器的UI）将其删除。
localStorage的作用域限于同一来源的文档。如第13.6.2节所述，文档来源由其协议，主机名和端口定义，因此以下每个以下URL具有不同的来源：
http://www.example.com //协议：http; 主机名：www.example.com
https://www.example.com //不同的协议
http://static.example.com //不同的主机名
http://www.example.com:8000 //不同的端口
具有相同来源的所有文档共享相同的localStorage数据（不管实际访问localStorage的脚本的来源）。他们可以读取彼此的数据，甚至可以覆盖对方的数据。但是具有不同来源的文档永远不会读取或覆盖彼此的数据（即使它们都运行来自同一第三方服务器的脚本）。
请注意，localStorage也是浏览器供应商的范围。如果您使用Firefox访问网站，然后再使用Chrome（例如）访问，则在第一次访问期间存储的任何数据在第二次访问期间将无法访问。
通过sessionStorage存储的数据的有效期与通过localStorage存储的数据的有效期不同：前者存储的脚本运行在顶层窗口或浏览器选项卡中具有相同的使用寿命。当窗口或选项卡被永久关闭时，通过sessionStorage存储的任何数据都将被删除。（请注意，现代浏览器可以重新打开最近关闭的标签页并恢复最后一个浏览会话，因此这些标签及其关联的sessionStorage的生命周期可能比看起来更长。）
像localStorage一样，sessionStorage的作用域也被限定在相同的文档来源，这样不同来源的文件不会共享sessionStorage。但是，sessionStorage还被限定在窗口中。如果同一来源的文档显示在两个不同的浏览器选项卡，则这两个选项卡具有单独的sessionStorage数据：在一个选项卡中运行的脚本无法读取或覆盖另一个选项卡中的脚本编写的数据，即使两个选项卡正在访问相同的页面并且正在运行完全相同的脚本。
请注意，这个基于窗口的sessionStorage的范围仅适用于顶级窗口。 如果一个浏览器选项卡包含两个lt;iframegt;元素，并且这些框架使两个文档同源，则这两个框架文档将共享sessionStorage。
20.1.2 存储API
localStorage和sessionStorage通常被当做常规的JavaScript对象一样使用：通过设置一个属性来存储一个字符串，并通过查询该属性来检索值。 但是这些对象也定义了一个更加正式的基于方法的API。 要存储值，请将名称和值传递给setItem()。 要检索一个值，将该名称传递给getItem()。要删除一个值，请将该名称传递给removeItem()。（在大多数浏览器中，您也可以使用delete操作符来删除一个值，就像普通对象一样，但这种技术在IE8中无效）要删除所有存储的值，请调用clear()方法（没有参数）。最后，要枚举所有存储值的名称，请使用length属性，并将数字从0到长度-1传递给key()方法。 以下是使用本地存储的一些示例。这些代码对sessionStorage也可以使用：
localStorage.setItem（“x”，1）; //用“x”的名字存储数字
localStorage.getItem（“x”）; //获取数值
//枚举所有存储的键/值对
for（var i = 0; i lt;localStorage.length; i ）{// Length给出了键值对数目
var name = localStorage.key（i）; //获取第i对的名字
var value = localStorage.getItem（name）; //获取该对的值
}}
localStorage.removeItem（“x”）; //删除“x”项
localStorage.clear（）; //删除所有项
虽然通过设置和查询属性来存储和检索值通常更方便，但有时您可能想要使用上面这些方法。首先，clear()方法没有等效的方法，是删除所有存储对象中的值对。类似地，removeItem()方法是删除单个名称/值对的唯一便捷方式，因为IE8不支持使用delete操作符。
如果浏览器供应商完全实现了标准，并允许将对象和数组存储在存储对象中，那么就又多了一个使用setItem()和getItem()等方法的理由。对象和数组的值通常是可变的，所以当存储一个值时，需要一个存储对象来创建副本，以便对原始值的任何后续更改对存储对象没有影响。当检索一个值时，还需要使用“存储”对象进行复制，以便对检索到的值所做的任何更改对存储的值都没有影响。所以当进行这种复制时，使用基于属性的API可能会令人困惑。考虑一下（假设浏览器支持结构化值）代码：
localStorage.o = {x：1}; //存储具有属性x的对象
localStorage.o.x = 2; //尝试设置存储对象的属性
localStorage.o.x // =gt; 1：x不变
上面的第二行代码想要设置存储对象的属性，但是检索到的是存储对象的副本，在该复制对象中设置一个属性，然后就丢弃副本。 存储的对象本身保持不变。如果我们在这里使用getItem()，那么就不会那么混淆：
localStorage.getItem(“o”).x = 2; //我们不希望存储2
最后，使用基于显式方法的Storage API的另一个原因是，我们可以在尚不支持Web Storage规范的浏览器中，其他存储机制的顶层API对其也是兼容的。 以下部分将使用Cookie和IE userData实现Storage API。如果使用基于方法的API，则可以使用localStorage的时候就可以使用它来编写代码，并在其他浏览器中使用其他存储机制。代码可如下所示：
//找出正在使用的存储方式
var memory = window.localStorage ||
(window.UserDataStora
全文共12454字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[144540]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
