某土地网站cookie和字体反爬虫

网站分析流程：

打开浏览器无痕窗口访问网站首页并抓包：

1、第一次请求返回了一段JS代码

且Set-Cookie: yunsuo_session_verify=bce172d3d4b76e70d08b342b4c675618;

<script type="text/javascript">
function stringToHex(str){
    var val="";
    for(var i = 0; i < str.length; i++){
    if(val == "")
    val = str.charCodeAt(i).toString(16);
    else val += str.charCodeAt(i).toString(16);}
    return val;
}
function YunSuoAutoJump(){ 
    var width =screen.width;
    var height=screen.height;
    var screendate = width + "," + height;
    var curlocation = window.location.href;
    if(-1 == curlocation.indexOf("security_verify_")){  // indexOf方法可返回某个指定的字符串值在字符串中首次出现的位置, 如果要检索的字符串值没有出现，则该方法返回 -1
    document.cookie="srcurl=" + stringToHex(window.location.href) + ";path=/;";}
    self.location = "/DesktopModule/BizframeExtendMdl/workList/bulWorkView.aspx?wmguid=6506735a-142d-4bde-9674-121656045e
                    d1&recorderguid=b65bc136-c939-4fba-a63f-d586f4f88f69&sitePath=&security_verify_data=" + stringToHex(screendate);}  // 会跳转
    // self 指窗口本身，它返回的对象跟window对象是一模一样的                
</script>

每次请求返回的这段JS代码都会将访问页面的url转换为16进制存入到cookie
并且在当前url的基础上拼接一个参数security_verify_data=’屏幕宽+高的16进制‘
在跳转页面设置另一个cookie 'security_session_mid_verify’重新跳转回初始请求页面
2、第二次请求返回同样的JS代码
可以观察到cookie中确实包含srcurl
且Set-Cookie: security_session_mid_verify=ffb3dc19b5925c35e2be8a30abe172b3;
重新跳转到初始请求页面
3、显示第三次请求返回真正的目标页面

所以爬取的时候也要模拟前两次请求拿到cookie才能成功获取数据

除了上述cookie反爬之外还有一个字体反爬：

之前遇到的字体反爬网页源码中的字体都显示形如ģ 的这种表示，F12查看字体为?(这个方框在我写文章的时候其实也是用实体字符’&#x100be‘写的)

不过这次的文字都显示为类似乱码的中文,无论使用任何方法都抓取不到编码而是乱码文字
不能像以前一样通过字体的编码与文字的映射关系将乱码替换为真正的文字（假设已经通过ttf文件整理好映射关系了）

接下来：

1、首先搞懂以&#x为开头的字符串叫做实体字符，是可以被浏览器识别并显示对应字符的
并且发现&#x后面的16进制数字即为乱码的unicode码
因此明白了此网站的字体反爬就是找一堆特别复杂的汉字或者其他不友好的字符，将字符的unicode作为字体的编码

2、采取的方法是将所有ttf文件的编码通过python 的html.upescape转化为原来的unicode码所表示的汉字，然后将requests请求回来的数据中的文字逐一替换
注意这里有一个大坑
网站显示的字符集为gb2312
对response.content.decode(‘gb2312’) 解码替换发现部分字体替换成功
是因为gb2312字符集太小了导致解码出现部分乱码导致替换不成功
后采用gb18030(兼容gb2312)解码成功替换