前端面試查漏補缺--(四) 前端本地存儲

前言

本系列最開始是爲了本身面試準備的.後來發現整理愈來愈多,差很少有十二萬字符,最後決定仍是分享出來給你們.css

爲了分享整理出來,花費了本身大量的時間,起碼是隻本身用的三倍時間.若是喜歡的話,歡迎收藏,關注我!謝謝!html

文章連接

合集篇:

前端面試查漏補缺--Index篇(12萬字符合集) 包含目前已寫好的系列其餘十幾篇文章.後續新增值文章不會再在每篇添加連接,強烈建議議點贊,關注合集篇!!!!,謝謝!~前端

後續更新計劃

後續還會繼續添加設計模式,前端工程化,項目流程,部署,閉環,vue常考知識點 等內容.若是以爲內容不錯的話歡迎收藏,關注我!謝謝!vue

求一分內推

目前本人也在準備跳槽,但願各位大佬和HR小姐姐能夠內推一份靠譜的武漢 前端崗位!郵箱:bupabuku@foxmail.com.謝謝啦!~web

cookie

做用面試

cookie是純文本,沒有可執行代碼。存儲數據,當用戶訪問了某個網站(網頁)的時候,咱們就能夠經過cookie來向訪問者電腦上存儲數據,或者某些網站爲了辨別用戶身份、進行session跟蹤而儲存在用戶本地終端上的數據(一般通過加密)ajax

如何工做
當網頁要發http請求時,瀏覽器會先檢查是否有相應的cookie,有則自動添加在request header中的cookie字段中。這些是瀏覽器自動幫咱們作的,並且每一次http請求瀏覽器都會自動幫咱們作。這個特色很重要,由於這關係到「什麼樣的數據適合存儲在cookie中」。算法

存儲在cookie中的數據,每次都會被瀏覽器自動放在http請求中,若是這些數據並非每一個請求都須要發給服務端的數據,瀏覽器這設置自動處理無疑增長了網絡開銷;但若是這些數據是每一個請求都須要發給服務端的數據(好比身份認證信息),瀏覽器這設置自動處理就大大免去了重複添加操做。因此對於那種設置「每次請求都要攜帶的信息(最典型的就是身份認證信息)」就特別適合放在cookie中,其餘類型的數據就不適合了。segmentfault

特徵設計模式

  1. 不一樣的瀏覽器存放的cookie位置不同,也是不能通用的。
  2. cookie的存儲是以域名形式進行區分的,不一樣的域下存儲的cookie是獨立的。
  3. 咱們能夠設置cookie生效的域(當前設置cookie所在域的子域),也就是說,咱們可以操做的cookie是當前域以及當前域下的全部子域
  4. 一個域名下存放的cookie的個數是有限制的,不一樣的瀏覽器存放的個數不同,通常爲20個。
  5. 每一個cookie存放的內容大小也是有限制的,不一樣的瀏覽器存放大小不同,通常爲4KB
  6. cookie也能夠設置過時的時間,默認是會話結束的時候,當時間到期自動銷燬

Cookie主要用於如下三個方面:

  • 會話狀態管理(如用戶登陸狀態、購物車、遊戲分數或其它須要記錄的信息)
  • 個性化設置(如用戶自定義設置、主題等)
  • 瀏覽器行爲跟蹤(如跟蹤分析用戶行爲等)

設置

  • 客戶端設置:
document.cookie = '名字=值';
document.cookie = 'username=cfangxu; domain=baike.baidu.com'    //而且設置了生效域
//在設置這些屬性時,屬性之間由一個分號和一個空格隔開。

//當咱們須要設置多個cookie時
document.cookie = "name=Jonh";
document.cookie = "age=12";
document.cookie = "class=111";
複製代碼

注意: 客戶端能夠設置cookie下列選項:expires(過時時間)、domain(服務器域名)、path(域名下的哪些路徑能夠接受Cookie)、secure(有條件:只有在https協議的網頁中,客戶端設置secure類型的 cookie 才能成功),但沒法設置HttpOnly選項。

  • 服務器端設置

無論你是請求一個資源文件(如 html/js/css/圖片),仍是發送一個ajax請求,服務端都會返回response。而response header中有一項叫set-cookie,是服務端專門用來設置cookie的。

Set-Cookie  //消息頭是一個字符串,其格式以下(中括號中的部分是可選的):
Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]
複製代碼

注意:一個set-Cookie字段只能設置一個cookie,當你要想設置多個 cookie,須要添加一樣多的set-Cookie字段。  服務端能夠設置cookie 的全部選項:expires、domain、path、secure、HttpOnly  經過 Set-Cookie 指定的這些可選項只會在瀏覽器端使用,而不會被髮送至服務器端。

讀取

咱們經過document.cookie來獲取當前網站下的cookie的時候,獲得的字符串形式的值,它包含了當前網站下全部的cookie(爲避免跨域腳本(xss)攻擊,這個方法只能獲取非 HttpOnly 類型的cookie)。它會把全部的cookie經過一個分號+空格的形式串聯起來,例如username=chenfangxu; job=coding

修改 cookie

要想修改一個cookie,只須要從新賦值就行,舊的值會被新的值覆蓋。 但要注意一點,在設置新cookie時,path/domain這幾個選項必定要舊cookie 保持同樣。不然不會修改舊值,而是添加了一個新的 cookie。

刪除 把要刪除的cookie的過時時間設置成已過去的時間,path/domain/這幾個選項必定要舊cookie 保持同樣。

注意

  • cookie雖然是個字符串,但這個字符串中逗號、分號、空格被當作了特殊符號。因此當cookie的 key 和 value 中含有這3個特殊字符時,須要對其進行額外編碼,通常會用escape進行編碼,讀取時用unescape進行解碼;固然也能夠用encodeURIComponent/decodeURIComponent或者encodeURI/decodeURI三者的區別能夠參考這篇文章)。

  • 何時 cookie 會被覆蓋:name/domain/path 這3個字段都相同的時候;

expires

expires選項用來設置「cookie 什麼時間內有效」。**expires實際上是cookie失效日期**,expires必須是 GMT 格式的時間(能夠經過 new Date().toGMTString()或者new Date().toUTCString() 來得到 )。

expires=Thu, 25 Feb 2016 04:18:00 GMT表示cookie講在2016年2月25日4:18分以後失效,對於失效的cookie瀏覽器會清空。若是沒有設置該選項,則默認有效期爲session,即會話cookie。這種cookie在瀏覽器關閉後就沒有了。

expires 是 http/1.0協議中的選項,在新的http/1.1協議中expires已經由 max-age 選項代替,二者的做用都是限制cookie 的有效時間。expires的值是一個時間點(cookie失效時刻= expires),而max-age 的值是一個以爲單位時間段(cookie失效時刻= 建立時刻+ max-age)。 另外,max-age 的默認值是 -1(即有效期爲 session );若max-age有三種可能值:負數、0、正數。負數:有效期session0:刪除cookie;正數:有效期爲建立時刻+ max-age

domain 和 path

domain是域名,path是路徑,二者加起來就構成了 URL,domainpath一塊兒來限制 cookie 能被哪些 URL 訪問。

一句話歸納:某cookie的 domain爲「baidu.com」, path爲「/ 」,若請求的URL(URL 能夠是js/html/img/css資源請求,但不包括 XHR 請求)的域名是「baidu.com」或其子域如「api.baidu.com」、「dev.api.baidu.com」,且 URL 的路徑是「/ 」或子路徑「/home」、「/home/login」,則瀏覽器會將此 cookie 添加到該請求的 cookie 頭部中。

因此domainpath2個選項共同決定了cookie什麼時候被瀏覽器自動添加到請求頭部中發送出去。若是沒有設置這兩個選項,則會使用默認值。domain的默認值爲設置該cookie的網頁所在的域名,path默認值爲設置該cookie的網頁所在的目錄。

secure

一般 cookie 信息都是使用HTTP鏈接傳遞數據,這種傳遞方式很容易被查看,因此 cookie 存儲的信息容易被竊取。假如 cookie 中所傳遞的內容比較重要,那麼就要求使用加密的數據傳輸。

secure選項用來設置cookie只在確保安全的請求中才會發送。當請求是HTTPS或者其餘安全協議時,包含 secure 選項的 cookie 才能被髮送至服務器。

document.cookie = "username=cfangxu; secure"

把cookie設置爲secure,只保證 cookie 與服務器之間的數據傳輸過程加密,而保存在本地的 cookie文件並不加密。就算設置了secure 屬性也並不表明他人不能看到你機器本地保存的 cookie 信息。 機密且敏感的信息毫不應該在 cookie 中存儲或傳輸,由於 cookie 的整個機制本來都是不安全的

注意:若是想在客戶端即網頁中經過 js 去設置secure類型的 cookie,必須保證網頁是https協議的。在http協議的網頁中是沒法設置secure類型cookie的。

httpOnly

這個選項用來設置cookie是否能經過 js 去訪問。默認狀況下,cookie不會帶httpOnly選項(即爲空),因此默認狀況下,客戶端是能夠經過js代碼去訪問(包括讀取、修改、刪除等)這個cookie的。當cookie帶httpOnly選項時,客戶端則沒法經過js代碼去訪問(包括讀取、修改、刪除等)這個cookie。

在客戶端是不能經過js代碼去設置一個httpOnly類型的cookie的,這種類型的cookie只能經過服務端來設置。

——httpOnly與安全

從上面介紹中,你們是否會有這樣的疑問:爲何咱們要限制客戶端去訪問cookie?其實這樣作是爲了保障安全。

試想:若是任何 cookie 都能被客戶端經過document.cookie獲取會發生什麼可怕的事情。當咱們的網頁遭受了 XSS 攻擊,有一段惡意的script腳本插到了網頁中。這段script腳本作的事情是:經過document.cookie讀取了用戶身份驗證相關的 cookie,並將這些 cookie 發送到了攻擊者的服務器。攻擊者垂手可得就拿到了用戶身份驗證信息,因而就能夠搖搖大擺地冒充此用戶訪問你的服務器了(由於攻擊者有合法的用戶身份驗證信息,因此會經過你服務器的驗證)。

第三方cookie

一般cookie的域和瀏覽器地址的域匹配,這被稱爲第一方cookie。那麼第三方cookie就是cookie的域和地址欄中的域不匹配,這種cookie一般被用在第三方廣告網站。爲了跟蹤用戶的瀏覽記錄,而且根據收集的用戶的瀏覽習慣,給用戶推送相關的廣告。  關於第三方cookie和cookie的安全問題能夠查看這篇文章

session和cookie區別

  • session保存在服務器,cookie保存在客戶端
  • session中保存的時對象,cookie保存的是字符串
  • session不能區分路徑,同一個用戶訪問一個網站期間,全部的session在任何一個地方均可以訪問
  • cookie若是設置路徑,則在某些地方不能訪問
  • session須要藉助cookie才能正常工做,若是禁用cookie,session則失效
  • 客戶端會在發送請求的時候,自動將本地存活的cookie封裝在信息頭髮送給服務器 複製代碼

session和cookie應用場景

  • session上下文機制,針對每個用戶,經過sessionid來區分不一樣客戶
  • session是以cookie或url重寫爲基礎的,默認使用cookie實現,系統會創造一個名爲jsessionid的輸出cookie
  • 重要狀態走session,不重要走cookie,登錄信息用session,購物車用cookie

localStorage(本地存儲)

HTML5新方法,僅IE8及以上瀏覽器兼容。

特色:

  • 生命週期:持久化的本地存儲,除非主動刪除數據,不然數據是永遠不會過時的。
  • 存儲的信息在同一域中是共享的
  • 當本頁操做(新增、修改、刪除)了localStorage的時候,本頁面不會觸發storage事件,可是別的頁面會觸發storage事件。
  • 大小:聽說是5M(跟瀏覽器廠商有關係)
  • 在非IE下的瀏覽中能夠本地打開。IE瀏覽器要在服務器中打開。
  • localStorage本質上是對字符串的讀取,若是存儲內容多的話會消耗內存空間,會致使頁面變卡
  • localStorage受同源策略的限制

設置

localStorage.setItem('username','cfangxu');

獲取

localStorage.getItem('username')  也能夠獲取鍵名  localStorage.key(0) #獲取第一個鍵名

刪除

localStorage.removeItem('username')  也能夠一次性清除全部存儲  localStorage.clear()

storage事件

當storage發生改變的時候觸發。

注意: 當前頁面對storage的操做會觸發其餘頁面的storage事件  事件的回調函數中有一個參數event,是一個StorageEvent對象,提供了一些實用的屬性,以下表:

Property Type Description
key String The named key that was added, removed, or moddified
oldValue Any The previous value(now overwritten), or null if a new item was added
newValue Any The new value, or null if an item was added
url/uri String The page that called the method that triggered this change

補充:
js跨頁面觸發事件,利用storage監聽事件 觸發storage事件的條件:

  • 同一瀏覽器打開了兩個同源頁面
  • 其中一個頁面修改了localStorage
  • 另外一個網頁註冊了這個事件

sessionStorage

其實跟localStorage差很少,也是本地存儲,會話本地存儲

特色

  • 用於本地存儲一個會話(session)中的數據,這些數據只有在同一個會話中的頁面才能訪問而且當會話結束後數據也隨之銷燬。所以sessionStorage不是一種持久化的本地存儲,僅僅是會話級別的存儲。也就是說只要這個瀏覽器窗口沒有關閉,即便刷新頁面或進入同源另外一頁面,數據仍然存在。關閉窗口後,sessionStorage即被銷燬,或者在新窗口打開同源的另外一個頁面,sessionStorage也是沒有的。

cookie、localStorage、sessionStorage區別

  • 相同:在本地(瀏覽器端)存儲數據
  • 不一樣:
    • localStorage只要在相同的協議、相同的主機名、相同的端口下,就能讀取/修改到同一份localStorage數據。

    • sessionStorage比localStorage更嚴苛一點,除了協議、主機名、端口外,還要求在同一窗口(也就是瀏覽器的標籤頁)下。

    • localStorage是永久存儲,除非手動刪除。

    • sessionStorage當會話結束(當前頁面關閉的時候,自動銷燬)

    • cookie的數據會在每一次發送http請求的時候,同時發送給服務器而localStorage、sessionStorage不會。

web SQL database和indexedDB

這些不經常使用的前端存儲我就不在這裏多述了(其實就是我不會=.=).想詳細瞭解的能夠查看這篇文章

感謝及參考

相關文章
相關標籤/搜索