web存储方式有哪些?
如下图,常见的浏览器端存储技术有(
Local Storage
、Session Storage
、IndexedDB
、Web SQL
还有Cookies
Local Storage与Session Storage
介绍
Local Storage
是没有时间限制的存储(关闭浏览器,再次打开浏览器,存储的数据依然存在,除非主动清除。)Session Storage
是针对一个Session的数据存储(关闭浏览器窗口,存储的数据清空。),前进、后退、刷新数据依然存在。它们均只能存储字符串类型的对象,都是用来存储客户端临时信息的对象。
不同浏览器无法共享
Session Storage
、Local Storage
中的信息.相同浏览器不同页面可以共享
Local Storage
中的信息(同协议,同域名,同端口,即不能跨域。),但是Session Storage
不行。
用法
1 | /* 存储变量 */ |
注意:localStorage存储的值只能是字符串形式。当存储的数据为引用对象,会默认调用对象的toString方法,转为字符串在存储。在存储数组的时候,存储的数据项以“,”隔开,解析的时候需要分解为数组在操作。对于对象,需要JSON.stringify转化在存储,获取数据后用JSON.parse转为对象。
顺带一提服务端的存储技术
Session
与Session Storage
是不同的。Session
数据是放在服务器上,而Session Storage
是放在浏览器上的。PHP-SESSION
Cookies
介绍
网络早期最大的问题之一是如何管理状态。简而言之,服务器无法知道两个请求是否来自同一个浏览器。当时最简单的方法是在请求时,在页面中插入一些参数,并在下一个请求中传回参数。这需要使用包含参数的隐藏的表单,或者作为URL参数的一部分传递。这两个解决方案都手动操作,容易出错。cookie出现来解决这个问题。
cookie是纯文本,没有可执行代码。存储数据,当用户访问了某个网站(网页)的时候,我们就可以通过cookie来向访问者电脑上存储数据,或者某些网站为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据(通常经过加密)。
当网页要发http请求时,浏览器会先检查是否有相应的cookie,有则自动添加在request header中的cookie字段中。这些是浏览器自动帮我们做的,而且每一次http请求浏览器都会自动帮我们做。这个特点很重要,因为这关系到“什么样的数据适合存储在cookie中”。
存储在cookie中的数据,每次都会被浏览器自动放在http请求中,如果这些数据并不是每个请求都需要发给服务端的数据,浏览器这设置自动处理无疑增加了网络开销;但如果这些数据是每个请求都需要发给服务端的数据(比如身份认证信息),浏览器这设置自动处理就大大免去了重复添加操作。所以对于那种设置“每次请求都要携带的信息(最典型的就是身份认证信息)”就特别适合放在cookie中,其他类型的数据就不适合了。
特征
不同的浏览器存放的cookie位置不一样,也是不能通用的。
cookie的存储是以域名形式进行区分的,不同的域下存储的cookie是独立的。
我们可以设置cookie生效的域(当前设置cookie所在域的子域),也就是说,我们能够操作的cookie是当前域以及当前域下的所有子域。
一个域名下存放的cookie的个数是有限制的,不同的浏览器存放的个数不一样,一般为20个。
cookie也可以设置过期的时间,默认是会话结束的时候,当时间到期自动销毁。
使用
由于源生cookie设置不是很友好,我们要自己写函数实现。
使用JavaScript
1 | /* 设置cookie,name-存Cookie的变量名,value-变量的值,days-有效期 */ |
使用jQuery插件
1 | /* 使用之前记得引入jquery与jquery.cookie.js */ |
使用php
1 | /* 设置cookie */ |
Web SQL
未来会被取代,主要有以下几个原因:
- W3C舍弃 Web SQL database草案,而且是在2010年年底,规范不支持了,浏览器厂商已经支持的就支持了,没有支持的也不打算支持了,比如IE和Firefox。
- 为什么要舍弃?因为 Web SQL database 本质上是一个关系型数据库,后端可能熟悉,但是前端就有很多不熟悉了,虽然SQL的简单操作不难,但是也得需要学习。
- SQL熟悉后,真实操作中还得把你要存储的东西,比如对象,转成SQL语句,也挺麻烦的。
indexedDB
来自MDN的解释: indexedDB 是一种低级API,用于客户端存储大量结构化数据(包括, 文件/ blobs)。该API使用索引来实现对该数据的高性能搜索。虽然 Web Storage 对于存储较少量的数据很有用,但对于存储更大量的结构化数据来说,这种方法不太有用。IndexedDB提供了一个解决方案。所以,IndexedDB API是强大的,但对于简单的情况可能看起来太复杂了,所以要看你的业务场景来选择到底是用还是不用。
其他对比
Local Storage
、Session Storage
、Cookies
对比
对比内容 | Local Storage | Session Storage | Cookies |
---|---|---|---|
数据生命周期 | 除非被清除,否则永久保留。 | 关闭页面或者浏览器后清除 | 有失效时间 |
存放数据大小 | 一般为5MB(由各浏览器厂商决定) | 同前者 | 一般是4KB左右 |
与服务器端通信 | 仅保存在客户端,不与服务器通信。 | 同前者 | 每次都会携带在HTTP请求头里面,如果使用Cookie保存过多数据会带来性能问题。 |
易用性 | 源生可用,也可再次封装。 | 源生可用,也可再次封装。 | 源生的Cookie接口不友好,需自己封装。 |
应用场景 | 保存一些持久性数据,像游戏数据等。 | 保存一些暂时性的数据 | 一般用来保存一些验证信息 |
cookie、session区别
cookie数据存放在客户的浏览器上,session数据放在服务器上。
cookie不是很安全,别人可以分析存放在本地的cookie并进行cookie欺骗,考虑*到安全应当使用session。
session会在一定时间内保存在服务器上,当访问增多,会比较占用你服务器的性能,考虑到减轻服务器性能方面,应当使用cookie。
单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie。
建议将登录信息等重要信息存放为session,其他信息如果需要保留,可以放在cookie中。
session保存在服务器,客户端不知道其中的信息,cookie保存在客户端,服务器能够知道其中的信息。
session中保存的是对象,cookie中保存的是字符串。
session不能区分路径,同一个用户在访问一个网站期间,所有的session在任何一个地方都可以访问到,而cookie中如果设置了路径参数,那么同一个网站中不同路径下的cookie互相是访问不到的。
客户端(浏览器)本地存储与服务器端存储
其实数据既可以在浏览器本地存储,也可以在服务器端存储。浏览器可以保存一些数据,需要的时候直接从本地存取,sessionStorage、localStorage和cookie都是由浏览器存储在本地的数据,服务器端也可以保存所有用户的所有数据,但需要的时候浏览器要向服务器请求数据。
服务器端可以保存用户的持久数据,如数据库和云存储将用户的大量数据保存在服务器端。
服务器端也可以保存用户的临时会话数据,服务器端的session机制,如session对象,数据保存在服务器上,实际上,服务器和浏览器之间仅需传递session id即可,服务器根据session id找到对应用户的session对象,会话数据仅在一段时间内有效,这个时间就是server端设置的session有效期。
服务器端保存所有的用户的数据,所以服务器端的开销较大,而浏览器端保存则把不同用户需要的数据分别保存在用户各自的浏览器中,浏览器端一般只用来存储小数据,而非服务可以存储大数据或小数据服务器存储数据安全一些,浏览器只适合存储一般数据。
千万不能在客户端存储敏感信息。
参考文章