Фронтенд сразится с пятью подонками, чтобы выучить JavaScript - внешнее хранилище данных

Говоря о внешнем хранилище данных, мы должны упомянуть Cookie, sessionStorage и localStorage.Это самые знакомые слова для внешнего хранилища данных, с которыми мы сталкивались.Как фронтенд-разработчик и фронтенд-инженер, эти три слова ранее не применялись. Но в последнее время я видел много друзей, которые не знают, что делают куки, и они не знают, как использовать sessionStorage и localStorage, поэтому я подытожу~

внешнее хранилище данных

Все мы знаем, что фронтенд-разработчику, более или менее находящемуся в процессе разработки, из-за различных требований необходимо хранить некоторые данные во внешнем интерфейсе, такие как проверка входа, может использовать файлы cookie или localStorage для сохранить токены, а затем попросить поднять его вручную. Итак, нам нужно выяснить, какие методы доступны для внешнего хранилища и как мы можем использовать эти слова, с которыми мы уже знакомы (cookies, sessionStorage и localStorage) 😝

Ниже приведена сравнительная таблица распространенных методов внешнего хранилища, которые я суммировал. В настоящее время я понимаю это так. Если у вас есть какие-либо вопросы, пожалуйста, поправьте меня:

Cookie

Файлы cookie HTTP, часто называемые просто файлами cookie, изначально использовались на стороне клиента для хранения информации о сеансе. Стандарт требует, чтобы серверы отправляли HTTP-заголовок Set-Cookie как часть ответа на любой HTTP-запрос, который содержит информацию о сеансе. ——————《Расширенное программирование на JavaScript》

Проще говоря, он обычно используется для проверки входа в систему, после отправки запроса на вход сервер устанавливает возвращаемый заголовок ответа.Set-Cookieи установите его значение. И Cookie следует за тем же политикой браузера, а печенье текущей страницы не может быть доступно на страницах разных происхождений. Если вы можете, вы можете получить файл cookie, чтобы выделить запросы на XSS и CSRF.

Как показано на картинке выше, в заголовке ответа естьSet-Cookie, и установите соответствующее значение, возвращаемое сервером. В это время мы смотрим на файл cookie в приложении текущей страницы и обнаруживаем, что файл cookie уже возвращен только сейчас.Сеансовые файлы cookie, как правило, хранятся не на жестком диске, а в памяти.Если установлен срок действия, браузер сохранит файл cookie на жестком диске.

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

На картинке выше показан запрос, содержащий файл cookie, который не передается вручную внешним интерфейсом в запросе, а является автономным поведением браузера.

Ajax, Axios и fetch несут куки

Как мы только что сказали, пока сервер устанавливает его в заголовке ответа, возвращаемом запросомSet-CookieПри значении сервер помещает куки в браузер, и каждый последующий запрос будет нести этот куки, но есть такжеЗапросы, отправленные в отдельных случаях, не будут содержать файлы cookie по умолчанию..

Междоменные запросы Cors и запросы на выборку не содержат файлы cookie по умолчанию.

Ajax-запрос в jQuery

Нас не волнует запрос jsonp, отправленный в jQuery, потому что, строго говоря, jsonp — это не ситуация, когда серверная часть запроса отправляет данные обратно. Мы говорим только об отправленном прямо сейчас json-запросе. Под этим же доменом отправляем Ajax запрос ⬇️

$.ajax({
  type: 'post',
  url: '/person/detail',
  dataType: 'json',
  data: {
    id: 1
  },
  success: function (res) {},
  error: function(e) {}
})

Если мы запрашиваем интерфейс под другим доменом, мы не рассматриваем ситуацию с обратным прокси, потому что обратный прокси теоретически по-прежнему обращается к интерфейсу того же домена. Ниже показано, если мы используем Cors для междоменного решения ⬇️

$.ajax({
  type: 'post',
  url: '/person/detail',
  dataType: 'json',
  data: {
    id: 1
  },
  xhrFields: {
    withCredentials: true // 如果是Cors解决的跨域，我们请求接口的域和我们页面所在域是不同域，所以需要添加这个属性值
  },
  success: function (res) {},
  error: function(e) {}
})

Запрос Axios

Ниже приведена библиотека запросов, которую мы часто используем в библиотеке vue или react — Axios, Axios отправляет междоменные запросы Cors и не будет приносить куки по умолчанию⬇️

axios({
  method: 'post',
  url: '/person/detail',
  data: {
    id: 1,
  }
});

Выше приведен обычный запрос того же домена, давайте посмотрим, как отправить запрос Cors.

axios({
  method: 'post',
  url: '/person/detail',
  data: {
    id: 1,
  },
  withCredentials: true, // 设置了这个值，我们我就可以发送Cors请求了，这个值默认不设置的话是false
});

Запрос

Fetch — это относительно низкоуровневый API, предоставляемый javascript, который позволяет нам легко инициировать запросы на выборку, но запросы на выборку теперь кажутся просто низкоуровневым API.Хотя это удобнее, чем собственные запросы Ajax, Ajax был инкапсулирован с помощью различные библиотеки.Очень удобно использовать, но fetch меркнет по сравнению с ним. Насколько мы видим сейчас, fetch не только не использует slack cookies при отправке запросов Cors, но и по умолчанию fetch не будет ни отправлять, ни получать cookies с сервера ни при каких обстоятельствах.Давайте сначала посмотрим на обычные запросы⬇️

fetch('/person/detail', {
  method: 'POST',
  body: JSON.stringify({id: 1}),
  headers: {
    'content-type': 'application/json'
  },
})

Мы отправили запрос на выборку выше, а затем нам нужно запросить учетные данные, что делать, если нам нужны файлы cookie⬇️

fetch('/person/detail', {
  method: 'POST',
  body: JSON.stringify({id: 1}),
  credentials: 'include', // 强制带上凭据头，携带上cookie
  headers: {
    'content-type': 'application/json'
  },
})

Управление файлами cookie

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

Формат сохраненных данных

Ниже приведен состав файла cookie, взятый из «Расширенное программирование на JavaScript».

имя:Имя, которое однозначно идентифицирует файл cookie. Имена файлов cookie нечувствительны к регистру, поэтому myCookie и MyCookie считаются одним и тем же файлом cookie. На практике, однако, лучше рассматривать имена файлов cookie с учетом регистра, поскольку некоторые серверы обрабатывают файлы cookie таким образом. Имя файла cookie должно быть закодировано в URL.
стоимость:Строковое значение, хранящееся в файле cookie. Значение должно быть закодировано в URL.
площадь:Для какого домена действителен файл cookie. Все запросы к этому домену будут включать информацию об этом файле cookie. Это значение может включать субдомен (субдомен, например, www.wrox.com) или не включать (например, .wrox.com, который действителен для всех субдоменов wrox.com). Если это не указано явно, предполагается, что домен относится к домену, в котором был установлен файл cookie.
дорожка:Для этого пути в указанном домене на сервер должен быть отправлен файл cookie. Например, вы можете указать, что файл cookie доступен только с http://www.wrox.com/books/, а затемwww.wrox.com, информация о файлах cookie не будет отправлена, даже если запрос исходит из того же домена.
Время окончания срока действия:Временная метка, указывающая, когда файл cookie должен быть удален (то есть, когда он должен прекратить отправку этого файла cookie на сервер). По умолчанию все файлы cookie удаляются при завершении сеанса браузера, однако вы можете самостоятельно установить время удаления. Это значение представляет собой дату в формате GMT (Wdy, DD-Mon-YYYY HH:MM:SS GMT), указывающую точное время, когда файл cookie должен быть удален. Поэтому файлы cookie могут оставаться на компьютере пользователя даже после закрытия браузера. Если установленная вами дата истечения срока действия уже прошла, файл cookie будет немедленно удален.
Знаки безопасности:Если указано, файл cookie отправляется на сервер только при использовании соединения SSL. Например, информация о файлах cookie может быть отправлена только на https://www.wrox.com, аwww.wrox.comзапросы не могут отправлять файлы cookie. Каждая часть информации включается как часть заголовка Set-Cookie, используя точку с запятой, за которой следует пробел для разделения каждой части, как показано в примере ниже.

получить куки, изменить куки

Нам очень удобно получать куки через js, нужно толькоdocument.cookie, мы можем получить cookie текущей страницы.

Вышеперечисленное передается в консолиdocument.cookieПолученный файл cookie

Мы обнаружили, что полученный файл cookie представляет собой длинную строку, и мы увидели в приложении, что это сериализованный файл cookie. Теперь, когда мы получили файл cookie, осталось самостоятельно сериализовать и манипулировать строкой, поэтому я не буду вдаваться в подробности.

Если мы изменим куки, если там то же значение, то он будет перезаписан, если нет, то будет создан новый

Из вышеизложенного мы можем знатьdocument.cookieКак получить и изменить значение куки, что бы кука ни сохраняла, она будет доставлена на сервер вместе с запросом. Если нам нужно часто манипулировать значением файла cookie, мы можем сами инкапсулировать методы get и set для работы с файлом cookie.

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

Web Storage

Веб-хранилище преодолевает некоторые ограничения, налагаемые файлами cookie, когда данные должны строго контролироваться на стороне клиента, без постоянной отправки данных обратно на сервер. Две основные цели веб-хранилища:
1. Обеспечьте способ хранения данных сеанса, отличных от файлов cookie;
2. Обеспечьте механизм для хранения больших объемов данных, которые могут существовать между сеансами.

Storage API, общий для sessionStorage и localStorage

И sessionStorage, и localStorage принадлежат веб-хранилищу, хотя время их действия разное, разработчики используют один и тот же метод.

// clear方法，可以删除sessionStorage中所有的值
sessionStorage.clear(); // 清除所有sessionStorage中的数据
localStorage.clear(); // 清除所有localStorage中的数据

// getItem(name) 根据指定的名字name获取对应的值
var name = sessionStorage.getItem('name'); // 获取key为name的value
var name = localStorage.getItem('name'); // 获取key为name的value
// 当然，我们也可以不这么着获取storage中的值，也可以像下面这样获取值
var name = sessionStorage.name; // 获取key为name的value
var name = localStorage.name; // 获取key为name的value

// key(index) 可以获取到index位置处的值的名字
var key = sessionStorage.key(0); // 获取到了sessionStorage中排在第一个的值的key，比如刚才的’name‘
var key = localStorage.key(0); // 获取到了localStorage中排在第一个的值的key，比如刚才的’name‘
// 获取到了排在第一位的key值，我们就可以根据这个key获取对应的value了
var value = sessionStorage.getItem(key); // 这样我们就获取到了排在第一位的name的value值
var value = localStorage.getItem(key); // 这样我们就获取到了排在第一位的name的value值

// removedItem(name) 删除由name指定的键值对
sessionStorage.removedItem('name'); // 删除了key为name的value
localStorage.removedItem('name'); // 删除了key为name的value
// 我们也能使用删除对象中属性的delete方法来删除
delete sessionStorage.name;
delete localStorage.name;

// setItem(name, value) 为指定的name设置一个对应的值
sessionStorage.setItem('name', 'zhanwuzha'); // 在sessionStorage中存了一个name，值为zhanwuzha
localStorage.setItem('name', 'zhanwuzha'); // 在localStorage中存了一个name，值为zhanwuzha
// 我们也可以使用另一种方法来设置
sessionStorage.name = 'zhanwuzha'; // 在sessionStorage中存了一个name，值为zhanwuzha
localStorage.name = 'zhanwuzha'; // 在localStorage中存了一个name，值为zhanwuzha

Выше описан метод в веб-хранилище, охватывающий CRUD.deleteОператоры не могут удалять данные в WebKit, поэтому мы по-прежнему используемremoveItem()метод

Данные, хранящиеся в веб-хранилище, не будут отправлены обратно на сервер вместе с запросом. Это самое большое отличие от файлов cookie, и данные хранятся в парах ключ-значение. Хотя файлы cookie также являются парами ключ-значение, они похожи к'name=zhanwuzha&age=16'Такие строки нуждаются в дальнейшей обработке.

sessionStorage

Объект sessionStorage хранит данные, относящиеся к сеансу, то есть данные сохраняются только до закрытия браузера. Этот объект похож на файл cookie сеанса и также исчезает при закрытии браузера. Данные, хранящиеся в sessionStorage, могут сохраняться при обновлении страницы и остаются доступными после сбоя и перезапуска браузера, если браузер поддерживает это (поддерживают и Firefox, и WebKit, но не IE). ——————《Расширенное программирование на JavaScript》

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

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

пример:

Мы устанавливаем sessionStorage на странице, ключname, значениеzhanwuzha, В это время мы нажимаем кнопку «Новая страница, чтобы открыть ту же страницу» на странице, чтобы открыть страницу в новой вкладке.

У нас все еще есть данные, которые мы только что сохранили в sessionStorage страницы новой вкладки, но что, если мы введем адрес прямо в адресную строку

На данный момент больше нет, поэтому мы обнаруживаем, что в том же сеансе есть только sessionStorage;
Новые вкладки, открытые по ссылке (или с помощью window.open), принадлежат одному и тому же сеансу, но открытие новой вкладки всегда инициализирует новый сеанс, даже если веб-сайт тот же, они не принадлежат к одному и тому же сеансу.

Теперь друзья знают, при каких обстоятельствах страницы будут использовать одно и то же хранилище sessionStorage.

localStorage

По сравнению с sessionStorage, localStorage намного проще для понимания.Пока данные, хранящиеся с помощью вышеупомянутого метода, не удаляются вручную, они всегда будут сохраняться, и пока страницы, соответствующие политике одного и того же источника, могут делиться то же самое локальное хранилище.

Это так легко понять~

indexedDB

what is indexedDB

IndexedDB — это локальная база данных, предоставляемая браузером, которую можно создавать и управлять ею с помощью веб-скриптов. Мы все знаем, что файлы cookie могут хранить данные только от 4 до 5 КБ, в то время как веб-хранилище может хранить от 2,5 МБ до 10 МБ (разные браузеры), а indexedDB обычно не менее 250 МБ и даже не имеет верхнего предела. Чувствуется, что это действительно крутая техника.

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

Ниже приведен блог, посвященный indexedDB от Ruan Yifeng. Блогер написал очень подробно, с концепциями и операциями. Я чувствую, что эта технология может быть использована в будущем, поэтому вы можете узнать о ней заранее.

заброшенный

Не упомянутые в статье Web SQL и globalStorage находятся в основном в заброшенном состоянии, поэтому не пишутся.

Ссылаться на

«Введение в базу данных браузера IndexedDB» — Руан Ифэн
Будут ли данные sessionStorage совместно использоваться несколькими вкладками на одном веб-сайте? Это зависит от того, как открыта вкладка >

Зарегистрируйтесь и уходите с работы~ Праздник 1 мая~

Я первопроходец войны пятерки, ученик начальной школы в мире фронтенда. Поклонись начальству.