Расскажите о распространенных решениях для хранения данных в браузере

браузер

Предисловие:

Я использовал файлы cookie при написании кода во время праздника 1 мая. Я чувствовал, что мало знаю о схеме хранения данных в браузере, поэтому я перешел к главе о хранении данных на стороне браузера в середине двух больших книг и зашел на MDN., еще раз прочитал несколько статей, и у меня есть понимание схемы хранения данных в браузере, поэтому резюмирую здесь!

хранилище браузера

Для нас очень полезно хранить данные на стороне браузера, что эквивалентно предоставлению браузеру функции памяти, которая может записывать всю информацию о состоянии пользователя и улучшать работу пользователя. Например, когда статус входа пользователя записывается, пользователь может получить доступ быстрее, вместо того, чтобы выполнять громоздкие операции каждый раз при входе в систему.

В целом, наиболее распространенными решениями для хранения данных на рынке сегодня являются следующие три:

  • Cookie
  • веб-хранилище (localStorage и seesionStorage)
  • IndexedDB

图片.png

Cookie

Cookie, также известный как HTTP Cookie, изначально использовался для хранения информации о сеансе на стороне клиента. На нижнем уровне он реализован как расширение протокола HTTP. Данные cookie автоматически передаются между веб-браузером и веб-сервером. Таким образом, серверный сценарий может читать и записывать значение сохраненного файла cookie, поэтому файлы cookie обычно используются для хранения некоторых общих данных, таких как статус входа пользователя в систему, предпочтения и т. д. Хотя с течением времени механизм веб-хранилища, предоставляемый HTML5, постепенно заменил файлы cookie, но некоторые старые браузеры по-прежнему несовместимы с механизмом веб-хранилища, поэтому мы все еще находимся на этой старой стадии замены, нам все еще нужно понять это. .из. (Например, моя кожа дыни до сих пор использует его, 2333)

Преимущества файлов cookie

Прежде всего, поскольку API для работы с файлами cookie был определен и реализован давно, по сравнению с другими методами хранения данных, совместимость файлов cookie очень хорошая.Он совместим со всеми основными браузерами на рынке.Когда мы его используем , мы полностью не беспокойтесь о проблемах совместимости.

Недостатки файлов cookie

Что касается недостатков файлов cookie, то это уже слишком, иначе не будет новых решений для хранения данных, таких как веб-хранилище за файлами cookie. Подводя итог, недостатки файлов cookie в основном заключаются в следующем:

  1. Хранилище маленькое. Хотя разные браузеры имеют разные объемы памяти, в основном они составляют около 4 КБ.
  2. влияют на производительность. Поскольку файлы cookie отправляются браузерами в виде заголовков запросов, когда в файлах cookie хранится слишком много информации, это повлияет на эффективность получения ресурсов для конкретного домена и увеличит нагрузку на передачу документов.
  3. Только строки могут быть сохранены.
  4. Безопасный вопрос. Хранение может быть доступно в любых данных файлов cookie, поэтому важная информация не может быть сохранена в cookie.
  5. Из-за злоупотребления сторонними файлами cookie многие старые драйверы отключают файлы cookie при просмотре веб-страниц, поэтому мы должны проверить, поддерживают ли пользователи файлы cookie, что также очень проблематично.

Использование файлов cookie

Существует три основных операции с файлами cookie: чтение, запись и удаление. Но работа с куками в JavaScript — очень громоздкая вещь, потому что все имена и значения в куки закодированы в URI, поэтому, когда мы должны использовать decodeURICompoent для декодирования, чтобы получить значение куки. Давайте посмотрим, как объект 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, это очень хлопотно, что также стало основной причиной появления последующих решений для хранения данных браузера.

веб-хранилище

Механизм веб-хранилища изначально был определен в виде API как часть HTML5, но из-за собственной уникальности и некоторых других причин он был исключен и стал независимым стандартом. Стандартные API для веб-хранилища включают объект locaStorage и объект seesionStorage. Основные причины для этого в основном по следующим двум причинам:

  • Хотелось бы иметь способ хранить данные сеанса вне файлов cookie.
  • Хотелось бы иметь механизм для хранения больших объемов данных, которые могут существовать между сеансами.

(Примечание. На самом деле исходная спецификация веб-хранилища содержит определения двух объектов: seesionStorage и globalStorage. Эти два объекта существуют в виде свойств объекта Windows в браузерах, поддерживающих эти два объекта)

localStorage

Объект localStorage заменяет объект globalStorage, о котором мы упоминали выше, как решение для сохранения данных на стороне клиента в пересмотренной спецификации HTML5. Функционально мы можем хранить данные о паре ключ-значение на стороне браузера через locaStorage, По сравнению с файлами cookie, он предоставляет более интуитивно понятный API и относительно лучше с точки зрения безопасности. , и хотя localStorage может хранить только строки, он также может хранить строковые данные JSON, поэтому localStorage может хранить более сложные данные, чем файлы cookie. В целом, по сравнению с куки, localStorage имеет следующие преимущества:

  • Предоставляет простой и понятный API для работы
  • безопаснее
  • Большой объем данных, которые можно сохранить

Именно по этим причинам localStorage рассматривается как решение для замены файлов cookie, но все же необходимо соблюдать осторожность, чтобы не хранить конфиденциальную информацию в localStorage.

Базовый синтаксис localStorage

Основная операция localStorage очень проста, пример выглядит следующим образом:

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

Но следует отметить, что все наши приведенные выше примеры хранят данные в строковом формате.Когда нам нужно передать данные в других форматах, нам нужно преобразовать все эти данные в строковый формат, а затем сохранить их:

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

Конечно, не забудьте преобразовать его обратно, когда мы получим значение:

var age = JSON.parse(localStorage.user)

Действительность и объем данных хранилища localStorage

Данные, хранящиеся через localStorage, являются постоянными, если мы не используем removeItem для удаления или пользователь не удаляет их, настроив конфигурацию браузера, ответственные данные всегда будут оставаться на компьютере пользователя и никогда не истечет.

Область действия localStorage ограничена уровнем источника документа (это означает, что один и тот же источник может совместно использоваться), данные localStorage будут совместно использоваться документами одного и того же источника, они могут читать данные друг друга, а иногда даже перезаписывать данные друг друга. Конечно, возможности localStorage также ограничены браузером.

Совместимость с локальным хранилищем

Совместимость localStorage показана в следующей таблице:

    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 — еще один большой объект механизма веб-хранилища.Свойство sessionStorage позволяет нам получить доступ к объекту Session Storage. Это похоже на localStorage, разница в том, что данные, хранящиеся в localStorage, не имеют настройки времени истечения срока действия, в то время как хранилище сеансов хранит только данные текущей страницы сеанса, и данные будут очищены только тогда, когда пользователь закроет текущую страницу сеанса или браузер.

Базовый синтаксис 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 и localStorage похожи, поэтому много говорить здесь не буду, поговорим об IndexedDB.

IndexedDB

Хотя механизм веб-хранилища очень удобен и полезен для хранения небольших объемов данных, для хранения больших объемов структурированных данных этот метод не отвечает потребностям разработчиков. В ответ на этот спрос была создана IndexedDB.Это локальное хранилище, предоставляемое HTML5, которое используется для хранения веб-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 (по сравнению с предыдущими решениями для хранения данных)

  • Иметь больше места для хранения
  • Способность работать с более сложными и структурированными данными
  • Получите больше интерактивного контроля
  • Каждая «база данных» может иметь несколько «баз данных» и «таблиц».

Ограничения IndexedDB

После понимания преимуществ IndexedDB, конечно, мы также должны поговорить об ограничениях и применимых сценариях IndexedDB:

1. Ограничение места для хранения

Размер одного элемента базы данных не ограничен. Однако могут быть ограничения на размер каждой базы данных IndexedDB. Это ограничение (и то, как его устанавливает пользовательский интерфейс) также может различаться в разных браузерах:

  • Firefox: размер базы данных IndexedDB не ограничен. Разрешения запрашиваются в пользовательском интерфейсе только для BLOB (больших двоичных объектов), размер которых превышает 50 МБ. Это ограничение размера можно настроить с помощью параметра dom.indexedDB.warningQuota. (определено вНекоторые люди. Mozilla.org/Mozilla-cen…).
  • Гугл Хром:Developers.Google.com/chrome...Человек...

2. Проблемы совместимости

图片.png
Из приведенного выше рисунка видно, что совместимость IndexedDB намного хуже, чем у упомянутых выше решений для хранения данных, поэтому при использовании IndexedDB мы также должны учитывать вопрос совместимости.

3. indexedDB ограничен политикой одного и того же источника

indexedDB использует принцип того же источника, что означает, что он привязывает пространство хранения к источнику сайта, который его создал (обычно это домен или поддомен сайта), поэтому к нему нельзя получить доступ из любого другого источника. Важно отметить, что IndexedDB не работает с контентом, загруженным во фреймы с другого сайта (ни того, ни другого). Это мера безопасности. Подробнее см. здесь:Но информация. Mozilla.org/show_but. Успех...  

Кроме того, у IndexedDB также есть проблемы, такие как: он не подходит для хранения конфиденциальных данных, и операция сложнее, чем механизм веб-хранилища.Это все проблемы, которые мы должны учитывать при использовании IndexedDB.

Категории