本系列最開始是爲了本身面試準備的.後來發現整理愈來愈多,差很少有十二萬字符,最後決定仍是分享出來給你們.css
爲了分享整理出來,花費了本身大量的時間,起碼是隻本身用的三倍時間.若是喜歡的話,歡迎收藏,關注我!謝謝!html
前端面試查漏補缺--Index篇(12萬字符合集) 包含目前已寫好的系列其餘十幾篇文章.後續新增值文章不會再在每篇添加連接,強烈建議議點贊,關注合集篇!!!!,謝謝!~前端
後續還會繼續添加設計模式,前端工程化,項目流程,部署,閉環,vue常考知識點 等內容.若是以爲內容不錯的話歡迎收藏,關注我!謝謝!vue
目前本人也在準備跳槽,但願各位大佬和HR小姐姐能夠內推一份靠譜的武漢 前端崗位!郵箱:bupabuku@foxmail.com.謝謝啦!~web
做用面試
cookie是純文本,沒有可執行代碼。存儲數據,當用戶訪問了某個網站(網頁)的時候,咱們就能夠經過cookie來向訪問者電腦上存儲數據,或者某些網站爲了辨別用戶身份、進行session跟蹤而儲存在用戶本地終端上的數據(一般通過加密)ajax
如何工做
當網頁要發http請求時,瀏覽器會先檢查是否有相應的cookie,有則自動添加在request header中的cookie字段中。這些是瀏覽器自動幫咱們作的,並且每一次http請求瀏覽器都會自動幫咱們作。這個特色很重要,由於這關係到「什麼樣的數據適合存儲在cookie中」。算法
存儲在cookie中的數據,每次都會被瀏覽器自動放在http請求中,若是這些數據並非每一個請求都須要發給服務端的數據,瀏覽器這設置自動處理無疑增長了網絡開銷;但若是這些數據是每一個請求都須要發給服務端的數據(好比身份認證信息),瀏覽器這設置自動處理就大大免去了重複添加操做。因此對於那種設置「每次請求都要攜帶的信息(最典型的就是身份認證信息)」就特別適合放在cookie中,其餘類型的數據就不適合了。segmentfault
特徵設計模式
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
選項用來設置「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、正數。負數:有效期session
;0
:刪除cookie
;正數:有效期爲建立時刻+ max-age
domain
是域名,path
是路徑,二者加起來就構成了 URL,domain
和path
一塊兒來限制 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 頭部中。
因此domain
和path
2個選項共同決定了cookie
什麼時候被瀏覽器自動添加到請求頭部中發送出去。若是沒有設置這兩個選項,則會使用默認值。domain
的默認值爲設置該cookie
的網頁所在的域名,path
默認值爲設置該cookie
的網頁所在的目錄。
一般 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的。
這個選項用來設置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推薦資源
HTML5新方法,僅IE8及以上瀏覽器兼容。
特色:
設置
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差很少,也是本地存儲,會話本地存儲
特色
localStorage只要在相同的協議、相同的主機名、相同的端口下,就能讀取/修改到同一份localStorage數據。
sessionStorage比localStorage更嚴苛一點,除了協議、主機名、端口外,還要求在同一窗口(也就是瀏覽器的標籤頁)下。
localStorage是永久存儲,除非手動刪除。
sessionStorage當會話結束(當前頁面關閉的時候,自動銷燬)
cookie的數據會在每一次發送http請求的時候,同時發送給服務器而localStorage、sessionStorage不會。
這些不經常使用的前端存儲我就不在這裏多述了(其實就是我不會=.=).想詳細瞭解的能夠查看這篇文章