webview获取cookie（webview获取网页源码） - 杂七乱八

今天给各位分享webview获取cookie的知识，其中也会对webview获取网页源码进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

1、ios webview 加载链接携带cookie
2、Android WebView原生与网页交互常用知识点
3、iOS WKWebView Cookie的处理
4、iOS WKWebView设置cookie方法总结

ios webview 加载链接携带cookie

ios 中有的请求需要带cookie, 验证登陆等.

ios默认是会把url 的cookie保存到本地, 但不是实时保存的, 会有延迟, 一般理解为在系统空闲时去保存 . 所以为了实时给url添加cookie, 我们最好将请求url 后获取到的cookie 保存到本地, 用NSUserDefault即可

在设置Cookie之前，先让我们了解一下通用Cookie格式，多个Cookie的格式通常为：cookie1=value1; cookie2=value2; cookie3=value3;

这里特别要注意，多个cookie之间用分号+空格分隔开，不是也不是单纯的空格。我所了解到的iOS设置Cookie的方法有两种，分别如下。

方法一：

方法二：

注意: 一定要把cookie设置到request.allHTTPHeaderFields中才会生效.

网上好多的demo都是这样设置cookie的 --- [[NSHTTPCookieStorage sharedHTTPCookieStorage] setCookie:cookie]; 亲测不能用

update 于当天下午

现在是这样, 要在每一次请求的时候都要带cookie, 如果要按上面那种写法之有在第一次请求的时候带cookie, 其他请求都带不上了,

解决方法 :

Android WebView原生与网页交互常用知识点

2.1 获取cookie

【WebView】Android WebView中的Cookie操作

如果需要构造特定的referrer请求的，比如盗图这种特殊业务时实践过程

实际访问地址：

实际访问地址要校验的referrer：

1、将要访问的实际地址抓换为访问referrer的地址

2、设置Android的浏览器支持JavaScript对Referrer的获取

3、设置如果请求的是构造的那个Referrer的这个请求，则创建一个本地的伪造response

完整例子

iOS WKWebView Cookie的处理

最近接到一个模块迁移的功能，就是把H5页面的某个功能模块嵌入的App中...其中涉及到一些原生和JS交互，cookie认证的问题。。。我这里涉及的cookie是token的回传，登录验证是native

OK，js和native交互的这个很好解决，最烦人的是cookie问题，当然【UIWebView】是真的‘香’，Cookie问题人家自行就给解决了，代价就是内存增加了 100MB+ ，呵呵。。。

内存问题，我随即更换了【WKWebView】，加载页面很快，内存很亮眼，退出控制器也释放占用，但是，这个‘但是’，一出现‘但是’就没好事儿。。。对吧，这个但是就是 H5 页面总提示“账户未登录”，登录返回的“token”设置后，“web”不能获取到。。。呵呵。。。

Cookie知识传送门儿

1. 针对302问题，不使用【allHTTPHeaderFields】设置cookie，将【HTTPShouldHandleCookies】设置为'YES'（默认就是'YES'）

2. ajax问题，向【WKWebView】中注入cookie即，【document.cookie 】

举个栗子?：

重新加载页面数据都出来了，这次是真香，呵呵...

iOS 11.0 后增加了【WKHTTPCookieStore】类，专门用来管理与之关联的 WKWebView 的 Cookie ，引用结构如下：

WKWebView - WKWebViewConfiguration - WKWebsiteDataStore - WKHTTPCookieStore

获取 Cookie 也会有不同步的问题大同小异，不过一般业务里并不会主动去获取 Cookie

webview获取cookie（webview获取网页源码）,webview获取cookie,信息,文章,源码,第1张

iOS WKWebView设置cookie方法总结

这个问题首先你要明白，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出现两种不同的传值方式，测试效果上看性能无优劣，只是一种传值方式而已！！！，且看使用起来是否顺手。

一、可以拼接在地址后面，有加密需要的加密