聊一聊常见的浏览器端数据存储方案

前言：

五一假期在撸代码的时候用到cookie，感受对浏览器的数据存储方案不是很了解，所以又去翻了两本大头书中间的关于浏览器端数据存储的章节，同时去MDN逛了逛，又看了几篇文章，算是对浏览器的数据存储方案有了一个了解，在此总结一下！

浏览器存储

在浏览器端存储数据对咱们是颇有用，这至关于赋予浏览器记忆的功能，能够纪录用户的全部状态信息，加强用户体验。好比当纪录用户的登录状态时，可让用户可以更快的进行访问，而不是每次登录时都须要去进行繁琐的操做。

总的来讲,如今市面上最多见的数据存储方案是如下三种：

• Cookie
• web存储 (locaStorage和seesionStorage)
• IndexedDB

Cookie

Cookie的又称是HTTP Cookie，最初是在客户端用于存储会话信息，从底层来看，它做为HTTP协议的一种扩展实现，Cookie数据会自动在web浏览器和web服务器之间传输，所以在服务器端脚本就能够读写存储的cookie的值，所以Cookie一般用于存储一些通用的数据，好比用户的登录状态，首选项等。虽然随着时代的进步，HTML5所提供的web存储机制已经逐步替代了Cookie，但有些较为老的浏览器仍是不兼容web存储机制，所以正处于这个老旧更替阶段的咱们对于它仍是要了解了解的。(好比我这个瓜皮还在用它，2333)

Cookie的优势

首先因为操做Cookie的API很早就已经定义和实现了，所以相比于其余的数据存储方式，Cookie的兼容性很是的好，兼容如今市面上全部的主流浏览器，咱们在使用它的时候彻底不用担忧兼容问题。

Cookie的缺点

说到Cookie的缺点，那就有点多了，否则也不会在Cookie后面出现web存储等新的数据存储的方案了。 总结起来Cookie的缺点主要是如下几点：

1. 存储量小。虽不一样浏览器的存储量不一样，但基本上都是在4kb左右。
2. 影响性能。因为Cookie会由浏览器做为请求头发送，所以当Cookie存储信息过多时，会影响特定域的资源获取的效率，增长文档传输的负载。
3. 只能储存字符串。
4. 安全问题。存储在Cookie的任何数据能够被他人访问，所以不能在Cookie中储存重要的信息。
5. 因为第三方Cookie的滥用，因此不少老司机在浏览网页时会禁用Cookie，因此咱们不得不测试用户是否支持Cookie，这也是很麻烦的一件事。

Cookie的操做

基本的Cookie操做主要有三个：读取，写入和删除。但在JavaScript中去处理cookie是一件很繁琐的事情，由于cookie中的全部的名字和值都是通过URI编码的，因此当咱们必须使用decodeURICompoent来进行解码才能获得cookie的值。咱们来看看CookieUtil对象是如何操纵cookie的：

var CookieUtil = {
	// get可根据cookie的名字获取相应的值
	get: function() {
		const cookieName = encodeURIcOMPONET(name) + "=",
			   cookieStart = document.cookie.indexOf(cookieName),
			   cookieValue = null
		if(cookieStart > -1) {
			const cookieEnd = document.cookie.indexOf(";", cookieStart)
			if(cookieEnd == -1) {
				cookieEnd = document.cookie.length
			}
			cookieValue = decodeURICompoent(document.cookie.substring(cookieStart + cookieName.length, cookieEnd))	
		}
		return cookieValue
	}
	// set设置一个cookie
	set: function(name, value, expires, path, domain, secure) {
		var cookieText = encodeURIComponet(name)+"="+encodeURIComponet(value)
		if(expires instanceof Date) {
			cookieText += "; expires=" + expires.toGMTString()
		}
		if(path) {
			cookieText += ";path=" + path
		}
		if(domain) {
			cookieText += "; domain" + domain
		}
		if(secure) {
			cookieText += "; secure"
		}
		document.cookie = cookieText
	}
	// 删除已有的cookie
	unset: function(name, path, domain, secure) {
		this.set(name, "", new Date(0), path, domain, secure)
	}
}
复制代码

是否是很麻烦，不管是获取一个cookie的值或是设置一个cookie都是很麻烦的事情，这也成为了后续的浏览器数据存储方案出现的一大缘由。

web存储

web存储机制最初做为HTML5的一部分被定义成API的形式，但又因为其自己的独特性与其余的一些缘由而剥离了出来，成为独立的一个标准。web存储标准的API包括locaStorage对象和seesionStorage对象。它所产生的主要缘由主要出于如下两个缘由：

• 人们但愿有一种在cookie以外存储回话数据的途径。
• 人们但愿有一种存储大量能够跨会话存在的数据的机制。

（注：其实在最初的web存储规范中包含了两种对象的定义：seesionStorage和globalStorage,这两个对象在支持这两个对象的浏览器中都是以windows对象属性的形式存在的）

locaStorage

locaStorage对象在修订过的HTML5规范中做为持久保存客户端数据的方案取代了咱们上面所提到的globalStorage。从功能上来说，咱们能够经过locaStorage在浏览器端存储键值对数据，它相比于cookie而言，提供了更为直观的API，且在安全上相对好一点 ，并且虽然locaStorage只能存储字符串，但它也能够存储字符串化的JSON数据，所以相比于cookie，locaStorage能存储更复杂的数据。总的来讲相较于cookie，locaStorage有如下优点：

• 提供了简单明了的API来进行操做
• 更加安全
• 可储存的数据量更大

也正是出于以上这些缘由，locaStorage被视为替代cookie的解决方案，但仍是要注意不要在locaStorage中存储敏感信息。

locaStorage的基本语法

locaStorage的基本操做很简单，示例以下：

// 使用方法存储数据
locaStorage.setItem("name", "Srtian")
// 使用属性存储数据
locaStorage.say = "Hello world"
// 使用方法读取数据
const name = locaStorage.getItem("name")
// 使用属性读取数据
const say = locaStorage.say
// 删除数据
locaStorage.removeItem("name")
复制代码

但须要注意的是，咱们上面的示例全是存储字符串格式的数据，当咱们须要传输其余格式的数据时，咱们就须要将这些数据所有转换为字符串格式，而后再进行存储：

const user = {name:"Srtian", age: 22}
localStorage.setItem("user", JSON.stringify(user))
复制代码

固然，咱们在获取值的时候也别忘了将其转化回来：

var age = JSON.parse(locaStorage.user)
复制代码

locaStorage储存数据的有效期与做用域

经过locaStorage存储的数据时永久性的，除非咱们使用removeItem来删除或者用户经过设置浏览器配置来删除，负责数据会一直保留在用户的电脑上，永不过时。

locaStorage的做用域限定在文档源级别的（意思就是同源的才能共享），同源的文档间会共享locaStorage的数据，他们能够互相读取对方的数据，甚至有时会覆盖对方的数据。固然，locaStorage的做用域一样也受浏览器的限制。

locaStorage的兼容

locaStorage的兼容以下表所示：

Feature 	Chrome 	Edge 	Firefox (Gecko) Internet Explorer 	Opera 	Safari (WebKit)
localStorage 	4 	(Yes) 	   3.5 	            8 	             10.50     4
sessionStorage 	5 	(Yes) 	   2 	            8 	             10.50 	   4
复制代码

sessionStorage

sessionStorage是web存储机制的另外一大对象，sessionStorage 属性容许咱们去访问一个 session Storage 对象。它与 localStorage 类似，不一样之处在于 localStorage里面存储的数据没有过时时间设置，而Session Storage只存储当前会话页的数据，且只有当用户关闭当前会话页或浏览器时，数据才会被清除。

sessionStorage的基本语法

咱们能够经过下面的语法，来保存，获取，删除数据，大致语法与：

// 保存数据到sessionStorage
sessionStorage.setItem('name', 'Srtian');

// 从sessionStorage获取数据
var data = sessionStorage.getItem('name');

// 从sessionStorage删除保存的数据
sessionStorage.removeItem('name');

// 从sessionStorage删除全部保存的数据
sessionStorage.clear();
复制代码

下面的示例会自动保存一个文本输入框的内容，若是浏览器因偶然因素被刷新了，文本输入框里面的内容会被恢复，写入的内容不会丢失：

// 获取文本输入框
var field = document.getElementById("field")

// 检测是否存在 autosave 键值
// (这个会在页面偶然被刷新的状况下存在)
if (sessionStorage.getItem("autosave")) {
  // 恢复文本输入框的内容
  field.value = sessionStorage.getItem("autosave")
}
// 监听文本输入框的 change 事件
field.addEventListener("change", function() {
  // 保存结果到 sessionStorage 对象中
  sessionStorage.setItem("autosave", field.value)
})
复制代码

在兼容性和优势方面，sessionStorage和locaStorage是差很少的，所以在此也就很少说了，下面咱们来聊一聊IndexedDB。

IndexedDB

虽然web存储机制对于存储较少许的数据很是便捷好用，但对于存储更大量的结构化数据来讲，这种方法就不太知足开发者们的需求了。IndexedDB就是为了应对这个需求而产生的，它是由HTML5所提供的一种本地存储，用于在浏览器中储存较大数据结构的 Web API，并提供索引功能以实现高性能查找。它通常用于保存大量用户数据并要求数据之间有搜索须要的场景，当网络断开时，用户就能够作一些离线的操做。它较之SQL更为方便，不须要写一些特定的语法对数据进行操做，数据格式是JSON。

IndexedDB的基本语法

使用IndexedDB在浏览器端存储数据会比上述的其余方法更为复杂。首先，咱们须要建立数据库，并指定这个数据库的版本号：

// 注意数据库的版本号只能是整数
const request = IndexedDB.open(databasename, version)
复制代码

而后咱们须要生成处理函数，须要注意的是onupgradeneeded 是咱们惟一能够修改数据库结构的地方。在这里面，咱们能够建立和删除对象存储空间以及构建和删除索引。 ：

request.onerror = function() {
	// 建立数据库失败时的回调函数
}
request.onsuccess = function() {
	// 建立数据库成功时的回调函数
}
request.onupgradeneededd = function(e) {
	 // 当数据库改变时的回调函数
}

复制代码

而后咱们就能够创建对象存储空间了，对象存储空间仅调用createObjectStore()就能够建立。这个方法使用存储空间的名称，和一个对象参数。即使这个参数对象是可选的，它仍是很是重要的，由于它可让咱们定义重要的可选属性和完善你但愿建立的对象存储空间的类型。

request.onupgradeneeded = function(event) {
	const db = event.target.result
	const objectStore = db.createObjectStore('name', { keyPath:'id' })
}
复制代码

对象的存储空间咱们已经创建好了，接下来咱们就能够进行一系列的骚操做了，好比来个蛇皮走位！不不不，口误口误，好比添加数据：

addData: function(db, storename, data) {
	const store = store = db.transaction(storename, 'readwrite').objectStore(storename)
	for(let i = 0; i < data.length; i++) {
		const request = store.add(data[i])
		request.onerror = function() {
			console.error('添加数据失败')
		}
		request.onsuccess = function() {
			console.log('添加数据成功')
		}
	}
}
复制代码

若是咱们想要修改数据，语法与添加数据差很少，由于重复添加已存在的数据会更新本来的数据，但仍是有细小的差异：

putData: function(db, storename, data) {
	const store = store = db.transaction(storename, 'readwrite').objectStore(storename)
	for(let i = 0; i < data.length; i++) {
		const request = store.put(data[i])
		request.onerror = function() {
			console.error('修改数据失败')
		}
		request.onsuccess = function() {
			console.log('修改数据成功')
		}
	}
}
复制代码

获取数据：

getDataByKey: function(db, storename, key) {
	const store = store = db.transaction(storename, 'readwrite').objectStore(storename)
	const request = store.get(key)
	request.onerror = function() {
		console.error('获取数据失败')
	}
	request.onsuccess = function(e) {
		const result = e.target.result
		console.log(result)
	}
}
复制代码

删除数据：

deleteDate: function(db, storename, key) {
	const store = store = db.transaction(storename, 'readwrite').objectStore(storename)
	store.delete(key)
	console.log('已删除存储空间' + storename + '中的' + key + '纪录')
}
复制代码

关闭数据库：

db.close
复制代码

IndexedDB的优势（相较于前面的存储方案）

• 拥有更大的储存空间
• 可以处理更为复杂和结构化的数据
• 拥有更多的交互控制
• 每一个'database'中能够拥有多个'database'和'table'

IndexedDB的局限性

了解了IndexedDB的优势，咱们固然也要来聊一聊IndexedDB的局限性与适用的场景：

1. 存储空间限制

一个单独的数据库项目的大小没有限制。然而可能会限制每一个 IndexedDB 数据库的大小。这个限制（以及用户界面对它进行断言的方式）在各个浏览器上也可能有所不一样：

• Firefox: 对 IndexedDB 数据库的大小没有限制。在用户界面上只会针对存储超过 50 MB 大小的 BLOB（二进制大对象）请求权限。这个大小的限额能够经过 dom.indexedDB.warningQuota 首选项进行自定义。(定义在 http://mxr.mozilla.org/mozilla-central/source/modules/libpref/src/init/all.js)。
• Google Chrome：https://developers.google.com/chrome...rage#temporary

2. 兼容性问题

从上面的图咱们能够看出对于IndexedDB的兼容来说比前面所说起的存储方案要差很多，所以在使用IndexedDB时，咱们也要好好的考虑兼容性的问题

3. indexedDB受同源策略的限制

indexedDB使用同源原则，这意味着它把存储空间绑定到了建立它的站点的源（典型状况下，就是站点的域或是子域），因此它不能被任何其余源访问。要着重指出的一点是 IndexedDB 不适用于从另外一个站点加载进框架的内容 (无论是 仍是 。这是一项安全措施。详情请看这个：https://bugzilla.mozilla.org/show_bug.cgi?id=595307

除此以外，IndexedDB还存在诸如：不适合存储敏感数据，相较于web存储机制的操做更加复杂等问题，这都是咱们在使用IndexedDB时须要考虑的。