前端需要處理數據嗎，前端Cookie處理

在瀏覽器端，雖然以LocalStorage為代表的本地持久化方案已經非常成熟，但cookie因其可跨三級及以上域名、可后端參與操作等特性，在涉及用戶驗證等諸多業務中依然被廣泛運用。

Cookie規格

Cookie的基本組成主要由4部分組成：

• Key => Value 存儲數據
• Path 作用路徑
• Domain 作用域
• Expires 過期時間，或者叫生命周期

我們可以用谷歌控制臺體會一下。

打開suning.com，然后在控制臺輸入以下代碼：

document.cookie = `my_data=123; expires=${new Date(2021,0,1).toGMTString()};`
復制代碼

然后進入Application->Cookie->https://www.suning.com，可以看到my_data已經被寫入列表。

前端需要處理數據嗎？在上面的例子中，我們并沒有指定Path和Domain兩個值，所以瀏覽器給出了默認值：

• Path=/ 作用于根及以下分支目錄
• Domain=www.suning.com 作用于該域

如果希望Cookie在三級及以上域名作用，可簡單加一條：

document.cookie = `my_data=123; domain=suning.com; expires=${new Date(2021,0,1).toGMTString()};`
復制代碼

可以看到，Cookie中增加了一條my_data記錄domain=.suning.com。這里的.suning.com可以理解為*.suning.com。

關于Path項及其他Cookie項，這里就不多做解釋了，大家可以自行嘗試或者查詢資料，在控制臺里盡情虐待瀏覽器的cookie。

這里有幾個小的經驗追加一下：

1. 日期格式非常松散。GMT時間格式是Cookie的標準時間格式，但其他時間格式谷歌瀏覽器也可以識別，這個方面大家可以自己探索一下，就不贅述了。因為單純是日期格式問題，就可以寫好多字。
2. Expires時間是UTC時間。
3. 瀏覽器的document.cookie雖然是以字符串形式賦值與取值，但其背后的管理機制卻是類似Map類型。
4. Cookie的銷毀，是通過設置expires為一個過去時，但需要注意其domain path等需要對應。比如：

document.cookie = `my_data=123; domain=suning.com; expires=${new Date(0).toGMTString()};`
復制代碼

后端Set-Cookie

后端往前端塞cookie是一種常用操作，方法是在響應頭中設置set-cookie。瀏覽器會接收這個頭部，并原樣設置到本地cookie中。

Set-Cookie: <name>=<value>[; <name>=<value>]...[; expires=<date>][; domain=<domain_name>][; path=<some_path>][; secure][; httponly]
復制代碼

前端請求攜帶cookie，這個格式看起來是不是與剛才設置document.cookie一致？補充最后兩項說明：

• secure表示cookie只能被發送到http服務器。
• httponly表示cookie不能被客戶端腳本獲取到。

關于HTTP響應頭，這里提兩個注意事項：

1. 頭部的KEY可以重復多個。也就是說，頭部是有可能出現多個set-cookie的。之前我曾遇到這樣一個案例：后端工程師使用NodeJS+KOA做服務，對允許跨域的請求設置了頭部Access-Control-Allow-Origin: *。當服務使用Docker部署后，運維的同學對前置的Nginx也配置了Access-Control-Allow-Origin，所以前端拿到的響應頭中出現兩個Access-Control-Allow-Origin。結果瀏覽器判定此項頭配置無效，造成跨域請求失敗。當然，set-cookie出現多個沒有問題，只是此種情況需要做適配處理。
2. 頭部的KEY大小寫不敏感。但這不代表處理頭部的應用會大小寫不敏感。

Cookie與encodeURI

關于URI/URL/URN

• URI: Uniform Resource Identifier
• URL: Uniform Resource Locator
• URN: Uniform Resource Name

在進行web訪問時，一個web地址(URL)由protocol+domain+path組成。

• protocol: http/https/ftp 等等
• domain: 類似www.suning.com
• path: /aaa/b/cc/d.html 醬嬸兒的 這樣就形成了對一個網絡資源的有效定位，也就是一個Locator。而這個URL實際上在全網范圍也是一個唯一標識，所以也是一個URI。簡單點說，URL是URI的一種。

URN我沒有遇到（意識到？）典型的場景，按RFC來講同樣是URI的一個子集。

關于encodeURI與encodeURIComponent

這兩者的區別在于對URI轉義的字符集不同。encodeURI并不會對一個URI的分割標記做出轉移，比如://啦#啦()啦?&=...，等等。

對encodeURIComponent望文生義的話，是對URI部分的轉義，意圖是被轉義的部分不影響URL的解析，那么就必須將其中的URI定義的字符全部轉義。例子：

window.location.href = `https://auth.suning.com?redir=${encodeURIComponent('https://www.suning.com')}`;
// https://auth.suning.com?redir=https%3A%2F%2Fwww.suning.com
window.location.href = `${encodeURI('https://www.suning.com/prod.do?location=北京')}`;
// https://www.suning.com/prod.do?location=%E5%8C%97%E4%BA%AC
復制代碼

前端設置cookie發送后端，最終的目的，是在不破壞URI的前提下，完整傳遞參數。

encodeURI在Cookie操作中的應用

我們獲取cookie的途徑，不僅是響應頭的set-cookie。也許是localStorage數據，也許是一次API請求。

由于HTTP規范中，頭中只允許使用ASCII字符，所以在向請求頭塞cookie的時候，需要對cookie來源的字符串做預處理。這時候，就用到了encodeURI/encodeURIComponent。由于在GMT時間格式中存在URI的敏感字，也就是說，被encodeURI的忽略的字符集，小于header允許的字符集。所以一次性encode并不可取，需在cookie拼接完成后，做全量分析和處理。

Cookie字符串的切割與分析

如文章開頭所說，為了兼容、復用一些老的登錄框架，往往需要用到cookie處理機制。由于前端AJAX無法處理302請求問題，也就無法處理寫cookie跳轉的登錄行為，所以你可能需要一個后端接口去代理一系列的后端set-cookie行為。

假設中間我們跳轉了兩個頁面，每個頁面set-cookie一次，那么在代理頁面返回的響應頭中，會至少包含2條set-cookie頭部。出于安全考慮，XMLHttpRequest并不能拿到頭部的set-cookie，所以接下來，我們用小程序中的request方法，來作為進一步演示cookie處理問題的工具。

（依然未完）