Lokal lagring av cookies. Lokalt utrymme. Grundläggande CRUD-operationer med lokal lagring

Webböversikt Lagring

På Internet kan information lagras på två ställen: på webbservern och på webbklienten (d.v.s. sidans besökares dator). Vissa typer av data lagras bäst på en av dessa platser och andra typer på en annan.

Rätt plats att lagra känslig och viktig data på skulle vara en webbserver. Till exempel, om du lägger till varor i din varukorg i en webbutik, lagras dina potentiella köpdetaljer på en webbserver. Endast ett fåtal byte spårningsdata lagras på din dator, som innehåller information om dig (eller snarare din dator), så att webbservern vet vilken papperskorg som är din. Även med de nya funktionerna i HTML5 finns det inget behov av att ändra detta system - det är pålitligt, säkert och effektivt.

Men att lagra data på servern är inte alltid den bästa metoden, eftersom ibland är det lättare att lagra icke väsentlig information på användarens dator. Till exempel är det vettigt att lagra användarinställningar lokalt (till exempel inställningar som bestämmer hur en webbsida visas) och applikationstillstånd (ögonblicksbild nuvarande tillstånd webbapplikation) så att besökaren kan fortsätta sin körning från samma plats senare.

Före HTML5 var det enda sättet att lagra data lokalt att använda filmekanismen. småkakor, som ursprungligen utformades för att utbyta små mängder identifierande information mellan webbservrar och webbläsare. Cookies är idealiska för att lagra små mängder data, men JavaScript-modellen för att arbeta med dem är lite klumpig. Cookiesystemet tvingar också utvecklaren att fiffla med utgångsdatum och värdelöst skicka data fram och tillbaka över internet med varje sidförfrågan.

HTML5 introducerar ett bättre alternativ till cookies, vilket gör det enkelt och enkelt att lagra information på en besökares dator. Denna information kan lagras på klientdator på obestämd tid, skickas inte till en webbserver (såvida inte utvecklaren gör det själv), kan vara stora och kräver bara ett par enkla, effektiva JavaScript-objekt att arbeta med.

Denna möjlighet kallas webblagring (webblagring) och är särskilt lämplig att använda med offlineläge arbetet med webbplatser, eftersom låter dig skapa fristående applikationer som kan spara all information de behöver även när det inte finns någon internetanslutning.

HTML5 webblagringsfunktioner gör att en webbsida kan lagra data på besökarens dator. Denna information kan vara kortsiktig, som raderas när webbläsaren stängs av, eller långvarig, som förblir tillgänglig vid efterföljande besök på webbsidan.

Informationen som lagras i webblagring lagras faktiskt inte på Internet, utan på datorn för besökaren på webbsidan. Webblagring innebär med andra ord att data inte lagras på Internet, utan att data från Internet lagras.

Det finns två typer av webblagring som är relaterade till två objekt på ett eller annat sätt:

Använder objekt lokalt utrymme att lagra data för hela webbplatsen på permanent basis. Detta innebär att om en webbsida sparar data till lokal lagring, kommer denna data att vara tillgänglig för användaren när de återvänder till den webbsidan nästa dag, nästa vecka eller nästa år.

Naturligtvis ger de flesta webbläsare också användaren möjlighet att rensa lokal lagring. Den är implementerad som en allt-eller-inget-strategi i vissa webbläsare, och den tar bort all lokal data, ungefär som att cookies tas bort. (Faktum är att i vissa webbläsare är cookiessystemet och den lokala lagringen sammankopplade, så det enda sättet att radera lokal data är att radera cookies.) Och andra webbläsare kan ge användaren möjligheten att se data för varje enskild webbplats och radera data för den eller de valda webbplatserna.

Använder objekt sessionStorage för att tillfälligt lagra data för ett enda webbläsarfönster eller en enda flik. Dessa data är endast tillgängliga tills användaren stänger fönstret eller fliken, då sessionen avslutas och data raderas. Men sessionsdata bevaras om användaren navigerar till en annan webbplats och sedan återvänder, så länge det sker i samma webbläsarfönster.

Ur webbsideskodens synvinkel fungerar både lokal lagring och sessionsdatalagring på exakt samma sätt. Skillnaden är bara i varaktigheten av datalagring.

Användningen av lokal lagring ger den bästa möjligheten att lagra den information som krävs för efterföljande besök på webbsidan av användaren. Och sessionslagret används för att lagra data som behöver överföras från en sida till en annan. (Sessionslagring kan också lagra temporär data som endast används på en sida, men normala JavaScript-variabler fungerar utmärkt för detta ändamål.)

Både lokal lagring och sessionslagring är associerad med en webbplats domän. Således, om du sparar data för sidan www..html i lokal lagring, kommer dessa data att vara tillgängliga för sidan www..html, eftersom båda dessa sidor har samma domän. Men denna information kommer inte att vara tillgänglig för sidor på andra domäner.

Dessutom sedan webblagring finns på en dator (eller mobilenhet) denna användare, den är kopplad till den här datorn och webbsidan öppnas på den här datorn och lagrar data i sin lokala lagring, har inte tillgång till information som den har lagrat på en annan dator. På samma sätt skapar en webbsida separat lokal lagring om du loggar in med ett annat användarnamn eller startar en annan webbläsare.

Även om HTML5-specifikationen inte anger några hårda och snabba regler för den maximala mängden lagringsutrymme, begränsar de flesta webbläsare det till 5 MB. Mycket data kan packas in i denna mängd, men det räcker inte om du vill använda lokal lagring för prestandaoptimering och cachelagra stora bilder eller videor i den (och, för att säga sanningen, lokal lagring är inte avsedd för sådana syften).

För lagring av stora mängder data, en databasstandard som fortfarande utvecklas IndexeradDB möjliggör mycket större lokal lagring - vanligtvis 50 MB till att börja med, och mer om användaren samtycker.

Sparar data

Innan en information kan placeras i lokal eller sessionslagring måste den ges ett beskrivande namn. Detta namn kallas nyckel (nyckel) och behövs för att data ska kunna hämtas i framtiden.

Syntaxen för att spara en bit data är följande:

localStorage = data;

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

Naturligtvis är det inte meningsfullt att spara en statisk text. Som regel behöver vi lagra någon form av variabel data, såsom aktuellt datum, resultatet av en matematisk beräkning eller textdata som användaren anger i formulärfält. Följande är ett exempel på hur du sparar användarinmatad textdata:

Funktion saveData() ( // Hämta textfältsvärdena var localData = document.getElementById("localData"). värde; var sessionData = document. getElementById("sessionData"). värde; // Spara texten som anges i textfält till lokal lagring localStorage["localData"] = localData; // Lagra texten som anges i textfältet i sessionslagring sessionStorage["sessionData"] = sessionData; ) funktion loadData() ( // Ladda lagrad data från lagringarna var localData = localStorage ["localData"]; var sessionData = sessionStorage["sessionData"]; // Visa denna data i textfält if (localData != null) ( document.getElementById("localData").value = localData ; ) if (sessionData ! = null) ( document.getElementById("sessionData").value = sessionData; ) )

Sidan innehåller två textfält: ett för lokal lagring (överst) och ett för sessionslagring (nederst). Genom att klicka på knappen "Spara" sparas texten som skrivits in i textfälten, och genom att klicka på knappen "Ladda" visas motsvarande sparade data i fälten.

Web Storage stöder också den mindre vanliga egendomssyntaxen. Enligt reglerna för denna syntax hänvisar vi till lagringsplatsen med namnet användarnamn som localStorage.username, inte localStorage["användarnamn"]. Båda typerna av syntax är likvärdiga, och att använda den ena eller den andra är en fråga om personlig preferens.

Webblagring fungerar inte utan en webbserver

I din webblagringsundersökning kan du stöta på ett oväntat problem. I många webbläsare fungerar webblagring endast för sidor som tillhandahålls av webbservern. Det spelar ingen roll var servern finns, på internet eller på din egen dator, det viktigaste är att sidorna inte startas från den lokala hårddisk(till exempel genom att dubbelklicka på sidans filikon).

Den här funktionen är en bieffekt av hur webbläsare allokerar utrymme till lokal lagring. Som tidigare diskuterats begränsar webbläsare lokal lagring per webbplats till 5MB, vilket kräver att de associerar varje sida som vill använda lokal lagring med webbplatsens domän.

Så vad händer om du öppnar en sida som använder webblagring från din lokala hårddisk? Allt beror på webbläsaren. webbläsare Utforskaren verkar helt tappa stöd för webblagring. LocalStorage- och sessionStorage-objekten försvinner och försök att använda dem orsakar ett JavaScript-fel.

PÅ Firefox webbläsare localStorage- och sessionStorage-objekten förblir på plats och verkar ha stöd (även Modernizr bestämmer vad som stöds), men allt som skickas till lagring försvinner till ingen vet var. PÅ Chrome webbläsare igen, något annat - det mesta av webblagringsfunktionaliteten fungerar som den ska, men vissa funktioner (som onStorage-händelsen) fungerar inte.

Liknande problem uppstår med användningen av File API. Därför kommer du att spara dig en hel del besvär om du lägger sidan du testar på en testserver för att undvika alla dessa osäkerheter.

Webblagringsstöd av webbläsare

Webblagring är en av de mest stödda funktionerna i HTML5, med en bra nivå av stöd i alla större webbläsare. Tabellen nedan listar minimiversionerna av de stora webbläsarna som stöder webblagring:

Alla dessa webbläsare tillhandahåller lokal lagring och sessionsdatalagring. Stöd för onStorage-händelsen kräver dock senare webbläsare som IE 9, Firefox 4 eller Chrome 6.

Den mest problematiska versionen är IE 7, som inte stöder webblagring alls. Som en lösning kan du emulera webblagring med hjälp av cookies. Det är inte precis en perfekt lösning, men det fungerar. Även om det inte finns något officiellt skript för att täppa till detta gap, kan några bra utgångspunkter hittas på HTML5 Cross Browser-sidan (under "Webblagring").

De Web Storage API tillhandahåller mekanismer genom vilka webbläsare kan lagra nyckel/värdepar, på ett mycket mer intuitivt sätt än att använda cookies.

Web Storage koncept och användning

De två mekanismerna inom webblagring är följande:

• sessionStorage upprätthåller ett separat lagringsområde för varje givet ursprung som är tillgängligt under sidsessionens varaktighet (så länge webbläsaren är öppen, inklusive sidåterladdningar och -återställningar)
  • Lagrar data endast för en session, vilket innebär att data lagras tills webbläsaren (eller fliken) stängs.
  • Data överförs aldrig till servern.
  • Lagringsgränsen är större än en cookie (högst 5 MB).
• localStorage gör samma sak, men kvarstår även när webbläsaren stängs och öppnas igen.
  • Lagrar data utan utgångsdatum och rensas endast genom JavaScript, eller genom att rensa webbläsarens cache/lokalt lagrade data.
  • Lagringsgränsen är den högsta av de tre.

Specifikationer

Webbläsarkompatibilitet

Window.localStorage

https://github.com/mdn/browser-compat-data och skicka oss en pull-förfrågan.

Legend

Window.sessionStorage

Kompatibilitetstabellen på den här sidan genereras från strukturerad data. Om du vill bidra till datan, kolla in https://github.com/mdn/browser-compat-data och skicka oss en pull-förfrågan.

Uppdatera kompatibilitetsdata på GitHub

Legend

Privat surfning/inkognitolägen

De flesta moderna webbläsare stöder ett sekretessalternativ som kallas "Inkognito", "Privat surfning" eller något liknande som inte lagrar data som historik och cookies. Detta är i grunden inkompatibelt med Web Storage av uppenbara skäl. Som sådan experimenterar webbläsarleverantörer med olika scenarier för hur man hanterar denna inkompatibilitet.

De flesta webbläsare har valt en strategi där lagrings-API:er fortfarande är tillgängliga och till synes fullt fungerande, med den stora skillnaden att all lagrad data raderas efter att webbläsaren stängs. För dessa webbläsare finns det fortfarande olika tolkningar av vad som ska göras med befintlig lagrad data (från en vanlig surfsession). Ska den vara tillgänglig att läsa i privat läge? Sedan finns det några webbläsare, framför allt Safari, som har valt en lösning där lagring är tillgänglig, men är tom och har en kvot på 0 byte tilldelad, vilket i praktiken gör det omöjligt att skriva data till den.

Utvecklare bör vara medvetna om dessa olika implementeringar och ta hänsyn till dem när de utvecklar webbplatser beroende på Web Storage API:er. För mer information, ta en titt på detta WHATWG-blogginlägg som specifikt handlar om detta ämne.

Översättning: Vlad Merzhevich

Beständig lokal lagring är ett område där klientapplikationer har fördelar jämfört med serverapplikationer. För applikationer som operativ system, tillhandahåller ett abstraktionslager för att lagra och hämta data som inställningar eller exekveringsstatus. Dessa värden kan lagras i registret, INI-filer, XML-filer eller någon annanstans, beroende på plattformsprinciper. Om din klientapplikation behöver lokal lagring för mer än bara ett nyckel/värdepar, kan du infoga din egen databas, komma på ditt eget filformat eller valfritt antal andra lösningar.

Historiskt sett har webbapplikationer inte haft någon av dessa lyx. Cookies uppfanns tidigt i Internets historia och de kan användas för att permanent lagra små mängder data lokalt. Men de har tre potentiella nackdelar:

• cookies ingår i varje HTTP-begäran, vilket saktar ner din webbapplikation genom att i onödan skicka samma data om och om igen;
• cookies ingår i varje HTTP-förfrågan när data överförs över Internet i okrypterad form (även om hela webbapplikationen överförs över SSL);
• cookies är begränsade till cirka 4 KB data - tillräckligt för att sakta ner din applikation (se ovan), men inte tillräckligt för att vara användbar.

Här är vad vi verkligen vill:

• gott om lagringsutrymme;
• arbeta på kundsidan;
• överväg att uppdatera sidan;
• ingen sändning till server.

Före HTML5 misslyckades alla försök att uppnå detta på olika sätt.

En kort historia av lokal lagring före HTML5

I början fanns det bara en Internet Explorer. Microsoft ville åtminstone att världen skulle tycka så. För det ändamålet, som en del av det första stora webbläsarkriget, uppfann Microsoft många saker och inkluderade dem i sin webbläsare-som-slutade-kriget, Internet Explorer. En av dessa saker har kallats DHTML Behaviours och ett av beteendena kallas userData .

UserData tillåter en webbsida att lagra upp till 64 KB data per domän i en hierarkisk XML-liknande struktur. Pålitliga domäner som intranätsajter kan lagra tio gånger mer. Och hey, 640kb borde räcka för alla. IE har inte tillhandahållit något sätt att ändra dessa konventioner, så det finns inget sätt att öka det tillgängliga minnet.

2002 introducerade Adobe en funktion i Flash 6 som misslyckades och som missvisande fick namnet "Flash cookies". PÅ Flash miljö denna funktion är mer korrekt känd som Local Shared Objects (lokala tillgängliga objekt, LSOs). Kort sagt tillåter det Flash-objekt att lagra upp till 100 KB data per domän. Brad Neuberg utvecklade en tidig prototyp av en bro mellan Flash och JavaScript kallade den AMASS (AJAX Massive Storage System), men den begränsades av några Flash-designegenheter. År 2006, med tillkomsten av ExternalInterface i Flash 8, hade åtkomst till LSO via JavaScript blivit enklare och snabbare. Brad skrev om AMASS och integrerade den i den populära Dojo Toolkit under aliaset dojox.storage. Flash "gratis" ger varje domän 100 kb lagringsutrymme. Dessutom uppmanas användaren att öka mängden lagringsutrymme med en storleksordning (1 MB, 10 MB, etc.) när så begärs.

if (Modernizr.localstorage) (
// window.localStorage är tillgängligt!
) annat (
// inget inbyggt stöd för HTML5-lagring
}

Använder HTML5-lagring

HTML5-lagring baseras på namnen på nyckel/värdepar. Du lagrar information baserat på ett nyckelnamn och sedan kan du hämta den datan med samma nyckel. Nyckelnamnet är en sträng. Data kan vara vilken typ som helst som JavaScript stöder, inklusive strängar, booleaner, heltal eller flyttal. Däremot lagras data faktiskt som en sträng. Om du lagrar och hämtar icke-strängar, måste du använda funktioner som parseInt() eller parseFloat() för att översätta mottagna data till rätt JavaScript-typer.

Lagringsgränssnitt (
Få via getItem(key);
Ställ in via setItem(nyckel, data);
};

Att anropa setItem() med ett befintligt nyckelnamn kommer tyst att skriva över det föregående värdet. Att anropa getItem() med en icke-existerande nyckel kommer att returnera NULL istället för att skapa ett undantag.

Precis som andra JavaScript-objekt kan du komma åt localStorage-objektet som en associativ array. Istället för att använda metoderna getItem() och setItem() kan du bara använda hakparenteser. Till exempel denna kodbit

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

kan skrivas om med hakparentessyntax:

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

Det finns också metoder för att radera värden efter nyckelnamn, samt att rensa hela butiken (det vill säga radera alla nycklar och värden på en gång).

Lagringsgränssnitt (
Ta bort via removeItem(key);
klar();
}

Att anropa removeItem() med en nyckel som inte finns returnerar ingenting.

Slutligen finns det en egenskap för att få det totala antalet värden i lagringsområdet och att iterera över alla nycklar efter index (får namnet på varje nyckel).

Lagringsgränssnitt (
längd
Hämta nyckel (icke-negativt heltal);
}

Om, när key() anropas, indexet inte är i intervallet från 0 till (längd-1), kommer funktionen att returnera null .

Spårar HTML5-lagringsområdet

Om du vill spåra lagringsändringar programmatiskt måste du fånga lagringshändelsen. Denna händelse uppstår på fönsterobjektet när setItem() , removeItem() , eller clear() anropas och ändrar något. Till exempel om du ställer in befintligt värde eller ring clear() när det inte finns några nycklar, kommer händelsen inte att starta eftersom lagringsområdet inte har ändrats.

Lagringshändelsen stöds överallt där localStorage-objektet körs, inklusive Internet Explorer 8. IE 8 stöder inte W3C addEventListener-standarden (även om den äntligen kommer att läggas till i IE 9), så för att fånga lagringshändelsen måste du kontrollera vilken händelsemotor den stöder webbläsare (om du har gjort detta tidigare med andra evenemang kan du hoppa över det här avsnittet till slutet). Att fånga lagringshändelsen fungerar på samma sätt som att fånga andra händelser. Om du föredrar att använda jQuery eller något annat JavaScript-bibliotek för att registrera händelsehanterare, kan du också göra det med lagring.

if (window.addEventListener) (
window.addEventListener("lagring", handle_storage, false);
) annat (
window.attachEvent("onstorage", handle_storage);
};

Handle_storage-återuppringningen kommer att anropas med ett StorageEvent-objekt, förutom i Internet Explorer, där händelser lagras i window.event .

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

I det här fallet kommer variabeln e att vara ett StorageEvent-objekt, som har följande användbara egenskaper.

*Obs: URL-egenskapen hette ursprungligen uri och vissa webbläsare stödde den här egenskapen innan specifikationsändringen. För maximal kompatibilitet bör du kontrollera om url-egenskapen finns, och om inte, kontrollera uri-egenskapen istället.

Lagringshändelsen kan inte avbrytas, det finns inget sätt inuti handle_storage-återuppringningen att stoppa ändringen. Det är bara webbläsarens sätt att säga till dig, "Hej, det hände precis. Det finns inget du kan göra, jag ville bara att du skulle veta."

Begränsningar i nuvarande webbläsare

På tal om historien om lokal lagring med plugins från tredje part, nämnde jag begränsningarna för varje teknik. Jag kom ihåg att jag inte hade sagt något om begränsningarna för den nu standardiserade HTML5-lagringen. Jag ska ge dig svaren och sedan förklara dem. Svaren, i viktordning, är: "5 megabyte", "QUOTA_EXCEEDED_ERR" och "ingen".

"5 megabyte" - hur mycket lagringsutrymme som ges som standard. Detta värde är förvånansvärt detsamma i alla webbläsare, även om det inte är formulerat som något annat än ett förslag i HTML5-specifikationen. Du måste förstå att du lagrar strängar, inte data i sitt ursprungliga format. Om du lagrar många heltal eller flyttal kan skillnaden i representation vara stor. Varje siffra i ett flyttalsnummer lagras som ett tecken, inte i den vanliga representationen för sådana tal.

"QUOTA_EXCEEDED_ERR" är undantaget du får om du överskrider din 5MB-kvot. "Nej" är svaret på nästa självklara fråga: "Kan jag be användaren om mer lagringsutrymme?". I skrivande stund implementerar webbläsare inte någon mekanism för webbutvecklare att begära mer lagringsutrymme. Vissa webbläsare (som Opera) låter användaren kontrollera lagringskvoter per plats, men detta är rent användarinitiativ och inte relaterat till vad du som utvecklare kan bygga in i din webbapplikation.

HTML5-lagring i aktion

Låt oss ta en titt på HTML5-lagring i aktion. Låt oss gå tillbaka till den vi byggde i ritkapitlet. Det finns ett litet problem med det här spelet: om du stänger webbläsarfönstret mitt i spelet kommer du att förlora resultaten. Men med HTML5-lagring kan vi spara spelet på plats, i själva webbläsaren. Öppna demon, gör några drag, stäng webbläsarfliken och öppna den sedan igen. Om din webbläsare stöder HTML5-lagring kommer demosidan magiskt ihåg din exakta position i spelet, inklusive hur många drag du gjorde, positionen för varje pjäs på brädet och till och med den valda pjäsen.

Hur det fungerar? Varje gång det sker en förändring i spelet kommer vi att anropa denna funktion.

funktion saveGameState() (

localStorage["halma.game.in.progress"] = gGameInProgress;
för (var i = 0; i< kNumPieces; i++) {
localStorage["halma.piece." + i + ".row"] = gPieces[i].rad;
localStorage["halma.piece." + i + ".column"] = gPieces[i].column;
}
localStorage["halma.selectedpiece"] = gSelectedPieceIndex;
localStorage["halma.selectedpiecehasmoved"] = gSelectedPieceHasMoved;
localStorage["halma.movecount"] = gMoveCount;
returnera sant;
}

Som du kan se används localStorage-objektet för att spara spelförloppet (gGameInProgress , boolean). Därefter itererar du över alla marker (gPieces, en JavaScript-array) och lagrar en rad och kolumn för var och en. Efter det sparas ytterligare några speltillstånd, inklusive den för närvarande valda biten (gSelectedPieceIndex , ett heltal), den bit som är mitt i en lång serie av hopp (gSelectedPieceHasMoved , boolean) och Totala numret drag gjorda (gMoveCount , heltal).

När sidan laddas, istället för att automatiskt anropa newGame()-funktionen, som skulle returnera alla variabler till sina ursprungliga värden, anropar vi resumeGame() . Funktionen resumeGame() använder HTML5-butiken för att kontrollera tillståndet för spelet i den lokala butiken. Om det finns återställer det värdena med hjälp av localStorage-objektet.

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

Den viktigaste delen av denna funktion är varningen jag nämnde tidigare i det här kapitlet och kommer att upprepas här: data lagras som strängar. Om du lagrar något annat än strängar måste du konvertera dem när du får dem. Till exempel är flaggan för pågående spel (gGameInProgress ) en boolesk. I saveGameState()-funktionen lagrar vi det bara och oroar oss inte för datatypen.

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

Men i funktionen resumeGame() måste vi betrakta värdet som hämtas från lokal lagring som en sträng och manuellt konstruera vårt eget booleska värde.

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

På samma sätt lagras antalet drag i gMoveCount som ett heltal, i funktionen saveGameState() sparar vi det helt enkelt.

localStorage["halma.movecount"] = gMoveCount;

Men i resumeGame()-funktionen måste vi konvertera värdet till ett heltal med hjälp av JavaScripts inbyggda parseInt()-funktion.

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

Beyond Key/Värdepar: Konkurrenskraftig vision

Även om det har funnits många knep och lösningar i historien, är det nuvarande tillståndet för HTML5-lagring förvånansvärt säkert. Det nya API:et har standardiserats och ingår i alla större webbläsare, plattformar och enheter. För en webbutvecklare ser man det inte varje dag, eller hur? Men det är mer än "5 megabyte nyckel-/värdepar" och framtiden för beständig lokal lagring är... hur ska man säga... ja, en konkurrenskraftig vision.

En vision är en akronym du redan känner till - SQL. 2007 lanserade Google Gears, ett plugin för flera webbläsare med öppen källkod som inkluderar en inbäddad SQLite-baserad databas. Denna tidiga prototyp påverkade senare skapandet av Web SQL Database-specifikationen. Web SQL Database (tidigare känd som "WebDB") ger ett tunt omslag runt databasen SQL-data, som låter dig göra följande saker från JavaScript:

openDatabase("dokument", "1.0", "Lokal dokumentlagring", 5*1024*1024, funktion (db) (
db.changeVersion("", "1.0", funktion (t) (
t.executeSql("CREATE TABLE docids (id, name)");
), fel);
});

Som du kan se är de flesta av åtgärderna i linje med ExecuteSQL-metoden. Den här strängen kan stödja alla SQL-kommandon, inklusive SELECT, UPDATE, INSERT och DELETE. Det är så serverprogrammering databaser, förutom att du gör det med JavaScript! O glädje!

Web SQL-databasspecifikationen har implementerats i fyra webbläsare och plattformar.

Naturligtvis, om du har använt mer än en databas i ditt liv, då vet du att "SQL" är mer av en marknadsföringsterm än en hård och snabb standard (man kan säga detsamma om HTML5, men det är inte viktigt). Naturligtvis finns det en faktisk SQL-specifikation (den kallas SQL-92), men det finns ingen databasserver i världen som bara överensstämmer med denna specifikation. Det finns Oracle SQL, Microsoft SQL, SQL i MySQL, SQL i PostgreSQL, SQL i SQLite. Faktum är att var och en av dessa produkter lägger till nya SQL-funktioner med tiden, så det räcker inte att bara säga "SQL i SQLite". Du bör säga "versionen av SQL som kommer med SQLite version X.Y.Z".

Allt detta för oss till nästa varning, som för närvarande är placerad överst i Web SQL-specifikationen.

Specifikationen har nått en återvändsgränd: alla intresserade utvecklare använder SQL (SQLite) på serversidan, men vi behöver flera oberoende implementeringar för att gå längs standardiseringsvägen. Medan andra utvecklare är intresserade av att implementera denna specifikation, har beskrivningen av SQL-dialekten lämnats som en ren referens till Sqlite, vilket inte accepteras av standarden.

Det är mot denna bakgrund som jag kommer att berätta om en annan konkurrenskraftig vision för avancerad, beständig lokal lagring för webbapplikationer: Indexed Database API, tidigare känt som "WebSimpleDB", som nu kärleksfullt kallas IndexedDB.

Indexed Database API tillhandahåller vad som kallas ett objektlager, med många idéer lånade från SQL-databaser. Det finns "databaser" med "poster", varje post har ett visst antal "fält". Varje fält har en specifik datatyp, som definieras när databasen skapas. Du kan välja en del av posterna och sedan lista dem med "markören". Ändringar av objektlagret behandlas med "transaktioner".

Om du någonsin har programmerat SQL-databaser är dessa termer förmodligen bekanta för dig. Den största skillnaden är att objektlagring inte har ett strukturerat frågespråk. Du skriver inte ett villkor som "SELECT * from USERS där ACTIVE = "Y"". Istället använder vi metoderna som tillhandahålls av objektarkivet för att öppna USERS-databasen, räkna upp posterna, filtrera våra poster och använda accessormetoder för att få värdet av varje fält av de återstående posterna. En tidig genomgång av IndexedDB är en bra guide om hur IndexedDB fungerar och hur IndexedDB kan jämföras med Web SQL.

I skrivande stund har IndexedDB endast implementerats i betaversionen av Firefox 4. Däremot har Mozilla uppgett att de aldrig kommer att implementera Web SQL. Google har uppgett att de överväger IndexedDB-stöd för Chromium och Google Chrome. Och även Microsoft har sagt att IndexedDB är "en fantastisk lösning för webben."

Vad kan du som webbutvecklare göra med IndexedDB? För tillfället nästan ingenting, förutom några tekniska demonstrationer. Om ett år? Kanske.

Senaste uppdatering: 1.11.2015

Även om cookies tillåter att information lagras har de ett antal begränsningar. Till exempel har webbläsaren begränsningar för storleken på cookies – varje cookie får inte överstiga 4 kb. Cookies har ett utgångsdatum efter vilket de raderas. Cookies är en integrerad del av HTTP-protokollet och överförs med varje begäran till servern tillsammans med begäran till servern. Men för att arbeta med cookies på klientsidan i javascript-kod spelar det ingen roll att skicka cookies till servern. Dessutom, för att hämta lagrade cookies, behöver du skriva lite kod.

Därför introducerade HTML5 nytt koncept för datalagring - webblagring. Webblagring består av två komponenter: sessionslagring och lokal lagring.

Sessionslagring är en tillfällig lagring av information som raderas efter att webbläsaren stängs.

Lokal lagring representerar lagring av data på löpande basis. Data från lokal lagring raderas inte automatiskt och upphör inte att gälla. Denna data skickas inte till servern i en HTTP-förfrågan. Dessutom är mängden lokal lagring i Chrome och Firefox 5 Mb för en domän och i IE - 10 Mb.

All data i webblagring är en uppsättning nyckel-värdepar. Det vill säga att varje objekt har ett unikt nyckelnamn och ett specifikt värde.

För att arbeta med lokal lagring i javascript används localStorage-objektet och för att arbeta med sessionslagring används sessionStorage-objektet.

För att spara data, skicka den till setItem()-metoden för localStorage-objektet:

LocalStorage.setItem("login", " [e-postskyddad]");

Två värden skickas till denna metod: nyckeln och värdet på objektet som ska sparas.

Om localStorage redan har ett objekt med "login"-nyckeln ersätts dess värde med ett nytt.

För att få sparad data måste du anropa getItem()-metoden:

var login = localStorage.getItem("login"); // [e-postskyddad]

Nyckeln till objektet skickas till denna metod.

För att ta bort ett objekt, använd metoden removeItem(), som tar nyckeln till objektet som ska tas bort:

LocalStorage.removeItem("login");

Och för fullständigt avlägsnande av alla objekt från localStorage kan du använda metoden clear():

LocalStorage.clear();

Att spara enkla objekt är enkelt, men tänk på att data i localStorage lagras som en sträng:

LocalStorage.setItem("ålder", 23); var age = localStorage.getItem("ålder"); age=parseInt(ålder)+10; document.write(ålder); //33

Om, i det här fallet, värdet inte konverteras till ett tal med parseInt() , kommer ålder att fungera som en sträng.

Det kan uppstå svårigheter med att spara komplexa objekt:

Var användare =( namn: "Tom", ålder: 23, gift: falskt ); localStorage.setItem("användare", användare); var savedUser = localStorage.getItem("användare"); document.write(sparadAnvändare); // document.write(sparad Användarnamn); // undefined - savedUser är en sträng, inte ett objekt

I det här fallet måste vi använda JSON-serialisering:

Var användare =( namn: "Tom", ålder: 23, gift: falskt ); localStorage.setItem("användare", JSON.stringify(användare)); var savedUser = JSON.parse(localStorage.getItem("användare")); document.write(savedUser.name + " " + savedUser.age +" " + savedUser.married); // Tom 23 falskt