Share
I årevis har en av hovedfordelene ved å skrive skrivebordsprogrammer vært enkel tilgang til lokal lagring på klientmaskinen. Webutviklere har satt opp med manglende evne til å lagre og hente data fra klientens maskin lenge, men det ser ut til at det kan endres snart. Du kan kanskje tro at det allerede har etter å ha lest denne artikkelen. Ja, jeg skal diskutere opprinnelsen til vedvarende data på klientmaskinen og deretter introdusere deg til Web Storage-standarden.
De fleste webutviklere vet at den eneste typen lokal lagring vi kan forvente fra en nettleser, kommer i form av informasjonskapsler. Vel, ikke helt. Ønsket om å lagre data på klientmaskinen er ikke et nytt konsept, og det ble ikke oppfattet under oppretting av HTML5-spesifikasjoner. Det som er enda mer overraskende er at en arbeidsmessig implementering ble utviklet av Microsoft som en del av IE6-funksjonssettet. De kalte det brukerdata og det garanterte i det vesentlige minst 640 kB lokal plass per domenavhengig av IE-sikkerhetspolitikken satt av brukeren. Det kan virke som svært lite plass etter dagens standard, men når vi sammenligner det med maksimum 4KB plass tilgjengelig for oss av Cookies, er forbedringen merkbar.
En rekke ting. Det største problemet med Cookies er at de sendes frem og tilbake mellom nettleseren og serveren med hver HTTP-forespørsel. Dette er ikke en ønskelig oppførsel fordi oftere enn ikke utviklere ønsker ikke å overføre lokale data til serveren mer enn én gang, om en gang i det hele tatt. Cookies gir utvikler ikke noe valg.
Som vi tidligere sa, kan cookies bare lagre opptil 4 KB data. Det er ikke mye data, likevel 4KB er nok data til å sakte sakte sideforespørsler.
Dessuten sendes cookies frem og tilbake mellom klienten og serveren i klar tekst. Derfor er den eneste måten å beskytte dem på ved å kryptere dataene mens de kommuniserer med backend-serveren ved hjelp av SSL (Secure Socket Layer). Imidlertid bruker de fleste nettsteder på Internett ikke SSL, noe som gjør at lagringsplassen er åpen for avlytting.
Det er andre problemer som gjør Cookies mindre nyttige. Ideelt sett ønsker utviklere å ha muligheten til å fortsette store mengder data på klientmaskinen og ikke å overføre dataene til serveren igjen og igjen.
Så langt har vi ikke diskutert ikke-standardiserte løsninger for vedvarende data på klientmaskinen. Da Adobe (da kjent som Macromedia) utviklere lanserte Flash Player 6, måtte de også løse det samme problemet. I 2002 introduserte Flash Player 6 en ny funksjon kalt Local Shared Object eller oftere kjent som Flash Cookies å effektivt introdusere de samme egenskapene som standard HTTP Cookies til Flash-filmer og nettsteder. Lokalt delt objekt tillater utviklere å vedvare som 100KB data på klientmaskinen som standard.
Den andre løsningen er Googles implementering av lokal lagring som en del av Gears-pluginet for nettlesere. Gears var (og jeg forteller deg hvorfor jeg bruker var i et øyeblikk) kombinasjonen av flere manglende og nyttige funksjoner som trengs for å utvikle Rich Internet Applications (RIA). Gears 'Local Storage var basert på den mindre populære Web SQL-spesifikasjonen som benyttet seg av SQLite. Du gjettet det riktig, Gears ga utviklere en fullblåst SQL-database for å vedvare en ubegrenset mengde data på klientmaskinen.
Utviklerne av Ajax Massive Storage System (AMASS) benyttet denne muligheten og utviklet et tredjeparts JavaScript-bibliotek som gjorde det mulig for standard HTML-nettsteder å utnytte funksjonen Lokalt delt objekt i Flash eller Gears-plugin for å fortsette data på klient maskin. Også, Dojo JavaScript Library er i stand til å oppdage tilgjengeligheten av lokal lagringsmekanikk (for eksempel Google Gears, Local Shared Object etc.) og gir et enhetlig grensesnitt for vedvarende data på tvers av forskjellige nettlesere.
Tilbake til hvorfor jeg sa Gears var "istedenfor" fortsatt er ": det er fordi Google nylig annonserte at de vil slippe videre utvikling av Gears-pluginet til fordel for HTML5 og Web Storage-spesifikasjonen som presenteres i denne opplæringen.
Nå som historieleksjonen er over, skal vi lære om Web Storage og dykke inn i en kode for å bedre forstå det. Den enkleste måten å beskrive Web Storage er evnen til å vedvare data på klientmaskinen i form av en nøkkel for en verdi. Dette ligner veldig på hvordan assosiative arrays brukes:
"Nøkkelen": "Verdien"
Lokal lagring er designet for å være støttet av nettlesere. Dette betyr ikke flere tredjepartsbiblioteker og messing med Flash. Overraskende nok har Web Storage vært en av de mer vellykkede spesifikasjonene når det gjelder adopsjon av moderne nettlesere. Faktisk støtter nesten alle moderne nettlesere Web Storage, inkludert:
Mens Web Storage har til hensikt å gi funksjonalitet som ligner på Cookies, har den blitt ytterligere raffinert for ikke å bære noen av deres negative egenskaper. For eksempel gjør Web Storage mulig for vedvarende opptil 5 MB data, en betydelig økning i plass sammenlignet med hvor mye data som kan lagres i en Cookie. Videre vil vedvarende data ved hjelp av Web Storage ikke resultere i å sende dataene til serverbackend med hver sideforespørsel. Dette øker ytelsen betydelig. I henhold til Web Storage-spesifikasjonen utløper nettlesere bare de vedvarende dataene fra den lokale maskinen når den blir bedt om det av brukeren, og vil alltid unngå å slette data mens et skript som kan få tilgang til at dataene kjører.
Weblesere avslører weblagring via lokal lagring objekt i JavaScript. En enkel måte å avgjøre om en nettleser kan støtte weblagring, er å utføre denne JavaScript-koden:
Accentsconagua
var webStorageSupported = ('localStorage' i vinduet) && window ['localStorage']! == null; I henhold til W3Cs spesifikasjon for Web Storage, er lokal lagring objektet implementerer følgende sett med metoder og egenskaper fra Lagringsgrensesnittet. La oss undersøke hver av disse metodene og egenskapene for å finne ut hva de gjør og hvordan de kan brukes:
grensesnitt Lagring lengst lang lengde; tomrom setItem (Strenge, Objektdata); Gjenstand getItem (strengnøkkel); tomrom removeItem (strengnøkkel); tomrom klar(); string nøkkel (lang indeks); ;
De lengde Eiendommen er veldig nyttig. Det vil returnere antall nøkkel / verdi-par som er lagret i lokal lagring under det nåværende domenet:
alert (localStorage.length);
Hvis ingen nøkkel / verdi-par tidligere er lagret i lokal lagring, vil det ovennevnte skriptet vise et varselvindu med "0" som meldingen, ellers vil meldingen være antall vedvarende nøkkel / verdipar.
De setItem (nøkkel, verdi) Metode lagrer bare en ny oppføring på den lokale maskinen. For å lagre nøkkelen Navn med verdien Arman vi kunne utføre dette skriptet:
localStorage.setItem ('navn', 'arman'); For å sikre at nøkkelen Navn var virkelig reddet til lokal lagring med verdien Arman vi må bruke getItem (nøkkel) metode. De getItem Metoden aksepterer bare en nøkkel og søker i lokal lagring for å finne en matchende nøkkel og returnerer deretter verdien.
localStorage.setItem ('navn', 'arman'); var verdi = localStorage.getItem ('navn'); alert (value); Hvis du kjører det ovennevnte skriptet, bør du se et varselvindu som inneholder ordet Arman vises på skjermen, bekrefter at vi har lagret et nytt nøkkel / verdi par til lokal lagring. Siden lokal lagring objekt oppfører seg ligner på associative arrays, vi kunne forenkle det ovennevnte skriptet for å se slik ut og det vil fortsatt fungere akkurat det samme:
localStorage ['name'] = 'arman'; var verdi = localStorage ['name']; alert (value);
La oss se på removeItem (nøkkel) metode. Denne metoden er utformet for å fjerne et tidligere lagret nøkkel / verdi-par fra lokal lagring. Hvis nøkkelen ikke eksisterer, gjør denne metoden ingenting. Følgende kodeprøve demonstrerer bruken av fjerne gjenstand metode:
localStorage.setItem ('navn', 'arman'); localStorage.removeItem ( 'navn'); var verdi = localStorage.getItem ('navn'); alert (value); Når det ovennevnte skriptet blir utført, bør du se et advarselsvindu med verdien null i varselboksen. Bruker Navn nøkkelen, oppretter skriptet bare et nytt nøkkel / verdi-par og fjerner det umiddelbart fra lokal lagring. Deretter returneres en nullverdi når du får tilgang til det lokale lagringsstedet med det samme Navn nøkkel.
Det vil komme anledninger der det vil være behov for å fullstendig fjerne lokalt lagringsplass og starte med en ren skifer. De klar() Metoden er utformet nøyaktig for det formålet. Denne metoden tømmer automatisk alle tidligere lagrede nøkkel / verdipar fra lokal lagring. Hvis det ikke er noen oppføringer, endres ingenting.
localStorage.setItem ('navn', 'arman'); localStorage.setItem ('navn', 'smith'); localStorage.setItem ('navn', 'frank'); alert (localStorage.length); localStorage.clear (); alert (localStorage.length); Selv om det ovennevnte skriptet oppretter tre nye nøkkel / verdipar (som vist ved første varsel), fjerner anropet til klare () -metoden alle oppføringene. Deretter vil det andre varselvinduet vise en "0" melding.
Den endelige metoden vi må se på er nøkkel (indeks) metode. Denne metoden vil hente navnet på en nøkkel basert på indeksparameteren. lokal lagring opprettholder en 0-basert liste over alle oppføringer i seg selv. Derfor, for å få tilgang til den første nøkkelen fra lokal lagring, må vi bruke 0 som indeksen som illustrert i dette skriptet:
localStorage.clear (); localStorage.setItem ('age', 5); alert (localStorage.key (0)); Når det ovennevnte skriptet blir utført, skal det vises et varselvindu med meldingen "alder". Legg merke til hvordan i det ovennevnte eksemplet den første linjen med kode sletter lokal lagring. Dette er for å sikre at vi begynner med en ren skifer. En annen nyttig anvendelse av nøkkel() Metoden er i forbindelse med lengde eiendom. For eksempel å få alle nøkkel / verdi-parene fra det lokale lagringsstedet uten å vite nøklene på forhånd, kan vi skrive et skript som følgende:
localStorage.clear (); localStorage.setItem ("title", "Mr."); localStorage.setItem ("fullname", "Aaron Darwin"); localStorage.setItem ("age", 17); localStorage.setItem ("høyde", 182,5); for (var i = 0; i < localStorage.length; i++) var keyName = localStorage.key(i); var value = localStorage.getItem(keyName); alert(keyName + " = " + value); I det ovennevnte skriptet fjerner koden vår først og legger deretter til fire nye nøkkel / verdipar til lokal lagring. Deretter bruker den lengde eiendom i en Til sløyfe for å utarbeide nøkkelen for hvert nøkkel / verdi par. Ved hver iterasjon av løkken er nøkkelen tilordnet til KeyName variabel som deretter sendes til getItem () metode for å hente sin verdi.
Når du får tilgang til data ved hjelp av en nøkkel som ikke finnes i lokal lagring, i stedet for et unntak, a null verdien returneres alltid. Dette gjør det vanskelig å vite om verdien av nøkkelen er null eller nøkkelen eksisterer bare ikke i lokal lagring.
Den andre å snakke om er setItem (nøkkel, verdi) metode. Vi vet at vi kan overføre noen form for verdi til setItem () metode for verdi parameter, men det er ikke helt sant. I JavaScript kan vi lage Bilde objekter. Den nåværende implementeringen av Web Storage tillater imidlertid vedvarende primitive typer som string, boolean, Integer og Flyte typer. Derfor kan vi forvente at følgende skript kaster et unntak og et krasj:
var imageObject = nytt bilde ("http://www.google.com/logo.gif"); localStorage.setItem ("image", imageObject); I tillegg, selv om vi kan lagre boolean, Integer og Flyte typer, ligger den underliggende representasjonen av disse typene tilbake på string type. Dette betyr uansett hvilken type verdi som overføres til setItem () metode, den getItem () Metoden vil alltid returnere en verdi som er av typen String. La oss se på et eksempelskript:
var integerVariabel = 34; localStorage.setItem ("age", integerVariable); var newVariable = localStorage.getItem ("age"); varsling (typeof (newVariable) == "nummer"); I det ovennevnte skriptet, til slutt verdien av integerVariable lagres som streng. Derfor, når vi inspiserer typen newVariable etter å ha fått sin verdi fra lokal lagring, er det ikke lenger en helhetstype, og derfor vil sammenligningsoppgaven evaluere til falsk. I slike situasjoner må vi bruke den praktiske parseInt (String) og parseFloat (String) Fungerer for konvertering. Det er ingen funksjon å analysere boolean datatype, så vi må bare sammenligne den hentede verdien med "ekte" eller "falske" strenger.
Til slutt, for å få sammenligningserklæringen i det ovennevnte skriptet til å evaluere til ekte, Vi må endre koden vår for å bruke funksjonen parseInt () som vist i følgende skript:
var integerVariabel = 34; localStorage.setItem ("age", integerVariable); var newVariable = parseInt (localStorage.getItem ("age")); varsling (typeof (newVariable) == "nummer"); Nå, når det ovennevnte skriptet utføres, typen av verdien som er lagret i newVariable vil være Integer. Deretter vil sammenligningsoppgaven evaluere til ekte.
Når de vedvarende dataene når 5 MB kvoten, gir ikke weblesere muligheten til å be om mer plass i lokal lagring. De kaster i stedet QUOTA_EXCEEDED_ERR unntak for å varsle skriptet om at det ikke er mer plass. Den enkleste måten å håndtere dette unntaket er å ta unntaket og varsle brukeren om problemet.
Alternativt når man unngår unntaket, kan skriptet slette noen nøkkel / verdioppføringer fra lokal lagring for å rydde opp plass til nye par.
Til slutt, når dokumentet blir forespurt direkte fra disken og ikke fra en webserver, blir det lokale lagringsstedet fjernet hver gang du navigerer bort fra siden.
Web Storage Standard lar skript bli varslet når andre deler av koden legger til, oppdaterer eller sletter oppføringer fra lokal lagring. Således, når noe endres i lokal lagring, a Lagringsarrangement kommer til ild. Men hvis du sletter en oppføring ved hjelp av en ikke eksisterende nøkkel, vil ingen hendelse bli sparket. Dette skyldes at ingenting vil endres i lokal lagring. Dessverre viste mine tester at webkit-nettlesere (for eksempel Safari og Chrome) for tiden ikke brenner Lagringsarrangementer som beskrevet av Web Storage-spesifikasjonen. Internet Explorer, Firefox og Opera-nettleserne oppfører seg som forventet.
En lokal lagringshendelse kan ikke kanselleres. Dens eneste formål er å varsle brukerkoden til en endring som har skjedd i lokal lagring.
Følgende skript viser hvordan du lytter etter endringer i lokal lagring, ved å registrere en hendelseshandler som blir kalt hver gang a Lagringsarrangement er sparken:
hvis (window.addEventListener) window.addEventListener ("storage", handleStorageChange, false); ellers window.attachEvent ("onstorage", handleStorageChange); funksjonshåndtakStorageChange (event) alert ("Noe ble endret i lokal lagring"); Siden ingen versjon av Internet Explorer (unntatt versjon 9 offentlig forhåndsvisning) støtter DOM Level 2-hendelseshåndteringssystemet, vil attacheEvent () Metoden må brukes til å registrere hendelsesbehandlere.
De begivenhet Argumentet er nyttig fordi det bærer informasjon om endringer i lokal lagring. Det overholder StorageEvent grensesnitt:
grensesnitt StorageEvent: Event readonly String nøkkel; readonly Object OLDVALUE; lett gjenstand nyVerdi; readonly String url; ;
De nøkkel Egenskapen identifiserer hvilket nøkkel / verdi-par som ble endret. De OLDVALUE og nyVerdi egenskaper oppfører seg som deres navn antyder. Det vil si at de inneholder henholdsvis den forrige og den nye verdien for nøkkelen.
Endelig, den url Egenskapen inneholder adressen til dokumentet som den lokale lagringen var justert for. På grunn av flere gjennomførings-iterasjoner av Web Storage-spesifikasjonen, er det i enkelte nettlesere url Eiendommen kan bli implementert som uri. Derfor er det bedre å først sjekke url eiendom og deretter uri i tilfelle url Eiendommen er udefinert.
Etter å ha lest dette mye, liker jeg vanligvis å se et eksempel før jeg tror alt. Akkurat som meg selv, er jeg sikker på at mange av dere også vil se et fungerende eksempel. Det er ikke noe problem, fordi jeg har utarbeidet et lite skript som bare demonstrerer bruken av weblagringsstandarden i et fungerende program.
Den er laget slik at den også kan testes ved hjelp av iPhone Safari og Android Web Browser. Tanken er å få nettleseren til å huske hvilke bokser som har blitt åpnet før du bruker lokal lagring. Jeg forlater deg med denne koden for å spille med:
Web Storage Demo
Denne siden var designet for å bare vise bruk av Web Storage i moderne nettlesere. I dette eksemplet er boksene som ikke har blitt klikket, fortsatt svarte. Når du klikker på en svart boks, blir den ekte fargen avslørt. Nettleseren vil imidlertid huske hvilke bokser som klikkes, selv når du navigerer bort fra denne siden. Fortsett, prøv det.
