Веб сторадж для чего: Веб хранилище (API) — Интерфейсы веб API

Веб хранилище (API) — Интерфейсы веб API

Web Storage API предоставляет механизмы, при помощи которых браузеры могут безопасно хранить пары ключ/значение в более интуитивно понятной манере, чем куки (cookies).

В основе Веб хранилища лежат два механизма:

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

Обе функции доступны через Window.sessionStorage и Window.localStorage свойства (если быть более точным, в браузерах, поддерживающих хранилища объект Window выполняет объекты WindowLocalStorage и WindowSessionStorage, которые содержат свойства localStorage и sessionStorage) — вызов одного из них создаёт представление объекта

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

Примечание: Начиная с версии 45 Firefox, когда браузер прекращает работу/перезагружается, объем данных, сохранённых для каждого источника, ограничивается 10 МБ. Это было сделано, чтобы избежать проблем с памятью, вызванных чрезмерным использованием веб-хранилища.

Примечание: Доступ к веб хранилищу из iFrame третьей стороны запрещён, если пользователь отключил cookies третьих сторон (Firefox ведёт себя так с версии 43).

Примечание: Web Storage это не тоже самое, что mozStorage (Mozilla’s XPCOM интерфейсы для SQLite) или Session store API (XPCOM утилита хранения для расширений).

Storage

Позволяет присваивать, извлекать (читать) и удалять данные для специфического домена и типа хранилища (сессии или локального).

Window

Web Storage API расширяет Window объект, добавляя к нему два новых свойства — Window. sessionStorage и Window.localStorage — которые предоставляют доступ к сессии текущего домена и к соответствующим локальным

Storage объектам, и Window.onstorage (en-US) обработчик событий, который срабатывает при изменении объекта хранилища (например, при сохранении нового элемента)

StorageEvent (en-US)

Событие storage срабатывает на объекте документа Window при изменении объекта хранилища.

Чтобы проиллюстрировать типичное использование веб хранилища, мы создали простейший пример и назвали его Web Storage Demo. На лендинге нашего примера вы найдёте элементы управления для изменения фонового цвета, шрифта и изображения. Когда вы выбираете разные опции, страница мгновенно меняется. В дополнение, ваш выбор сохраняется в локальном хранилище, чтобы, если вы покинете страницу и потом загрузите её снова, ваши настройки восстановились.

Также, мы сделали страницу вывода событий, которая выводит информацию о хранилище, каждый раз когда срабатывает событие StorageEvent (en-US). Загрузите эту страницу в другой вкладке браузера, затем вернитесь на лендинг и поменяйте значения цвета, шрифта или изображения и понаблюдайте, как меняется выводимая информация.

Specification
HTML Living Standard # webstorage

Window.localStorage

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Window.sessionStorage

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Многие браузеры в наши дни поддерживают опции приватности, названные «Инкогнито» или «Приватный просмотр» и т.п., что позволяет быть уверенными, что следов приватной сессии не остаётся после закрытия браузера. Это фундаментальная несовместимость с Веб хранилищем по очевидным причинам. Таким образом, производители браузеров экспериментируют с различными сценариями, как справиться с этой несовместимостью.

Многие браузеры выбрали стратегию, когда API хранилища доступно и кажется полностью функциональным, с одним большим отличием — все данные хранилища стираются после закрытия браузера.

Для этих браузеров есть ещё другие интерпретации того, что следует делать с хранимыми данными (от обычного режима браузера). Следует ли им быть доступными в приватном режиме? Затем, есть несколько браузеров, особенно Safari, которые выбрали решение, в котором хранилище доступно, но пустое и имеет квоту 0 байт, фактически, делая невозможной запись туда данных.

Разработчики должны быть осведомлены об этих различных реализациях и принимать их во внимание при разработке веб-сайтов, зависящих от API Веб хранилища. Для получения более подробной информации, пожалуйста, посмотрите на этот пост блога WHATWG, специально посвящённый этой теме.

• Использование Web Storage API
• HTML5 Storage API By Venkatraman

Found a content problem with this page?

• Edit the page on GitHub.
• Report the content issue.
• View the source on GitHub.

Want to get more involved?

Learn how to contribute.

This page was last modified on 000Z»>11 февр. 2023 г. by MDN contributors.

HTML5 Web Storage | Обзор веб-хранилища

85

Веб-программирование — HTML5 — Обзор Web Storage

В интернете информацию можно сохранять в двух местах: на веб-сервере и на веб-клиенте (т.е. компьютере посетителя страницы). Определенные типы данных лучше хранить в одном из этих мест, а другие типы — в другом.

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

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

До HTML5 единственным способом локального хранения данных было использование механизма файлов cookies, который первоначально был разработан для обмена небольшими объемами идентифицирующей информации между веб-серверами и браузерами. Файлы cookies подходят идеально для хранения небольших объемов данных, но модель JavaScript для работы с ними несколько неуклюжа. Система файлов cookies также вынуждает разработчика возиться со сроками действия и бесполезно пересылать данные туда и обратно по интернету с каждым запросом страницы.

В HTML5 вводится лучшая альтернатива файлам cookies, которая позволяет легко и просто сохранять информацию на компьютере посетителя. Эта информация может храниться на клиентском компьютере неограниченное время, не отправляется на веб-сервер (если только разработчик не сделает это сам), может быть большого объема и для работы с ней требуется всего лишь пара простых, эффективных объектов JavaScript.

Эта возможность называется веб-хранилищем (Web Storage) и особенно хорошо подходит для применения с автономным режимом работы вебсайтов, т.к. позволяет создавать самодостаточные автономные приложения, которые могут сохранять всю требуемую им информацию даже при отсутствии подключения к интернету.

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

Сохраняемая в веб-хранилище информация в действительности сохраняется не в интернете, а на компьютере посетителя веб-страницы. Иными, словами, веб-хранилище означает хранение данных не в интернете, а хранение данных из интернета.

Существуют два типа веб-хранилищ, которые так или иначе связаны с двумя объектами:

Локальное хранилище

Использует объект localStorage для хранения данных для всего веб-сайта на постоянной основе. Это означает, что если веб-страница сохранит данные в локальном хранилище, эти данные будут доступны для пользователя, когда он возвратится на эту веб-страницу на следующий день, на следующей неделе или в следующем году.

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

) А другие браузеры могут предоставлять пользователю возможность просмотра данных для каждого отдельного веб-сайта и удалять данные для выбранного сайта или сайтов.

Хранилище данных сеансов

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

С точки зрения кода веб-страницы, как локальное хранилище, так и хранилище данных сеансов работают абсолютно одинаково. Разница состоит лишь в длительности хранения данных.

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

Как локальное хранилище, так и хранилище сеансов связано с доменом веб-сайта. Таким образом, если сохранить в локальном хранилище данные для страницы www.professorweb.ru/index.html, эти данные будут доступны для страницы www.professorweb.ru/contact.html, т.к. обе эти страницы имеют один и тот же домен. Но эти данные не будут доступны для страниц других доменов.

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

Хотя спецификация HTML5 не устанавливает никаких жестких правил в отношении максимального объема хранилища, большинство браузеров ограничивают его 5 Мбайт. В этот объем можно упаковать много данных, но его будет недостаточно, если вы хотите использовать локальное хранилище для оптимизации производительности и кэшировать в нем изображения или видео большого объема (и, по правде говоря, локальное хранилище не предназначено для таких целей).

Для хранения большого объема данных все еще развивающийся стандарт базы данных IndexedDB допускает локальное хранение намного большего объема — обычно 50 Мбайт для начала и больше, по согласию пользователя.

Сохранение данных

Прежде чем поместить фрагмент информации в локальное хранилище или хранилище сеансов, ему необходимо присвоить описательное имя. Это имя называется ключом (key) и нужно для того, чтобы данные можно было извлечь в будущем.

Синтаксис для сохранения фрагмента данных следующий:

localStorage[keyName] = data;

Допустим, например, что нам нужно сохранить фрагмент текста, присвоив ему имя текущего пользователя. Для этих данных мы можем использовать ключ username:

// JS
localStorage["username"] = "Ivan Petrov";

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

  <fieldset>
      <legend>Веб-хранилище</legend>
      <label for="localData">Этот текст сохранится в локальном хранилище:</label>
      <input><br>
      <label for="sessionData">Этот текст сохранится в хранилище данных сессии:</label>
      <input>
  </fieldset>
  <div>
      <button>Сохранить</button>
      <button>Загрузить</button>
  </div>

function saveData() {
    // Получаем значения текстовых полей
    var localData = document. getElementById("localData").value;
    var sessionData = document.getElementById("sessionData").value;

    // Сохраняем текст, введенный в текстовом поле, в локальном хранилище
    localStorage["localData"] = localData;
    
    // Сохраняем текст, введенный в текстовом поле, в хранилище сессий
    sessionStorage["sessionData"] = sessionData;
}

function loadData() {
    // Загружаем сохраненные данные из хранилищ
    var localData = localStorage["localData"];    
    var sessionData = sessionStorage["sessionData"];

    // Отображаем эти данные в текстовых полях
    if (localData != null) {
        document.getElementById("localData").value = localData;
    }
    if (sessionData != null) {
        document.getElementById("sessionData").value = sessionData;
    }
}

Страница содержит два текстовых поля: для локального хранилища (вверху) и для хранилища сеансов (внизу). Нажатие кнопки «Сохранить» сохраняет текст, введенный в текстовые поля, а нажатие кнопки «Загрузить» выводит в полях соответствующие сохраненные данные.

Веб-хранилище также поддерживает менее распространенный синтаксис свойств. Согласно правилам этого синтаксиса, мы обращаемся к ячейке хранения с именем username как localStorage.username, а не localStorage[«username»]. Оба типа синтаксиса равнозначны, и использование того или другого является вопросом личного предпочтения.

Веб-хранилище не работает без веб-сервера

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

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

Что же происходит, если открыть страницу, которая использует веб-хранилище, с локального жесткого диска? Все зависит от браузера. Браузер Internet Explorer, похоже, полностью утрачивает поддержку веб-хранилища. Объекты localStorage и sessionStorage исчезают, и попытка использовать их вызывает ошибку JavaScript.

В браузере Firefox объекты localStorage и sessionStorage остаются на месте и, вроде бы, поддерживаются (даже Modernizr определяет, что поддерживаются), но все, что отправляется на хранение, исчезает неведомо куда. В браузере Chrome опять же что-то другое — большая часть функциональности веб-хранилища работает как следует, но некоторые возможности (например, событие onStorage) не работают.

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

Поддержка веб-хранилища браузерами

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

Поддержка браузерами локального хранилища и хранилища данных сеансов

Браузер	IE	Firefox	Chrome	Safari	Opera	Safari iOS	Android
Минимальная версия	8	3.5	5	4	10.5	2	2

Все эти браузеры предоставляют возможность локального хранилища и хранилища данных сеанса. Но для поддержки события onStorage требуются более поздние версии браузеров, например IE 9, Firefox 4 или Chrome 6.

Самой проблемной является версия IE 7, которая не поддерживает веб-хранилище вообще. В качестве обходного решения можно эмулировать веб-хранилище посредством файлов cookies. Это не совсем идеальное решение, но оно работает. Хотя официального сценария для закрытия этого пробела не существует, несколько хороших отправных точек можно найти на странице HTML5 Cross Browser (в разделе «Web Storage»).

веб-хранилище: учебник для начинающих | Хранилище данных

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

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

Веб-хранилище и файлы cookie

Традиционный способ хранения данных на стороне клиента — использование файлов cookie HTTP. Есть много различий между веб-хранилищем и файлами cookie. Давайте сосредоточимся на прагматических различиях между двумя подходами к хранению данных на стороне клиента.

Механизм хранения

Файлы cookie представляют собой структурированные данные, отправляемые в браузер веб-сервером как часть ответа сервера на запрос.

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

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

Этот подход имеет много преимуществ, наиболее очевидным из которых является то, что он теоретически ведет к повышению производительности Web. Связано: статьи о веб-производительности Кроме того, поскольку веб-хранилище может работать без HTTP-запросов/ответов (помимо начальной транзакции обслуживания веб-страницы), при соответствующей реализации данные, хранящиеся в браузере пользователя, могут обновляться. и безопасно модифицироваться, даже если пользователь потеряет свое сетевое соединение.

Несколько экземпляров браузера

Веб-хранилище может обрабатывать ситуации, когда у пользователя открыто несколько окон/вкладок браузера. Данные, хранящиеся и/или обновляемые в одном окне браузера, переносятся в другие окна браузера, если другие окна браузера находятся на том же веб-сайте. С другой стороны, файлы cookie

не предназначены для условий, связанных с несколькими окнами браузера.

Ограничение размера хранилища

Ограничение размера файлов cookie HTTP и веб-хранилища зависит от разных веб-браузеров. Но, как правило, рекомендуется ограничивать размер файлов cookie примерно до 4.0 kB для обеспечения хорошей кросс-браузерной поддержки. (Существует инструмент тестирования файлов cookie, который позволяет вам проверить ограничения размера файлов cookie HTTP вашего браузера.) Спецификация веб-хранилища W3C не рекомендует ограничение размера хранилища по умолчанию, оставляя это на усмотрение браузеров.

Однако на практике веб-хранилище спокойно превышает лимит файлов cookie в 4,0 КБ. Общепринятое ограничение для объектов веб-хранилища составляет около 5 МБ. То есть ограничение размера веб-хранилища составляет +124,527% больше , чем у файлов cookie. (Существует также инструмент тестирования веб-хранилища, который позволяет проверить ограничения размера веб-хранилища вашего браузера.)

Типы веб-хранилищ

Существует два способа хранения данных на стороне клиента с помощью веб-хранилища: sessionStorage и localStorage .

Тип веб-хранилища	Время жизни сохраненных данных	Структура данных	Тип данных
хранилище сеансов	Только сеанс	Пары ключ/значение	Строка
локальное хранилище	Постоянный	Пары ключ/значение	Строка

sessionStorage

sessionStorage предназначен для хранения данных на стороне клиента только на время сеанса просмотра.

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

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

localStorage

С точки зрения реализации, localStorage работает почти так же, как сессионное хранилище . localStorage использует те же методы JavaScript (например,

getItem , setItem и т. д.), а также хранит элементы данных в виде пар ключ/значение. Однако хранение данных в виде объекта localStorage означает, что данные будут сохраняться между сеансами пользователя. Другими словами, данные будут доступны при следующем посещении пользователем вашего сайта.

Поддержка веб-хранилища в браузере

Caniuse.com сообщает, что веб-хранилище хорошо поддерживается браузером.

Таблица поддержки веб-хранилища

Браузер	Версия
Internet Explorer	IE 8 и выше
Мозилла Фаерфокс	Firefox 3. 5 и выше
Гугл Хром	Хром 4 и выше
Сафари Apple	Safari 4 и выше
Опера	Opera 11.5 и выше

В настоящее время спецификацией веб-хранилища является Кандидатская рекомендация W3C .

Существует 5 уровней рекомендаций, а «Рекомендация-кандидат» — третий из пяти уровней. Существующая спецификация веб-хранилища является достаточно зрелой, поскольку она уже не является рабочим проектом, но в то же время она все еще не является окончательной. Поддержка старых браузеров, в которых нет функций веб-хранилища, может осуществляться с помощью полифилла.

Одним из таких вариантов поддержки localStorage является Store.js.

Вопросы конфиденциальности и безопасности данных

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

Но это также может вызвать проблемы для веб-сайтов, использующих субдомены. В этом случае доступны обходные пути, такие как пакет с открытым исходным кодом под названием Cross-Storage, разработанный Zendesk. Как и в случае с любыми механизмами хранения данных на стороне клиента, защита хранимых данных является важным фактором.

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

Целостность данных также вызывает беспокойство. Должны быть предусмотрены средства защиты от сценариев, в которых происходит сбой события хранения данных. Сбой может произойти, если пользователь отключил веб-хранилище, или если у него/нее больше нет свободного места на компьютере, или если превышен предельный размер веб-хранилища его/ее браузера.

Спецификация веб-хранилища описывает стандартизированные ошибки/предупреждения, которые выводятся после событий сбоя хранилища, таких как исключение QuotaExceededError .

Как насчет IndexedDB?

С точки зрения хранения данных на стороне клиента API индексированной базы данных (IndexedDB) предлагает многие из тех же преимуществ, что и веб-хранилище. Но IndexedDB не является частью спецификации веб-хранилища, поэтому он выходит за рамки этого руководства. Однако об IndexedDB стоит кратко рассказать из-за его общего сходства и, возможно, взаимосвязанности с реализациями Web Storage.

Хранение данных в IndexedDB несколько сложнее по сравнению с Web Storage. Но это также открывает больше возможностей для сложных архитектур данных и взаимосвязей. В IndexedDB хранимые данные индексируются так же, как ваша любимая серверная система управления реляционными базами данных (RDMS), которая может быть MySQL, MSSQL, PostgreSQL и т. д. вы также можете запрашивать базы данных IndexedDB способом, аналогичным серверным базам данных, при условии, что вы реализуете язык запросов, способный работать с базами данных IndexedDB. По сравнению с IndexDB возможности извлечения данных Web Storage являются базовыми. Web Storage имеет только два встроенных метода для извлечения данных: .getItem и .key .

(в дополнение к атрибуту длины объектов веб-хранилища, который может выводить количество элементов в области хранения). Таким образом, для более сложного хранения данных вы можете рассмотреть IndexedDB вместо веб-хранилища.

Связанный контент

• Советы по созданию вашего первого веб-приложения
• Проектирование в цифрах: анализ данных для веб-дизайнеров
• Полное руководство по микроформатам: справочник и примеры

Мартин Май живет в Лондоне, Англия, и является совладельцем Mays Digital, агентства веб-дизайна, специализирующегося на дизайне, разработке и UX.

Введение в веб-хранилище (Windows)

• Статья
• 20.10.2016

Примечание   Эта статья относится к Internet Explorer. Информацию о веб-хранилище в Microsoft Edge см. в разделе Интернет-хранилище и автономное хранилище.

 

API веб-хранилища включает два связанных механизма для безопасного хранения данных на стороне клиента с использованием объектной модели документа (DOM): sessionStorage и localStorage . Эти объекты были представлены в Windows Internet Explorer 8.

Что такое веб-хранилище?

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

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

Веб-хранилище также предлагает значительно больше места на диске, чем файлы cookie. В Windows Internet Explorer файлы cookie могут хранить только 4 килобайта (КБ) данных. Всего в байтах может быть одна пара имя/значение размером 4 КБ или может быть до 20 пар имя/значение, имеющих общий размер 4 КБ. Для сравнения, Web Storage предоставляет примерно 10 мегабайт (МБ) для каждой области хранения.

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

Объекты сценариев веб-хранилища

• window.sessionStorage
• окно.localStorage
• Объект хранения

window.sessionStorage

Хранилище сеансов предназначено для сценариев, в которых пользователь выполняет одну транзакцию. Атрибут sessionStorage объекта window поддерживает пары ключ/значение для всех страниц, загруженных в течение времени жизни одной вкладки (на время контекста просмотра верхнего уровня). Например, на странице может быть флажок, который пользователь устанавливает, чтобы указать, что он хочет застраховаться.

 <метка>
    
    Я хочу страховку на эту поездку.

 

Более поздняя страница может проверить из сценария, установил ли пользователь флажок.

 если (sessionStorage.insurance) { ... }
 

Объект Storage поддерживает свойства расширения («страхование» в предыдущем примере). Если имя свойства не существует, для его хранения автоматически создается пара ключ/значение. Обратите внимание, что пары ключ/значение всегда хранятся в виде строк. Различные типы данных, такие как числа, логические значения и структурированные данные, должны быть преобразованы в строки перед сохранением в области хранения.

После того, как значение было сохранено в sessionStorage , его можно получить с помощью сценария, запущенного на другой странице в том же контексте. Когда загружается другой документ, sessionStorage инициализируется из памяти для URL-адресов того же происхождения. (Подробнее см. в разделе «Безопасность и конфиденциальность».)

Примечание   Несмотря на то, что это разрешено HTML5, Internet Explorer 8 не возобновляет sessionStorage после аварийного восстановления браузера.

 

window.localStorage

Механизм локального хранения охватывает несколько окон и сохраняется за пределами текущего сеанса. Атрибут localStorage предоставляет постоянные области хранения для доменов. Это позволяет веб-приложениям хранить почти 10 МБ пользовательских данных, таких как целые документы или почтовый ящик пользователя, на клиенте из соображений производительности.

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

 <р>
  Вы просмотрели эту страницу
  неисчислимое количество
  время (с). 

<скрипт>
  var storage = window.localStorage;
  если (!storage.pageLoadCount) storage.pageLoadCount = 0;
  storage.pageLoadCount = parseInt(storage.pageLoadCount, 10) + 1;
  document.getElementById('count').innerHTML = storage.pageLoadCount;

 

Примечание   Перед увеличением pageLoadCount его необходимо сначала преобразовать в число с помощью метода parseInt (JScript 5.6).

 

Каждый домен и поддомен имеет свою отдельную локальную область хранения. Домены могут получить доступ к областям хранения поддоменов, а поддомены могут получить доступ к областям хранения родительских доменов. Например, localStorage['example.com'] доступен для example.com и любого из его поддоменов. Поддомен localStorage['www.example.com'] доступен для example.com , но не для других поддоменов, таких как mail.example.com .

Объект хранилища

Следующие свойства и методы поддерживаются как сеансовыми, так и локальными объектами хранилища.

прозрачный	Удаляет все пары ключ/значение из области веб-хранилища.
конструктор	Возвращает ссылку на конструктор объекта.
getItem	Извлекает текущее значение, связанное с ключом веб-хранилища.
ключ	Извлекает ключ по указанному индексу в коллекции.
длина	Извлекает длину списка ключей/значений.
оставшееся пространство	Извлекает оставшееся количество символов UTF-16, разрешенное для объекта хранилища.
removeItem	Удаляет пару ключ/значение из коллекции веб-хранилища.
набор	Задает пару ключ/значение.

 

События веб-хранилища

Internet Explorer запускает события при обновлении данных в области хранилища, чтобы можно было синхронизировать информацию между несколькими экземплярами браузера или вкладками.

Поддерживаются следующие события.

• на хранение
• onstoragecommit

onstorage

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

Если целевой объект document в данный момент не активен, Internet Explorer не запускает никаких событий.

onstoragecommit

Internet Explorer использует файлы XML для хранения локального хранилища. Событие onstoragecommit срабатывает, когда локальное хранилище записывается на диск.

Безопасность и конфиденциальность

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

Вот некоторые вещи, которые следует учитывать:

• Контекст просмотра верхнего уровня и имя хоста
• Происхождение определяет пределы хранения
• Очистка складских помещений

Контекст просмотра верхнего уровня и имя хоста

Доступ к области хранения сеанса ограничен контекстом просмотра верхнего уровня. В Internet Explorer для каждой вкладки создается новый контекст просмотра. Сценарий, работающий в одном контексте просмотра верхнего уровня, не имеет доступа к хранилищу, созданному в другом. Сайты могут добавлять данные в хранилище сессий, и они будут доступны для любой страницы с этого имени хоста, открытой в том же окне.

Важно   В рамках этой проверки порт и протокол/схема не оцениваются.

 

Происхождение определяет лимиты хранилища

Ограничения дисковой квоты применяются к домену страницы, которая устанавливает значение, а не к домену, где значение устанавливается. Это предотвращает использование вредоносными сценариями квоты хранилища связанного домена. Это также предотвращает использование такими сценариями случайных поддоменов для хранения неограниченных объемов данных.

Размер хранилища рассчитывается как общая длина всех имен ключей и значений, и одна область хранения может содержать до 10 миллионов байт. Свойство restSpace используется для определения доступного места для хранения.

Очистка областей хранения

Состояние сеанса освобождается, как только закрывается последнее окно, ссылающееся на эти данные. Тем не менее, пользователи могут очистить области хранения в любое время, выбрав Удалить историю просмотров в меню Инструменты 9.