前端工作的小伙伴怎么能散孙不了解Cookie。今天小编就为大家带来了这篇文章，让我们一起来看一看Web前端新手应该了解的Cookie知识。
一、Cookie的出现
浏览器和服务器之间的通信少不了HTTP协议，但是因为HTTP协议是无状态的，所以服务器并不知道上一次浏览器做了什么样的 *** 作，这样严重阻碍了交互式Web
应用程序的实现。
针对上述的问题，网景公司的程序员创造了Cookie。
二、Cookie的传输
服务器端在实现Cookie标准的过程中，需要对任意HTTP请求发送Set-CookieHTTP头作为响应的一部分：
1.Set-Cookie:name=valueexpires=Tue,03-Sep-201914:10:21GMTpath=/
domain=.#
浏览器端会存储这样的Cookie，并且为之后的每个请求添加CookieHTTP请求头发送回服务器：
1.Cookie:name=value
服务器通过验证Cookie值，来判断浏览器发送请求属于哪一个用户。
三、浏览器中的Cookie
浏览器中的Cookie主要由以下几部分组成：
·名称：Cookie唯一的名称，必须经过URL编码处理。(同名会出现覆盖的情况)
·值：必须经过URL编码处理。
·域(domain)：默认情况下cookie在当前域下有效，你也可以设置该值来确保对其子域是否有效。
·路径(path)：指定Cookie在哪些路径下有效，默认是当前路径下。
·
失效时间(expires)：默认情况下，浏览器会话结束时会自动删除Cookie也可以设置一个GMT格式的日期，指冲扒链定具体的删除日期如果设置的日期为以前的日期，那么Cookie会立即删除。
·安全标志(secure)：指定之后只允许Cookie发送给https协议。
浏览器在发送请求时，只会将名称与值添加到请求头的Cookie字段中，发送给服务端。
浏览器提供了一个非常蹩脚的API来 *** 作Cookie：
1.document.cookie
通过上述方法可以对该Cookie进行写 *** 作此耐，每一次只能写入一条Cookie字符串：
1.document.cookie='a=1securepath=/'
通过该方法还可以进行Cookie的读 *** 作：
1.document.cookie//"a=1"
由于上述方法 *** 作Cookie非常的不直观，一般都会写一些函数来简化Cookie读取、设置和删除 *** 作。
对于Cookie的设置 *** 作中，需要以下几点：
对于名称和值进行URL编码处理，也就是采用JavaScript中的encodeURIComponent()方法
expires要求传入GMT格式的日期，需要处理为更易书写的方式，比如：设置秒数的方式注意只有的属性名的secure
每一段信息需要采用分号加空格。
1.functionsetCookie(key,value,attributes){
2.if(typeofdocument==='undefined'){
3.return
4.}
5.attributes=Object.assign({},{
6.path:'/'
7.},attributes)
8.
9.let{domain,path,expires,secure}=attributes
10.
11.if(typeofexpires==='number'){
12.expires=newDate(Date.now()+expires*1000)
13.}
14.if(expiresinstanceofDate){
15.expires=expires.toUTCString()
16.}else{
17.expires=''
18.}
19.
20.key=encodeURIComponent(key)
21.value=encodeURIComponent(value)
22.
23.letcookieStr=`${key}=${value}`
24.
25.if(domain){
26.cookieStr+=`domain=${domain}`
27.}
28.
29.if(path){
30.cookieStr+=`path=${path}`
31.}
32.
33.if(expires){
34.cookieStr+=`expires=${expires}`
35.}
36.
37.if(secure){
38.cookieStr+=`secure`
39.}
40.
41.return(document.cookie=cookieStr)
42.}
Cookie的读 *** 作需要注意的是将名称与值进行URL解码处理，也就是调用JavaScript中的decodeURIComponent()方法：
1.functiongetCookie(name){
2.if(typeofdocument==='undefined'){
3.return
4.}
5.letcookies=[]
6.letjar={}
7.document.cookie&&(cookies=document.cookie.split(''))
8.
9.for(leti=0,max=cookies.lengthi
10.let[key,value]=cookies[i].split('=')
11.key=decodeURIComponent(key)
12.value=decodeURIComponent(value)
13.jar[key]=value
14.if(key===name){
15.break
16.}
17.}
18.
19.returnname?jar[name]:jar
20.}
最后一个清除的方法就更加简单了，只要将失效日期(expires)设置为过去的日期即可：
1.functionremoveCookie(key){
2.setCookie(key,'',{expires:-1})
3.}
介绍Cookie基本 *** 作的封装之后，还需要了解浏览器为了限制Cookie不会被恶意使用，规定了Cookie所占磁盘空间的大小以及每个域名下Cookie的个数。
四、服务端的Cookie
相比较浏览器端，服务端执行Cookie的写 *** 作时，是将拼接好的Cookie字符串放入响应头的Set-Cookie字段中执行Cookie的读 *** 作时，则是解析HTTP请求头字段Cookie中的键值对。
与浏览器最大的不同，在于服务端对于Cookie的安全性 *** 碎了心
signed
当设置signed=true时，服务端会对该条Cookie字符串生成两个Set-Cookie响应头字段：
1.Set-Cookie:lastTime=2019-03-05T14:31:05.543Zpath=/httponly
2.Set-Cookie:lastTime.sig=URXREOYTtMnGm0b7qCYFJ2Db400path=/
httponly
这里通过再发送一条以.sig为后缀的名称以及对值进行加密的Cookie，来验证该条Cookie是否在传输的过程中被篡改。
httpOnly
服务端Set-Cookie字段中新增httpOnly属性，当服务端在返回的Cookie信息中含有httpOnly字段时，开发者是不能通过JavaScript来 *** 纵该条Cookie字符串的。
这样做的好处主要在于面对XSS(Cross-sitescripting)攻击时，黑客无法拿到设置httpOnly字段的Cookie信息。
此时，你会发现localStorage相比较Cookie，在XSS攻击的防御上就略逊一筹了。sameSite
在介绍这个新属性之前，首先你需要明白：当用户从#发起#的请求也会携带上Cookie，而从#携带过来的Cookie称为第三方Cookie。
虽然第三方Cookie有一些好处，但是给CSRF(Cross-siterequestforgrey)攻击的机会。
为了从根源上解决CSRF攻击，sameSite属性便闪亮登场了，它的取值有以下几种：
·
strict：浏览器在任何跨域请求中都不会携带Cookie，这样可以有效的防御CSRF攻击，但是对于有多个子域名的网站采用主域名存储用户登录信息的场景，每个子域名都需要用户重新登录，造成用户体验非常的差。
·lax：相比较strict，它允许从三方网站跳转过来的时候使用Cookie。
为了方便大家理解sameSite的实际效果，可以看这个例子：
1.//#服务端会在访问页面时返回如下Cookie
2.cookies.set('foo','aaaaa')
3.cookies.set('bar','bbbbb')
4.cookies.set('name','cccccc')
5.
6.//#服务端会在访问页面时返回如下Cookie
7.cookies.set('foo','a',{sameSite:'strict'})
8.cookies.set('bar','b',{sameSite:'lax'})
9.cookies.set('baz','c')
如何现在用户在#中点击链接跳转到#，它的请求头是这样的：
1.RequestHeaders
2.
3.Cookie:bar=bbaz=c
五、网站性能优化
Cookie在服务端和浏览器的通信中，主要依靠HTTP的响应头和请求头传输的，所以Cookie会占据一定的带宽。
前面提到浏览器会为每一次HTPP请求自动携带上Cookie信息，但是对于同站内的静态资源，服务器并不需要处理其携带的Cookie，这无形中便浪费了带宽。
在最佳实践中，一般都会将静态资源部署到独立的域名上，从而可以避免无效Cookie的影响。
以上就是小编今天为大家分享的关于Web前端新手应该了解的Cookie知识，希望本篇文章能够对正在从事Web前端工作和准备从事Web
前端学习的小伙伴们有所帮助。想要了解更多Web前端相关知识记得关注北大青鸟Web培训官网！
作者|descire
来源|#/article/286535
*声明：内容与图片均来源于网络(部分内容有修改)，版权归原作者所有，如来源信息有误或侵犯权益，请联系我们删除或授权事宜
Cookies的设置你可以在IE的"工具/Internet选项"的"常规"选项卡中，选择"设置/查看文件"，查看所有保存到你电脑里的Cookies。这些文件通常是以user@domain格式命名的，user是你的本地用户名，domain是所访问的网站的域名。如猜卜果你使用NetsCape浏览器，则存放在"C:/PROGRAMFILES/NETS- CAPE/USERS/"里面，与IE不同的是，NETSCAPE是使用一个Cookie文件记录所高兆告有网站的Cookies。
我们可对Cookie进行适当设置：打开"工具/Internet选项"中的"隐私"选项卡（注意该设置只在IE6.0中存在，其他版本IE可以单击"工具/Internet选项" "安全"标签中的"自定义级别"按钮，进行简单调整），调整Cookie的安全级别。通常情况，可以调整到"中高"或者"高"的位置。多数的论坛站点需要使用Cookie信息，如果你从来不去这些地方，可以将安全级调到"阻止所有Cookies"如果只是为了禁止个别网站的Cookie，可以单击"编辑"按钮，将要屏蔽的网站添加到列表中。在"高级"按钮选项中，你可以对第一方Cookie和第三方的Cookie进行设置，第一方Cookie是你正在浏览的网站的Cookie，第三方Cookie是非正在浏览的网站发给你的Cookie，通常要对第三方Cookie选戚明择"拒绝"。你如果需要保存Cookie，可以使用IE的"导入导出"功能，打开"文件/导入导出"，按提示 *** 作即可。
这个问题首先你要明白，WKWebView有自己的进程，使用自己的存储空间来存储cookie和cache，WKWebView会忽视NSURLCache、NSHTTPCookieStorage、NSCredentialStorage这些默认的网络存储， 其他的颤慧网络类如NSURLConnection是无法访问到的。 同时WKWebView发起的资源请求也是不经过NSURLProtocol的，导致无法自定义请求。
让WKWebview支持NSURLProtocol可参考： NSURLProtocol对WKWebView的处理
所以这里应该很清楚，NSHTTPCookieStorage已经用不到了，但是你可以把他作为存储cookie到本地的工具使用。我自己的项目里面已经全部删除了它的使用
以我项目为例，这种方法设置的cookie，不能被js读取到，在浏览器调试中也不能看到。所以通过js开发的此方式不可用，但是可以被PHP等动态语言读取，由于我的项目都是用js开发的，故不用此方式，也不做兼容。这里就不做过多的使用介绍。
这种方式不好的地方就是，只能在初始化的时候注入，如果cookie的值发生变化，就需要重新初始化，就变得比较low。所以这种方式的cookie尽量保证他的值是不变的，比如设备号、设备类型、来源等信息。使用方法如下图：
使用起来就比较方便了。如图孝丛：
最后可能还会遇到问题，前端获取不到，但是我的cookie确实设置成功了，在safari调试器中可以明确的看到cookie确实设置成功了。我猜想可能是由于cookie设置成功的巧洞樱时机在前端使用cookie值的时机之后造成，也无法解决。
前几天看到一篇文章： 苹果拒绝了16个Web API
说了一堆，总结一下就是苹果觉得cookie不安全。所以cookie中尽量设置一些无关紧要的参数，或者就尽量不去使用。
毕竟cookie这个坑，踩起来难受！！！
个人不推荐使用Cookie！
这都是避免出现Android和iOS出现两种不同的传值方式，测试效果上看性能无优劣，只是一种传值方式而已！！！，且看使用起来是否顺手。
一、可以拼接在地址后面，有加密需要的加密
二、通过JSBridge传值，我自己使用的 WebViewJavascriptBridge， 这种方式需要在页面加载完成之后才会起效。
三、将要传的值添加到NSMutableURLRequest的header内，如图：
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）