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

Постоянное локальное хранилище это одна из областей, где клиентские приложения имеют преимущества перед серверными. Для приложений, таких как операционная система, обеспечивается уровень абстракции для хранения и извлечения данных вроде настроек или статуса выполнения. Эти значения могут быть сохранены в реестре, INI-файлах, XML-файлах или в другом месте в зависимости от принципов платформы. Если ваше клиентское приложение нуждается в локальном хранилище больше чем просто пара ключ/значение, вы можете вставить свою собственную базу данных, придумать свой формат файлов или любое количество других решений.

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

• кукисы включаются в каждый HTTP-запрос, замедляя тем самым ваше веб-приложение на напрасную передачу одних и тех же данных снова и снова;
• кукисы включаются в каждый HTTP-запрос при передаче данных через Интернет в незашифрованном виде (если веб-приложение целиком не передаётся через SSL);
• кукисы ограничены объёмом данных примерно 4 Кб — достаточно, чтобы замедлить ваше приложение (см. выше), но не достаточно, чтобы быть полезным.

Вот что мы действительно хотим:

• много места для хранения;
• работа на стороне клиента;
• учитывать обновление страницы;
• и никакой отправки на сервер.

Перед HTML5 все попытки добиться этого в конечном итоге были по-разному провальными.

Краткая история локального хранилища до HTML5

Вначале был только один Internet Explorer. По крайней мере, Microsoft хотел, чтобы мир так думал. С этой целью в рамках Первой Великой Войны браузеров Microsoft изобрёл очень много вещей и включил их в свой браузер-который-завершил-войну — Internet Explorer. Одна из таких штук называлась DHTML Behaviors, а одна из её форм — userData.

UserData позволяет веб-странице хранить до 64 Кб данных на каждый домен в иерархической XML-подобной структуре. Доверенные домены, такие как интранет-сайты могут хранить в десять раз больше. И эй, 640 Кб должно быть достаточно для каждого. IE не представил диалога разрешений в какой-либо форме, поэтому нет способа увеличить объём доступной памяти.

В 2002 году компания Adobe представила функцию во Flash 6, которая получилась неудачной и с названием, вводящим в заблуждение — «Flash-кукисы». В среде Flash эта возможность известна более правильно как Local Shared Objects (локальные доступные объекты, LSO). Вкратце, она позволяет Flash-объектам хранить до 100 Кб данных на каждый домен. Брэд Нойберг разработавший ранний прототип моста между Flash и JavaScript назвал её AMASS (AJAX Massive Storage System), но она была ограничена некоторыми причудами Flash-дизайна. К 2006 году с появлением ExternalInterface во Flash 8 доступ к LSO через JavaScript стал на порядок проще и быстрее. Брэд переписал AMASS и интегрировал её в популярный Dojo Toolkit под псевдонимом dojox.storage. Flash «бесплатно» даёт каждому домену 100 Кб для хранения. Кроме того, он предлагает пользователю при запросе увеличивать объём хранения на порядок (1 Мб, 10 Мб и т. д.).

В 2007 году Google запустила Gears, открытый плагин для браузера направленный на обеспечение дополнительных возможностей. Gears предоставляет API для встроенной базы данных на основе SQLite. К 2010 году Google приложил усилия на перемещение всех возможностей Gears в веб-стандарты HTML5, так что в конце концов Google Gears была приостановлена.

В то же время Брэд Нойберг и другие продолжали вкалывать на dojox.storage чтобы обеспечить единый интерфейс для всех этих разных плагинов и API. На 2009 год dojox.storage может автоматически определить (и обеспечить универсальный интерфейс) Adobe Flash, Gears, Adobe AIR и ранний прототип хранилища HTML5, который был реализован только в старых версиях Firefox.

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

Введение в хранилище HTML5

То, что я буду называть «HTML5-хранилище» в спецификации именуется «веб-хранилище», которое в своё время было частью спецификации HTML5, но затем выделено в отдельную спецификацию по неинтересным для вас политическим мотивам. Некоторые разработчики браузеров также называют его «Локальное хранилище» или «DOM-хранилище». Ситуацию с именами осложняют некоторые похожие названия из других стандартов, о которых пойдёт речь ниже.

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

Какие браузеры? Ну, последние версии практически каждого браузера поддерживает HTML5-хранилище... даже Internet Explorer!

С помощью JavaScript вы можете получить доступ к HTML5-хранилищу через объект localStorage глобального объекта window. Перед использованием вы должны проверить, что браузер поддерживает технологию.

Проверка на HTML5-хранилище

function supports_html5_storage() {
  try {
    return 'localStorage' in window  && window['localStorage'] !== null;
  } catch (e) {
    return false;
  }
}

Вместо самостоятельного написания этой функции, вы можете использовать библиотеку Modernizr.

if (Modernizr.localstorage) {
  // window.localStorage доступно!
} else {
  // нет встроенной поддержки HTML5-хранилища
}

Использование HTML5-хранилища

HTML5-хранилище базируется на именах пар ключ/значение. Вы сохраняете информацию, основываясь на имени ключа, а затем можете получить эти данные с тем же ключом. Имя ключа это строка. Данные могут быть любого типа, который поддерживает JavaScript, включая строки, логические, целые числа или числа с плавающей запятой. Однако в действительности данные хранятся в виде строки. Если вы сохраняете и извлекаете не строки, то надо будет использовать такие функции как parseInt() или parseFloat(), чтобы перевести полученные данные в корректные типы JavaScript.

Интерфейс хранилища {
  Получить через getItem(ключ);
  Установить через setItem(ключ, данные);
};

Вызов setItem() с существующим именем ключа молча перепишет предыдущее значение. Вызов getItem() с несуществующим ключом вернет NULL, а не вызовет исключение.

Подобно другим объектам JavaScript вы можете обращаться к объекту localStorage как к ассоциативному массиву. Вместо использования методов getItem() и setItem(), вы можете просто указать квадратные скобки. Например, этот фрагмент кода

var foo = localStorage.getItem("bar");
// ...
localStorage.setItem("bar", foo);

может быть переписан с использованием синтаксиса квадратных скобок:

var foo = localStorage["bar"];
// ...
localStorage["bar"] = foo;

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

Интерфейс хранилища {
  Удалить через removeItem(ключ);
  clear();
}

Вызов removeItem() с несуществующим ключом ничего не вернёт.

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

Интерфейс хранилища {
  length
  Получить key(целое неотрицательное число);
}

Если при вызове key() индекс лежит не в диапазоне от 0 до (length-1), то функция вернет null.

Слежение за областью HTML5-хранилища

Если вы хотите программно отслеживать изменения хранилища, то должны отлавливать событие storage. Это событие возникает в объекте window, когда setItem(), removeItem() или clear() вызываются и что-то изменяют. Например, если вы установили существующее значение или вызвали clear() когда нет ключей, то событие не сработает, потому что область хранения на самом деле не изменилась.

Событие storage поддерживается везде, где работает объект localStorage, включая Internet Explorer 8. IE 8 не поддерживает стандарт W3C addEventListener (хотя он, наконец-то, будет добавлен в IE 9), поэтому, чтобы отловить событие storage нужно проверить, какой механизм событий поддерживает браузер (если вы уже проделывали это раньше с другими событиями, то можете пропустить этот раздел до конца). Перехват события storage работает так же, как и перехват других событий. Если вы предпочитаете использовать jQuery или какую-либо другую библиотеку JavaScript для регистрации обработчиков событий, то можете проделать это и со storage тоже.

if (window.addEventListener) {
  window.addEventListener("storage", handle_storage, false);
} else {
  window.attachEvent("onstorage", handle_storage);
};

Функция обратного вызова handle_storage будет вызвана с объектом StorageEvent, за исключением Internet Explorer, где события хранятся в window.event.

function handle_storage(e) {
  if (!e) { e = window.event; }
}

В данном случае переменная e будет объектом StorageEvent, который обладает следующими полезными свойствами.

* Примечание: свойство url изначально называлось uri и некоторые браузеры поддерживали это свойство перед изменением спецификации. Для обеспечения максимальной совместимости вы должны проверить существует ли свойство url, и если нет, то проверить вместо него свойство uri.

Событие storage нельзя отменить, внутри функции обратного вызова handle_storage нет возможности остановить изменение. Это просто способ браузеру сказать вам: «Эй, это только что случилось. Вы ничего не можете сделать, я просто хотел, чтобы вы знали».

Ограничения в текущих браузерах

Говоря об истории локального хранилища с помощью сторонних плагинов, я упомянул про ограничения каждой техники. Я вспомнил, что не сказал ничего об ограничениях теперь уже стандартного HTML5-хранилища. Я дам вам ответы, а затем объясню их. Ответы в порядке важности такие: «5 мегабайт», «QUOTA_EXCEEDED_ERR» и «нет».

«5 мегабайт» — сколько места для хранения выдается по умолчанию. Это значение на удивление одинаково во всех браузерах, хотя и сформулировано не более как предложение в спецификации HTML5. Надо понимать, что вы храните строки, а не данные в исходном формате. Если вы храните много целых чисел или чисел с плавающей запятой, разница в представлении может оказаться большой. Каждая цифра в числе с плавающей запятой хранится в виде символа, а не в обычном представлении для таких чисел.

«QUOTA_EXCEEDED_ERR» это исключение, которое вы получите, если превысите свою квоту в 5 Мб. «Нет» является ответом на следующий очевидный вопрос: «Могу ли я попросить у пользователя больше пространства для хранения?». На момент написания в браузерах не реализован какой-либо механизм для веб-разработчиков, чтобы запросить больше места для хранения. Некоторые браузеры (например, Opera) позволяют пользователю контролировать квоты хранилища для каждого сайта, но это чисто инициатива пользователя, не связанная с тем, что вы как разработчик можете встроить в ваше веб-приложение.

HTML5-хранилище в действии

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

Как это работает? Каждый раз, когда происходит изменение в игре, мы будем вызывать эту функцию.

function saveGameState() {
    if (!supportsLocalStorage()) { return false; }
    localStorage["halma.game.in.progress"] = gGameInProgress;
    for (var i = 0; i < kNumPieces; i++) {
        localStorage["halma.piece." + i + ".row"] = gPieces[i].row;
        localStorage["halma.piece." + i + ".column"] = gPieces[i].column;
    }
    localStorage["halma.selectedpiece"] = gSelectedPieceIndex;
    localStorage["halma.selectedpiecehasmoved"] = gSelectedPieceHasMoved;
    localStorage["halma.movecount"] = gMoveCount;
    return true;
}

Как видите, используется объект localStorage для сохранения процесса игры (gGameInProgress, логический тип). Далее перебираются все фишки (gPieces, массив JavaScript) и сохраняется строка и столбец для каждой из них. После чего сохраняются некоторые дополнительные состояния игры, включая выбранную фишку (gSelectedPieceIndex, целое число), фишку, которая находится в середине длинной серии прыжков (gSelectedPieceHasMoved, логический тип) и общее число сделанных ходов (gMoveCount, целое число).

При загрузке страницы вместо автоматического вызова функции newGame(), которая бы вернула все переменные в исходные значения, мы вызываем resumeGame(). Функция resumeGame() с помощью HTML5-хранилища проверяет состояние игры в локальном хранилище. Если оно есть, то восстанавливает значения с использованием объекта localStorage.

function resumeGame() {
    if (!supportsLocalStorage()) { return false; }
    gGameInProgress = (localStorage["halma.game.in.progress"] == "true");
    if (!gGameInProgress) { return false; }
    gPieces = new Array(kNumPieces);
    for (var i = 0; i < kNumPieces; i++) {
        var row = parseInt(localStorage["halma.piece." + i + ".row"]);
        var column = parseInt(localStorage["halma.piece." + i + ".column"]);
        gPieces[i] = new Cell(row, column);
    }
    gNumPieces = kNumPieces;
    gSelectedPieceIndex = parseInt(localStorage["halma.selectedpiece"]);
    gSelectedPieceHasMoved = localStorage["halma.selectedpiecehasmoved"] == "true";
    gMoveCount = parseInt(localStorage["halma.movecount"]);
    drawBoard();
    return true;
}

Наиболее важной частью этой функции является оговорка, о которой я упоминал ранее в этой главе и повторю здесь: данные хранятся в виде строк. Если вы храните нечто другое, а не строки, вам нужно конвертировать их при получении. К примеру, флаг о том, что игра в процессе (gGameInProgress) является логическим типом. В функции saveGameState() мы просто храним его и не беспокоимся о типе данных.

localStorage["halma.game.in.progress"] = gGameInProgress;

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

gGameInProgress = (localStorage["halma.game.in.progress"] == "true");

Аналогичным образом, число ходов хранится в gMoveCount как целое, в функции saveGameState() мы просто сохраняем его.

localStorage["halma.movecount"] = gMoveCount;

Но в функции resumeGame() мы должны конвертировать значение в целое, используя встроенную в JavaScript функцию parseInt().

gMoveCount = parseInt(localStorage["halma.movecount"]);

За пределами пары ключ/значение: конкурентное видение

Хотя в истории было много уловок и обходных путей, нынешнее состояние HTML5-хранилища на удивление благополучно. Новый API был стандартизирован и включен во все основные браузеры, платформы и устройства. Для веб-разработчика такое увидишь не каждый день, не так ли? Но это больше, чем «5 мегабайт пар ключ/значение» и будущее постоянного локального хранилища это... как бы сказать... ну, пусть конкурентное видение.

Одно видение является аббревиатурой, которую вы уже знаете — SQL. В 2007 году Google запустил Gears, кроссбраузерный плагин с открытым исходным кодом, в который включена встроенная база данных на основе SQLite. Этот ранний прототип позже повлиял на создание спецификации Web SQL Database. База данных Web SQL (ранее известная как «WebDB») обеспечивает тонкую оболочку вокруг базы данных SQL, что позволяет делать следующие вещи из JavaScript:

openDatabase('documents', '1.0', 'Local document storage', 5*1024*1024, function (db) {
  db.changeVersion('', '1.0', function (t) {
    t.executeSql('CREATE TABLE docids (id, name)');
  }, error);
});

Как вы можете видеть, большая часть действий находится в строке с методом ExecuteSQL. Эта строка может поддерживать любые команды SQL, в том числе SELECT, UPDATE, INSERT и DELETE. Это все равно, что серверное программирования баз данных, за исключением того, что вы делаете это с JavaScript! О радость!

Спецификация базы данных Web SQL была реализована в четырёх браузерах и платформах.

Конечно, если вы использовали более чем одну базу данных в своей жизни, то знаете, что «SQL» это скорее маркетинговый термин, чем жёсткий и быстрый стандарт (кто-то может сказать то же самое об HTML5, но это не важно). Конечно, есть актуальная спецификация SQL (она называется SQL-92), но в мире нет сервера баз данных, который соответствует только этой спецификации. Есть Oracle SQL, Microsoft SQL, SQL в MySQL, SQL в PostgreSQL, SQL в SQLite. В действительности, каждый из этих продуктов с течением времени добавляет новые функции SQL, так что недостаточно даже произнести «SQL в SQLite». Вы должны сказать «версия SQL, который поставляется вместе с SQLite версии X.Y.Z».

Все это подводит нас к следующей оговорке, в настоящее время размещённой вверху спецификации Web SQL.

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

Именно на этом фоне я расскажу вам о другом конкурентном видении для продвинутых, постоянное локальное хранилище для веб-приложений: Indexed Database API, ранее известное как «WebSimpleDB», теперь ласково называемое IndexedDB.

Indexed Database API предоставляет то, что называется хранилище объектов, при этом много идей заимствовано из баз данных SQL. Есть «базы данных» с «записями», каждая запись имеет определённое количество «полей». У каждого поля есть характерный тип данных, который определяется при создании базы данных. Вы можете выбрать часть записей, затем перечислить их «курсором». Изменения в хранилище объектов обрабатываются с «транзакциями».

Если вы хоть раз программировали базы данных SQL, то эти термины, вероятно, вам знакомы. Основная разница в том, что хранилище объектов не имеет структурированного языка запросов. Вы не напишете условие вроде «SELECT * from USERS where ACTIVE = 'Y'». Вместо этого используются методы, предоставляемые хранилищем объектов для открытия базы USERS, перечисления записей, фильтрации наших записей и использование методов доступа для получения значения каждого поля оставшихся записей. An early walk-through of IndexedDB (Ранний проход IndexedDB) это хорошее руководство о том, как работает IndexedDB и сравнение IndexedDB с Web SQL.

На момент написания IndexedDB был реализован только в бета-версии Firefox 4. Для контраста, Mozilla заявила, что никогда не будет воплощать Web SQL. Google заявил, что они рассматривают поддержку IndexedDB для Chromium и Google Chrome. И даже Майкрософт заявил, что IndexedDB «отличное решение для веба».

Что вы как веб-разработчик можете делать с IndexedDB? На данный момент практически ничего, кроме некоторых технологических демонстраций. Через год? Возможно.

Дальнейшее чтение

HTML5-хранилище

• Спецификация HTML5 Storage 
• Introduction to DOM Storage на MSDN
• Web Storage: easier, more powerful client-side data storage на Opera Developer Community
• DOM Storage на Mozilla Developer Center
• Unlock local storage for mobile Web applications with HTML5, руководство на IBM DeveloperWorks

Web SQL Database

• Спецификация Web SQL Database
• Introducing Web SQL Databases
• Демонстрация Web Database
• persistence.js

IndexedDB

• Спецификация Indexed Database API
• Beyond HTML5: Database APIs and the Road to IndexedDB
• Firefox 4: An early walk-through of IndexedDB