Локално съхранение на бисквитки. Локално съхранение. Основни CRUD операции с локално съхранение

Уеб прегледСъхранение

В Интернет информацията може да се съхранява на две места: на уеб сървъра и на уеб клиента (т.е. компютъра на посетителя на страницата). Определени типове данни е най-добре да се съхраняват на едно от тези места, а други типове на друго.

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

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

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

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

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

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

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

Има два типа уеб хранилище, които са свързани с два обекта по един или друг начин:

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

Разбира се, повечето браузъри предоставят на потребителя и опция за изчистване на локално хранилище. Внедрява се като стратегия "всичко или нищо" в някои браузъри и премахва всички локални данни, подобно на премахването на бисквитките. (Всъщност в някои браузъри системата за бисквитки и локалното хранилище са взаимосвързани, така че единственият начин за изтриване на локални данни е да изтриете бисквитки.) А други браузъри могат да предоставят на потребителя възможността да преглежда данни за всеки отделен уебсайт и да изтрива данни за избрания сайт или сайтове.

Използва обект sessionStorageза временно съхраняване на данни за един прозорец или раздел на браузъра. Тези данни са достъпни само докато потребителят затвори прозореца или раздела, в който момент сесията приключва и данните се изтриват. Но данните за сесията се запазват, ако потребителят навигира до друг уебсайт и след това се върне, стига това да се случи в същия прозорец на браузъра.

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

Използването на локално хранилище предоставя най-добрата възможност за съхраняване на необходимата информация за последващи посещения на уеб страницата от потребителя. А хранилището за сесии се използва за съхраняване на данни, които трябва да бъдат прехвърлени от една страница на друга. (Съхранението на сесии може също да съхранява временни данни, използвани само на една страница, но нормалните JavaScript променливи работят добре за тази цел.)

Както локалното хранилище, така и хранилището за сесии са свързани с домейна на уебсайта. По този начин, ако запишете данните за страницата www..html в локално хранилище, тези данни ще бъдат налични за страницата www..html, тъй като и двете страници имат един и същи домейн. Но тези данни няма да са достъпни за страници от други домейни.

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

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

За съхраняване на големи количества данни, все още развиващ се стандарт за база данни Индексирана база даннипозволява много по-голямо локално съхранение - обикновено 50 MB за начало и повече, ако потребителят се съгласи.

Запазване на данни

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

Синтаксисът за запазване на част от данните е както следва:

localStorage = данни;

// JS localStorage["username"] = "Иван Петров";

Разбира се, запазването на част от статичен текст няма смисъл. Като правило трябва да съхраняваме някакъв вид променливи данни, като текуща дата, резултат от математическо изчисление или текстови данни, въведени от потребителя в полетата на формуляра. Следва пример за запазване на въведени от потребителя текстови данни:

Функция saveData() ( // Вземете стойностите на текстовото поле var localData = document.getElementById("localData"). value; var sessionData = document. getElementById("sessionData"). value; // Запазете текста, въведен в текстово поле към локално хранилище localStorage["localData"] = localData; // Съхраняване на текста, въведен в текстовото поле, в хранилището на сесията sessionStorage["sessionData"] = sessionData; ) функция 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; ) )

Страницата съдържа две текстови полета: едно за локално съхранение (отгоре) и едно за съхранение на сесии (отдолу). Щракването върху бутона "Запазване" записва въведения текст в текстовите полета, а щракването върху бутона "Зареждане" показва съответните запазени данни в полетата.

Уеб хранилището също поддържа по-рядко срещания синтаксис на свойствата. Съгласно правилата на този синтаксис, ние наричаме мястото за съхранение, наречено потребителско име, като localStorage.username, а не localStorage["username"]. И двата вида синтаксис са еквивалентни и използването на единия или другия е въпрос на лични предпочитания.

Уеб съхранението не работи без уеб сървър

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

Тази функция е страничен ефект от начина, по който браузърите разпределят място за локално съхранение. Както беше обсъдено по-рано, браузърите ограничават локалното хранилище за уебсайт до 5 MB, което изисква от тях да асоциират всяка страница, която иска да използва локално хранилище, с домейна на уебсайта.

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

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

Подобни проблеми възникват при използването на File API. Следователно ще си спестите много проблеми, ако поставите страницата, която тествате, на тестов сървър, за да избегнете всички тези несигурности.

Поддръжка на уеб съхранение от браузъри

Уеб съхранението е една от най-поддържаните функции на HTML5, с добро ниво на поддръжка във всеки основен браузър. Таблицата по-долу изброява минималните версии на основните браузъри, които поддържат уеб съхранение:

Всички тези браузъри осигуряват локално съхранение и съхранение на данни за сесии. Поддръжката за събитието onStorage обаче изисква по-нови браузъри като IE 9, Firefox 4 или Chrome 6.

Най-проблемната версия е IE 7, която изобщо не поддържа уеб съхранение. Като заобиколно решение можете да емулирате уеб съхранение с помощта на бисквитки. Не е точно идеалното решение, но работи. Въпреки че няма официален скрипт, който да запълни тази празнина, няколко добри отправни точки могат да бъдат намерени на страницата HTML5 Cross Browser (под „Уеб съхранение“).

The API за уеб съхранениепредоставя механизми, чрез които браузърите могат да съхраняват двойки ключ/стойност, по много по-интуитивен начин от използването на бисквитки.

Концепции и използване на уеб съхранение

Двата механизма в Web Storage са както следва:

• sessionStorage поддържа отделна зона за съхранение за всеки даден източник, която е налична за продължителността на сесията на страницата (докато браузърът е отворен, включително презареждане и възстановяване на страници)
  • Съхранява данни само за сесия, което означава, че данните се съхраняват до затваряне на браузъра (или раздела).
  • Данните никога не се прехвърлят към сървъра.
  • Ограничението за съхранение е по-голямо от бисквитка (най-много 5 MB).
• localStorage прави същото, но продължава дори когато браузърът е затворен и отворен отново.
  • Съхранява данни без дата на изтичане и се изчиства само чрез JavaScript или изчистване на кеша на браузъра / Локално съхранени данни.
  • Ограничението за съхранение е максималното измежду трите.

Спецификации

Съвместимост с браузър

Window.localStorage

https://github.com/mdn/browser-compat-data и ни изпратете заявка за изтегляне.

Легенда

Window.sessionStorage

Таблицата за съвместимост на тази страница е генерирана от структурирани данни. Ако искате да допринесете за данните, моля, разгледайте https://github.com/mdn/browser-compat-data и ни изпратете заявка за изтегляне.

Актуализирайте данните за съвместимост в GitHub

Легенда

Режими на частно сърфиране / инкогнито

Повечето съвременни браузъри поддържат опция за поверителност, наречена "Инкогнито", "Частно сърфиране" или нещо подобно, което не съхранява данни като история и бисквитки. Това е фундаментално несъвместимо с уеб съхранението по очевидни причини. Поради това доставчиците на браузъри експериментират с различни сценарии за това как да се справим с тази несъвместимост.

Повечето браузъри са избрали стратегия, при която API за съхранение все още са налични и привидно напълно функционални, с една голяма разлика, че всички съхранени данни се изтриват след затваряне на браузъра. За тези браузъри все още има различни интерпретации на това какво трябва да се направи със съществуващите съхранени данни (от обикновена сесия на сърфиране). Трябва ли да е достъпно за четене, когато е в личен режим? След това има някои браузъри, най-вече Safari, които са избрали решение, при което съхранението е налично, но е празно и има присвоена квота от 0 байта, което на практика прави невъзможно записването на данни в него.

Разработчиците трябва да са наясно с тези различни реализации и да ги вземат предвид, когато разработват уебсайтове в зависимост от API за уеб съхранение. За повече информация, моля, погледнете тази публикация в блога на WHATWG, която конкретно се занимава с тази тема.

Превод: Влад Мержевич

Постоянното локално съхранение е една област, в която клиентските приложения имат предимства пред сървърните приложения. За приложения като операционна система, предоставя абстракционен слой за съхраняване и извличане на данни като настройки или състояние на изпълнение. Тези стойности могат да се съхраняват в системния регистър, INI файлове, XML файлове или другаде, в зависимост от принципите на платформата. Ако вашето клиентско приложение се нуждае от локално хранилище за нещо повече от двойка ключ/стойност, можете да вмъкнете своя собствена база данни, да създадете свой собствен файлов формат или произволен брой други решения.

В исторически план уеб приложенията не са имали нито един от тези луксове. Бисквитките са изобретени в началото на историята на Интернет и могат да се използват за постоянно съхраняване на малки количества данни локално. Но те имат три потенциални недостатъка:

• бисквитките са включени във всяка HTTP заявка, като по този начин забавят вашето уеб приложение чрез ненужно изпращане на едни и същи данни отново и отново;
• бисквитките се включват във всяка HTTP заявка, когато данните се предават по интернет в некриптирана форма (дори ако цялото уеб приложение се предава по SSL);
• бисквитките са ограничени до около 4 KB данни - достатъчно, за да забавят вашето приложение (вижте по-горе), но не достатъчно, за да бъдат полезни.

Ето какво наистина искаме:

• много място за съхранение;
• работа от страна на клиента;
• помислете за опресняване на страницата;
• няма изпращане към сървъра.

Преди HTML5 всички опити да се постигне това завършваха с неуспех по различни начини.

Кратка история на локалното съхранение преди HTML5

В началото имаше само един Internet Explorer. Поне Microsoft искаше светът да мисли така. За тази цел, като част от Първата голяма война на браузърите, Microsoft изобрети много неща и ги включи в своя браузър, който сложи край на войната, Internet Explorer. Едно от тези неща се нарича DHTML Behaviors, а едно от поведенията се нарича userData.

UserData позволява на уеб страница да съхранява до 64 KB данни на домейн в йерархична структура, подобна на XML. Доверени домейни като интранет сайтове могат да съхраняват десет пъти повече. И хей, 640 kb трябва да са достатъчни за всички. IE не е предоставил никакъв начин за промяна на тези конвенции, така че няма начин да се увеличи наличната памет.

През 2002 г. Adobe представи функция във Flash 6, която беше неуспешна и подвеждащо наречена „Flash cookies“. AT Flash средатази възможност е по-правилно известна като локални споделени обекти (локално достъпни обекти, LSO). Накратко, позволява на Flash обекти да съхраняват до 100 KB данни на домейн. Брад Нойберг разработи ранен прототип на мост между Flash и JavaScript, наречен AMASS (AJAX Massive Storage System), но беше ограничен от някои странности на дизайна на Flash. До 2006 г., с появата на ExternalInterface във Flash 8, достъпът до LSO чрез JavaScript стана много по-лесен и по-бърз. Брад пренаписа AMASS и го интегрира в популярния Dojo Toolkit под псевдонима dojox.storage. Flash „безплатно“ дава на всеки домейн 100 kb място за съхранение. В допълнение, той подканва потребителя да увеличи обема на хранилището с порядък (1 MB, 10 MB и т.н.), когато бъде поискано.

ако (Modernizr.localstorage) (
// window.localStorage е наличен!
) иначе (
// няма вградена поддръжка за HTML5 съхранение
}

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

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

Интерфейс за съхранение (
Вземете чрез getItem(ключ);
Задаване чрез setItem(ключ, данни);
};

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

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

var foo = localStorage.getItem("лента");
// ...
localStorage.setItem("лента", foo);

може да се пренапише с помощта на синтаксиса на квадратни скоби:

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

Има и методи за изтриване на стойности по име на ключ, както и изчистване на целия магазин (т.е. изтриване на всички ключове и стойности наведнъж).

Интерфейс за съхранение (
Премахване чрез removeItem(ключ);
изчистване();
}

Извикването на removeItem() с ключ, който не съществува, няма да върне нищо.

И накрая, има свойство за получаване на общия брой стойности в областта за съхранение и за итериране на всички ключове по индекс (получава името на всеки ключ).

Интерфейс за съхранение (
дължина
Вземете ключ (неотрицателно цяло число);
}

Ако при извикването на key() индексът не е в диапазона от 0 до (length-1), тогава функцията ще върне null.

Проследяване на областта за съхранение на HTML5

Ако искате програмно да проследите промените в хранилището, трябва да уловите събитието за съхранение. Това събитие се предизвиква в обекта прозорец, когато setItem(), removeItem() или clear() се извикат и променят нещо. Например, ако зададете съществуваща стойностили извикайте clear(), когато няма ключове, тогава събитието няма да се активира, защото областта за съхранение всъщност не се е променила.

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

ако (window.addEventListener) (
window.addEventListener("storage", handle_storage, false);
) иначе (
window.attachEvent("onstorage", handle_storage);
};

Обратното извикване handle_storage ще бъде извикано с обект StorageEvent, освен в Internet Explorer, където събитията се съхраняват в window.event.

функция handle_storage(e) (
if (!e) (e = window.event;)
}

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

*Забележка: Свойството url първоначално се нарича uri и някои браузъри поддържаха това свойство преди промяната на спецификацията. За максимална съвместимост трябва да проверите дали съществува свойството url и ако не, вместо това проверете свойството uri.

Събитието за съхранение не може да бъде отменено, няма начин в обратното извикване handle_storage да спре промяната. Това е просто начинът на браузъра да ви каже: „Хей, това току-що се случи. Нищо не можеш да направиш, просто исках да знаеш."

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

Говорейки за историята на локалното съхранение с плъгини на трети страни, споменах ограниченията на всяка техника. Спомних си, че не бях казал нищо за ограниченията на вече стандартното HTML5 хранилище. Ще ви дам отговорите и след това ще ги обясня. Отговорите по важност са: „5 мегабайта“, „QUOTA_EXCEEDED_ERR“ и „нито един“.

"5 мегабайта" - колко място за съхранение е дадено по подразбиране. Тази стойност е изненадващо еднаква във всички браузъри, въпреки че не е формулирана като нищо повече от предложение в спецификацията на HTML5. Трябва да разберете, че съхранявате низове, а не данни в оригиналния им формат. Ако съхранявате много цели числа или числа с плаваща запетая, разликата в представянето може да бъде голяма. Всяка цифра в число с плаваща запетая се съхранява като знак, а не в обичайното представяне за такива числа.

„QUOTA_EXCEEDED_ERR“ е изключението, което получавате, ако надвишите квотата си от 5 MB. „Не“ е отговорът на следващия очевиден въпрос: „Мога ли да поискам от потребителя повече място за съхранение?“. Към момента на писане браузърите не прилагат никакъв механизъм за уеб разработчиците да изискват повече място за съхранение. Някои браузъри (като Opera) позволяват на потребителя да контролира квотите за съхранение за всеки сайт, но това е чисто потребителска инициатива и не е свързано с това, което вие като разработчик можете да вградите във вашето уеб приложение.

HTML5 съхранение в действие

Нека да разгледаме HTML5 съхранението в действие. Нека се върнем към този, който изградихме в главата за чертане. Има малък проблем с тази игра: ако затворите прозореца на браузъра по средата на играта, ще загубите резултатите. Но с HTML5 съхранение можем да запазим играта на място, в самия браузър. Отворете демонстрацията, направете няколко движения, затворете раздела на браузъра и след това го отворете отново. Ако вашият браузър поддържа HTML5 съхранение, демонстрационната страница магически ще запомни точната ви позиция в играта, включително колко хода сте направили, позицията на всяка фигура на дъската и дори избраната фигура.

Как работи? Всеки път, когато има промяна в играта, ние ще извикаме тази функция.

функция saveGameState() (

localStorage["halma.game.in.progress"] = gGameInProgress;
за (променлива 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;
връща вярно;
}

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

Когато страницата се зареди, вместо автоматично извикване на функцията newGame(), която ще върне всички променливи към първоначалните им стойности, ние извикваме resumeGame(). Функцията resumeGame() използва HTML5 магазина, за да провери състоянието на играта в локалния магазин. Ако присъства, той възстановява стойностите с помощта на обекта localStorage.

функция resumeGame() (
if (!supportsLocalStorage()) ( return false; )
gGameInProgress = (localStorage["halma.game.in.progress"] == "true");
if (!gGameInProgress) ( return false; )
gPieces = нов масив(kNumPieces);
за (променлива i = 0; i< kNumPieces; i++) {
var row = parseInt(localStorage["halma.piece." + i + ".row"]);
var column = parseInt(localStorage["halma.piece." + i + ".column"]);
gPieces[i] = нова клетка(ред, колона);
}
gNumPieces = kNumPieces;
gSelectedPieceIndex = parseInt(localStorage["halma.selectedpiece"]);
gSelectedPieceHasMoved = localStorage["halma.selectedpiecehasmoved"] == "true";
gMoveCount = parseInt(localStorage["halma.movecount"]);
drawBoard();
връща вярно;
}

Най-важната част от тази функция е предупреждението, което споменах по-рано в тази глава и ще повторя тук: данните се съхраняват като низове. Ако съхранявате нещо различно от низове, ще трябва да ги конвертирате, когато ги получите. Например, флагът за игра в ход (gGameInProgress) е булево. Във функцията saveGameState() ние просто го съхраняваме и не се притесняваме за типа на данните.

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

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

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

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

localStorage["halma.movecount"] = gMoveCount;

Но във функцията resumeGame() трябва да преобразуваме стойността в цяло число, използвайки вградената функция parseInt() на JavaScript.

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

Отвъд двойката ключ/стойност: конкурентна визия

Въпреки че в историята е имало много трикове и заобиколни решения, сегашното състояние на HTML5 хранилището е изненадващо безопасно. Новият API е стандартизиран и включен във всички основни браузъри, платформи и устройства. За уеб разработчик не виждате това всеки ден, нали? Но това е повече от "5 мегабайта двойки ключ/стойност" и бъдещето на постоянното локално съхранение е... как да кажа... добре, конкурентна визия.

One vision е акроним, който вече знаете - SQL. През 2007 г. Google стартира Gears, плъгин с отворен код за различни браузъри, който включва вградена база данни, базирана на SQLite. Този ранен прототип по-късно повлия на създаването на спецификацията на уеб SQL базата данни. Уеб SQL база данни (преди известна като "WebDB") осигурява тънка обвивка около базата данни SQL данни, което ви позволява да правите следните неща от JavaScript:

openDatabase("документи", "1.0", "Локално съхранение на документи", 5*1024*1024, функция (db) (
db.changeVersion("", "1.0", функция (t) (
t.executeSql("CREATE TABLE docids (id, name)");
), грешка);
});

Както можете да видите, повечето от действията са на линия с метода 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, което не се приема от стандарта.

Именно на този фон ще ви разкажа за друга конкурентна визия за усъвършенствано, постоянно локално съхранение за уеб приложения: API за индексирана база данни, по-рано известен като „WebSimpleDB“, сега нежно наричан IndexedDB.

API за индексирана база данни предоставя това, което се нарича хранилище на обекти, с много идеи, заимствани от SQL бази данни. Има "бази данни" със "записи", всеки запис има определен брой "полета". Всяко поле има специфичен тип данни, който се дефинира при създаването на базата данни. Можете да изберете част от записите, след което да ги изброите с "курсора". Промените в хранилището на обекти се обработват с "транзакции".

Ако някога сте програмирали SQL бази данни, тези термини вероятно са ви познати. Основната разлика е, че съхранението на обекти няма структуриран език за заявки. Не пишете условие като "SELECT * from USERS where ACTIVE = "Y"". Вместо това използваме методите, предоставени от хранилището на обекти, за да отворим базата данни USERS, да изброим записите, да филтрираме нашите записи и да използваме методи за достъп, за да получим стойността на всяко поле от останалите записи. Едно ранно разглеждане на IndexedDB е добро ръководство за това как работи IndexedDB и как IndexedDB се сравнява с Web SQL.

Към момента на писане IndexedDB е бил внедрен само в бета версия на Firefox 4. За разлика от тях Mozilla заяви, че никога няма да внедри Web SQL. Google заявиха, че обмислят поддръжка на IndexedDB за Chromium и Google Chrome. И дори Microsoft каза, че IndexedDB е „страхотно решение за мрежата“.

Какво можете да направите като уеб разработчик с IndexedDB? В момента почти нищо, с изключение на някои технологични демонстрации. След година? Може би.

Последна актуализация: 1.11.2015 г

Въпреки че бисквитките позволяват съхраняването на информация, те имат редица ограничения. Например, браузърът има ограничения за размера на бисквитките - всяка бисквитка не може да надвишава 4 kb. Бисквитките имат срок на валидност, след който се изтриват. Бисквитките са неразделна характеристика на HTTP протокола и се предават с всяка заявка към сървъра заедно със заявката към сървъра. Въпреки това, за да работите с бисквитки от страна на клиента в javascript код, предаването на бисквитки към сървъра няма значение. Освен това, за да извлечете съхранени бисквитки, трябва да напишете някакъв код.

Затова се въведе HTML5 нова концепцияза съхранение на данни - уеб хранилище. Уеб хранилището се състои от два компонента: съхранение на сесии и локално съхранение.

Съхранението на сесии е временно съхранение на информация, която се изтрива след затваряне на браузъра.

Локалното съхранение представлява постоянно съхранение на данни. Данните от локалното хранилище не се изтриват автоматично и не изтичат. Тези данни не се изпращат до сървъра в HTTP заявка. Освен това обемът на локалното хранилище в Chrome и Firefox е 5 Mb за домейн, а в IE - 10 Mb.

Всички данни в уеб хранилището са набор от двойки ключ-стойност. Тоест всеки обект има уникално име на ключ и специфична стойност.

За работа с локално хранилище в javascript се използва обектът localStorage, а за работа с хранилище на сесии се използва обектът sessionStorage.

За да запазите данни, предайте ги на метода setItem() на обекта localStorage:

LocalStorage.setItem("вход", " [имейл защитен]");

Към този метод се предават две стойности: ключът и стойността на обекта, който трябва да бъде запазен.

Ако localStorage вече има обект с ключ "login", тогава неговата стойност се заменя с нова.

За да получите запазените данни, трябва да извикате метода getItem():

var login = localStorage.getItem("вход"); // [имейл защитен]

Ключът на обекта се предава на този метод.

За да премахнете обект, използвайте метода removeItem(), който взема ключа на обекта, който трябва да бъде премахнат:

LocalStorage.removeItem("вход");

И за пълно премахванеот всички обекти от localStorage, можете да използвате метода clear():

LocalStorage.clear();

Запазването на прости обекти е лесно, но имайте предвид, че данните в localStorage се съхраняват като низ:

LocalStorage.setItem("възраст", 23); var age = localStorage.getItem("age"); възраст=parseInt(възраст)+10; document.write(възраст); //33

Ако в този случай стойността не се преобразува в число с помощта на parseInt(), тогава възрастта ще действа като низ.

Могат да възникнат трудности при запазването на сложни обекти:

Var user =( име: "Том", възраст: 23, женен: невярно); localStorage.setItem("потребител", потребител); var savedUser = localStorage.getItem("потребител"); document.write(savedUser); // document.write(savedUser.name); // undefined - savedUser е низ, а не обект

В този случай трябва да използваме JSON сериализация:

Var user =( име: "Том", възраст: 23, женен: невярно); localStorage.setItem("потребител", JSON.stringify(потребител)); var savedUser = JSON.parse(localStorage.getItem("user")); document.write(savedUser.name + " " + savedUser.age +" " + savedUser.married); // Том 23 невярно