当前位置:首页 » 服务存储 » 有什么方式可以存储整个前端页面
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

有什么方式可以存储整个前端页面

发布时间: 2023-06-05 23:09:51

⑴ 说一下前端数据存储方式(cookies,localstorage,sessionstorage,indexedDB)的区别

Cookie最初是在客户端用于存储会话信息的,其要求服务器对任意HTTP请求发送Set-CookieHTTP头作为响应的一部分。cookie
以name为名称,以value为值,名和值在传送时都必须是URL编码的。浏览器会存储这样的会话信息,在这之后,通过为每个请求添加Cookie
HTTP头将信息发送回服务器。

localstorage

存储方式:

以键值对(Key-Value)的方式存储,永久存储,永不失效,除非手动删除。

sessionstorage

HTML5 的本地存储 API 中的 localStorage 与 sessionStorage 在使用方法上是相同的,区别在于 sessionStorage 在关闭页面后即被清空,而 localStorage 则会一直保存。

IndexedDB

索引数据库(IndexedDB) API(作为 HTML5 的一部分)对创建具有丰富本地存储数据的数据密集型的离线 HTML5 Web 应用程序很有用。同时它还有助于本地缓存数据,使传统在线 Web 应用程序(比如移动 Web 应用程序)能够更快地运行和响应。

⑵ HTML5的5种存储方式详解

引言

本篇文章主要介绍了前端HTML5几种存储方式的总结 ,主要包括本地存储localstorage,本地存储sessionstorage,离线缓存(application cache),Web SQL,IndexedDB。有兴趣的可以了解一下。

正文开始~

h5之前,存储主要是用cookies。cookies缺点有在请求头上带着数据,大小是4k之内。主Domain污染。

主要应用:购物车、客户登录

对于IE浏览器有UserData,大小是64k,只有IE浏览器支持。

目标

存储方式:

以键值对(Key-Value)的方式存储,永久存储,永不失效,除非手动删除。

大小:

每个域名5M

支持情况:

注意:IE9 localStorage不支持本地文件,需要将项目署到服务器,才可以支持!

常用的API:

getItem //取记录

setIten//设置记录

removeItem//移除记录

key//取key所对应的值

clear//清除记录

存储的内容:

数组,图片,json,样式,脚本。。。(只要是能序列化成字符串的内容都可以存储)

HTML5 的本地存储 API 中的 localStorage 与 sessionStorage 在使用方法上是相同的,区别在于 sessionStorage 在关闭页面后即被清空,而 localStorage 则会一直保存。

本地缓存应用所需的文件

使用方法:

①配置manifest文件

页面上:

Manifest 文件:

manifest 文件是简单的文本文件,它告知浏览器被缓存的内容(以及不缓存的内容)。

manifest 文件可分为三个部分:

①CACHE MANIFEST - 在此标题下列出的文件将在首次下载后进行缓存

②NETWORK - 在此标题下列出的文件需要与服务器的连接,且不会被缓存

③FALLBACK - 在此标题下列出的文件规定当页面无法访问时的回退页面(比如 404 页面)

完整demo:

服务器上: manifest文件需要配置正确的MIME-type,即 "text/cache-manifest"。

如Tomcat:

常用API:

核心是applicationCache对象,有个status属性,表示应用缓存的当前状态:

0(UNCACHED) : 无缓存, 即没有与页面相关的应用缓存

1(IDLE) : 闲置,即应用缓存未得到更新

2 (CHECKING) : 检查中,即正在下载描述文件并检查更新

3 (DOWNLOADING) : 下载中,即应用缓存正在下载描述文件中指定的资源

4 (UPDATEREADY) : 更新完成,所有资源都已下载完毕

5 (IDLE) : 废弃,即应用缓存的描述文件已经不存在了,因此页面无法再访问应用缓存

相关的事件:

表示应用缓存状态的改变:

checking : 在浏览器为应用缓存查找更新时触发

error : 在检查更新或下载资源期间发送错误时触发

noupdate : 在检查描述文件发现文件无变化时触发

downloading : 在开始下载应用缓存资源时触发

progress:在文件下载应用缓存的过程中持续不断地下载地触发

updateready : 在页面新的应用缓存下载完毕触发

cached : 在应用缓存完整可用时触发

Application Cache的三个优势:

① 离线浏览

② 提升页面载入速度

③ 降低服务器压力

注意事项:

1. 浏览器对缓存数据的容量限制可能不太一样(某些浏览器设置的限制是每个站点 5MB)

2. 如果manifest文件,或者内部列举的某一个文件不能正常下载,整个更新过程将视为失败,浏览器继续全部使用老的缓存

3. 引用manifest的html必须与manifest文件同源,在同一个域下

4. 浏览器会自动缓存引用manifest文件的HTML文件,这就导致如果改了HTML内容,也需要更新版本才能做到更新。

6. FALLBACK中的资源必须和manifest文件同源

7. 更新完版本后,必须刷新一次才会启动新版本(会出现重刷一次页面的情况),需要添加监听版本事件。

8. 站点中的其他页面即使没有设置manifest属性,请求的资源如果在缓存中也从缓存中访问

9. 当manifest文件发生改变时,资源请求本身也会触发更新

离线缓存与传统浏览器缓存区别:

1. 离线缓存是针对整个应用,浏览器缓存是单个文件

2. 离线缓存断网了还是可以打开页面,浏览器缓存不行

3. 离线缓存可以主动通知浏览器更新资源

关系数据库,通过SQL语句访问

Web SQL 数据库 API 并不是 HTML5 规范的一部分,但是它是一个独立的规范,引入了一组使用 SQL 操作客户端数据库的 APIs。

支持情况:

Web SQL 数据库可以在最新版的 Safari, Chrome 和 Opera 浏览器中工作。

核心方法:

①openDatabase: 这个方法使用现有的数据库或者新建的数据库创建一个数据库对象。

②transaction: 这个方法让我们能够控制一个事务,以及基于这种情况执行提交或者回滚。

③executeSql: 这个方法用于执行实际的 SQL 查询。

打开数据库:

执行查询操作:

插入数据:

读取数据:

由这些操作可以看出,基本上都是用SQL语句进行数据库的相关操作,如果你会MySQL的话,这个应该比较容易用。

索引数据库 (IndexedDB) API(作为 HTML5 的一部分)对创建具有丰富本地存储数据的数据密集型的离线 HTML5 Web 应用程序很有用。同时它还有助于本地缓存数据,使传统在线 Web 应用程序(比如移动 Web 应用程序)能够更快地运行和响应。

异步API:

在IndexedDB大部分操作并不是我们常用的调用方法,返回结果的模式,而是请求——响应的模式,比如打开数据库的操作

这样,我们打开数据库的时候,实质上返回了一个DB对象,而这个对象就在result中。由上图可以看出,除了result之外。还有几个重要的属性就是onerror、onsuccess、onupgradeneeded(我们请求打开的数据库的版本号和已经存在的数据库版本号不一致的时候调用)。这就类似于我们的ajax请求那样。我们发起了这个请求之后并不能确定它什么时候才请求成功,所以需要在回调中处理一些逻辑。

关闭与删除:

数据存储:

indexedDB中没有表的概念,而是objectStore,一个数据库中可以包含多个objectStore,objectStore是一个灵活的数据结构,可以存放多种类型数据。也就是说一个objectStore相当于一张表,里面存储的每条数据和一个键相关联。

我们可以使用每条记录中的某个指定字段作为键值(keyPath),也可以使用自动生成的递增数字作为键值(keyGenerator),也可以不指定。选择键的类型不同,objectStore可以存储的数据结构也有差异。

学习从来不是一个人的事情,要有个相互监督的伙伴,想要学习或交流前端问题的小伙伴可以私信“学习”小明获取web前端入门资料,一起学习,一起成长!

⑶ 前端本地存储的 3 种方法 cookie、localStorage、sessionStorage

当网页要发http请求时,浏览器会先检查是否有相应的cookie,有则自动添加在request header中的cookie字段中。这些是浏览器自动帮我们做的,而且每一次http请求浏览器都会自动帮我们做。这个特点很重要,因为这关系到“什么样的数据适合存储在cookie中”。

存储在cookie中的数据,每次都会被浏览器自动放在http请求中,如果这些数据并不是每个请求都需要发给服务端的数据,浏览器这设置自动处理无疑增加了网络开销;但如果这些数据是每个请求都需要发给服务端的数据(比如身份认证信息),浏览器这设置自动处理就大大免去了重复添加操作。所以对于那种设置“每次请求都要携带的信息(最典型的就是身份认证信息)”就特别适合放在cookie中,其他类型的数据就不适合了。

不同的浏览器存放的cookie位置不一样,也是不能通用的。

cookie的存储是以域名形式进行区分的,不同的域下存储的cookie是独立的。

我们可以设置cookie生效的域(当前设置cookie所在域的子域),也就是说,我们能够操作的cookie是当前域以及当前域下的所有子域

一个域名下存放的cookie的个数是有限制的,不同的浏览器存放的个数不一样,一般为20个。

每个cookie存放的内容大小也是有限制的,不同的浏览器存放大小不一样,一般为4KB。

cookie也可以设置过期的时间,默认是会话结束的时候,当时间到期自动销毁

cookie值既可以设置,也可以读取。

我们通过document.cookie来获取当前网站下的cookie的时候,得到的字符串形式的值,它包含了当前网站下所有的cookie(为避免跨域脚本(xss)攻击,这个方法只能获取非 HttpOnly 类型的cookie)。它会把所有的cookie通过一个分号+空格的形式串联起来,例如username=chenfangxu; job=coding

要想修改一个cookie,只需要重新赋值就行,旧的值会被新的值覆盖。但要注意一点,在设置新cookie时,path/domain这几个选项一定要旧cookie 保持一样。否则不会修改旧值,而是添加了一个新的 cookie。

把要删除的cookie的过期时间设置成已过去的时间,path/domain/这几个选项一定要旧cookie 保持一样。

如果我们想长时间存放一个cookie。需要在设置这个cookie的时候同时给他设置一个过期的时间。如果不设置,cookie默认是临时存储的,当浏览器关闭进程的时候自动销毁

使用方法: setCookie('username','cfangxu',30)

domain指定了 cookie 将要被发送至哪个或哪些域中。默认情况下,domain 会被设置为创建该 cookie 的页面所在的域名,所以当给相同域名发送请求时该 cookie 会被发送至服务器。

浏览器会把 domain 的值与请求的域名做一个尾部比较(即从字符串的尾部开始比较),并将匹配的 cookie 发送至服务器。

cookie 一般都是由于用户访问页面而被创建的,可是并不是只有在创建 cookie 的页面才可以访问这个 cookie。 因为安全方面的考虑,默认情况下,只有与创建 cookie 的页面在同一个目录或子目录下的网页才可以访问。即path属性可以为服务器特定文档指定cookie,这个属性设置的url且带有这个前缀的url路径都是有效的。

domain是域名,path是路径,两者加起来就构成了 URL,domain和path一起来限制 cookie 能被哪些 URL 访问。 所以domain和path两个个选项共同决定了cookie何时被浏览器自动添加到请求头部中发送出去。如果没有设置这两个选项,则会使用默认值。domain的默认值为设置该cookie的网页所在的域名,path默认值为设置该cookie的网页所在的目录。

通常 cookie 信息都是使用HTTP连接传递数据,这种传递方式很容易被查看,所以 cookie 存储的信息容易被窃取。假如 cookie 中所传递的内容比较重要,那么就要求使用加密的数据传输。

secure选项用来设置cookie只在确保安全的请求中才会发送。当请求是HTTPS或者其他安全协议时,包含 secure 选项的 cookie 才能被发送至服务器。

把cookie设置为secure,只保证 cookie 与服务器之间的数据传输过程加密,而保存在本地的 cookie文件并不加密。就算设置了secure 属性也并不代表他人不能看到你机器本地保存的 cookie 信息。机密且敏感的信息绝不应该在 cookie 中存储或传输,因为 cookie 的整个机制原本都是不安全的

注意:如果想在客户端即网页中通过 js 去设置secure类型的 cookie,必须保证网页是https协议的。在http协议的网页中是无法设置secure类型cookie的。

这个选项用来设置cookie是否能通过 js 去访问。默认情况下,cookie不会带httpOnly选项(即为空),所以默认情况下,客户端是可以通过js代码去访问(包括读取、修改、删除等)这个cookie的。

当cookie带httpOnly选项时,客户端则无法通过js代码去访问(包括读取、修改、删除等)这个cookie。 在客户端是不能通过js代码去设置一个httpOnly类型的cookie的,这种类型的cookie只能通过服务端来设置。

HTML5新方法,不过IE8及以上浏览器都兼容。

生命周期:持久化的本地存储,除非主动删除数据,否则数据是永远不会过期的。

存储的信息在同一域中是共享的。

当本页操作(新增、修改、删除)了localStorage的时候,本页面不会触发storage事件,但是别的页面会触发storage事件。

大小:据说是5M(跟浏览器厂商有关系)

localStorage本质上是对字符串的读取,如果存储内容多的话会消耗内存空间,会导致页面变卡

localStorage受同源策略的限制

当storage发生改变的时候触发。 当页面对storage的操作会触发其他页面的storage事件,storage事件是可以跨页面通讯的,在你对storage对象进行任何操作的时候,都会触发storage事件,事件里边包括包括:

storage事件使用参考

对于sessionStorage和localStorage上的任何更改都会触发storage事件,但storage事件不会区分这两者;

其实跟localStorage差不多,也是本地存储,会话本地存储

和 localStorage 的API完全相同

用于本地存储一个会话(session)中的数据,这些数据只有在同一个会话中的页面才能访问并且当会话结束后数据也随之销毁。因此sessionStorage不是一种持久化的本地存储,仅仅是会话级别的存储。也就是说只要这个浏览器窗口没有关闭,即使刷新页面或进入同源另一页面,数据仍然存在。关闭标签页后,sessionStorage即被销毁,或者在新的标签页打开同源的另一个页面,sessionStorage也是没有的。

应用的场景有,比如说我们都知道,在页面刷新的时候,我们写的js里边的变量函数等等的,内存会被释放掉,那么这个时候可以用sessionStorage来存储一些不想被释放掉内存的数据,比如说记录一个滚动条的位置,或者播放器的进度等等

在本地(浏览器端)存储数据

sessionStorage和localStorage 都受到同源策略限制,就是跨域问题,在访问sessionStorage和localStorage 的时候,页面必须在同一个域名,使用同一个协议,并且一个端口

sessionStorage比localStorage更严苛一点,除了协议、主机名、端口外,还要求在同一窗口(也就是浏览器的标签页)下。

localStorage是永久存储,除非手动删除。

sessionStorage当会话结束(当前页面、标签页关闭的时候,自动销毁)

cookie的数据会在每一次发送http请求的时候,同时发送给服务器而localStorage、sessionStorage不会。

sessionStorage和localStorage 也有大小限制,相比cookie大了很多,是5M

sessionStorage和localStorage只能通过客户端操作,cookie既可以通过客户端操作又可以通过服务端操作