前言
只要牵扯到比较敏感的数据，不可避免的需要涉及到反爬。大数据时代，内容安全是一件极其重要的事情。对于前端而言，我们可以在反爬这件事中做些什么。
解决什么问题
一般爬虫工程师有什么爬虫手段
- 从渲染好的 html 页面找到感兴趣或有可能是重要信息的DOM节点，然后获取里面的文本
- 分析相应接口数据，更快、更精确地获取数据
显然，第一种方式便是前端需要考虑去如何处理的。我们要解决的就是让爬虫工程师爬取到的数据尽最大限度模糊。
反爬方案
先了解下一般处理反爬的方案。
- 最简单的可通过加特定请求头解决，不过也极易破解
- IP反爬：服务器检测某个IP在单位时间内的请求次数，如果超过了某个阈值，就直接拒绝服务，返回一些错误信息。
缺点：可使用IP代理，绕过检测 - 账号反爬：登录态下，针对单个用户单位时间内调取接口频率做相应动作，可以不返回数据或者封号。
缺点：可通过注册多个账号绕过检测 - 验证码反爬：图形验证码、行为验证码。通过在查询信息接口加入相应的验证码字段验证。
缺点：- 一些行为验证码包需要付费，自研成本较高；
- 一些深度学习训练验证码识别模型可高效识别图形验证码。
- 较多的行为验证会造成用户使用负担
- 数据加密-加密算法
加密算法涉及范围比较广，不属于本文重点。对于反爬，我们需要知道的是，选取适当的加密算法，前后端对敏感数据进行加解密即可。 - 数据加密-字体加密
通过自定义字体库实现反爬，主要表现在页面数据显示正常，但是获取到的实际数据和控制台展示的是其他字符或者是编码。这种反爬需要解析网站自己的字体库，对加密字符使用字体库对应字符替换。需要制作字体和基本字体间映射关系。
Web端反爬方案
通过上面的分析，在反爬中前端能做的最好的方案就是字体加密反爬。
这个方案的重点在于如何制作字体包，所以这里重点说一下制作字体包的步骤。
字体包制作流程
- 协定需要加密的词云：一个完整的字体包大小在几十兆甚至百兆级别，所以我们需要针对系统内最关键的信息筛出来做成词云，保证引入的字体文件压缩后在几十k上下，越小越好
- 找到项目中使用字体的完整ttf文件，做一个ttf to svg的转换，可以用这个工具1，工具2，工具3
- 将词云中的汉字根据unicode码从第2步得到的svg中拿出来单独做一个svg包
- 使用该工具icommon，上传第3步做好的词云svg包，选中所有字体后生成font（如果直接上传第2步中的全部字体包，一个个选择词云中的字很麻烦，所以做了第3步），这里可以与后端协定一定转换规则，将相应unicode码重定义，同时也可以改实际映射的unicode码，这个码对应的文字或图标是实际会在控制台中展示的物料。
- 导出之后将相应css、ttf等文件引入到项目内
除此之外，我们还可以做什么（加强版）
-
针对数字这种类型的数据，除了上面根据unicode码重定义，还可以与后端协定一些线性变换函数，或者数字映射乱序
-
如果还要继续增加安全性的话，可以再做一层动态字体：按不同转换规则，制作n套字体包，后端随机决定按第x套做转换逻辑，将x与数据一同返回，前端取第x套相应的font-family。
-
如果还要再深一步的话，可以考虑将重点文案区域的DOM通过一些开源工具转为图片展示，增加收集数据成本。
-
当然，我们在项目里引入的ttf文件，是可以在network里下载下来的。但是用一些可以看到ttf包内容的插件看到，解析出来的执行转换逻辑后得到的该字符的unicode，所以爬到的数据和下载完整加密字体包对于爬虫者来说效果一样。
-
可使用一些字体分析工具将下载的ttf文件转为xml，xml内部会有每个字对应的x, y, xMin, yMin, xMax, yMax坐标信息。但通过坐标信息这种方式和本身全量字体包转出来的xml去比对再拿到真实汉字的unicode相比较成本也会更高。
解决方式就是在icommon网站生成字体时，针对单个汉字可做文字本身的坐标替换。 -
针对实际项目，可以结合以上多种方式一起处理，达到团队预期的反爬目的。
实现效果
- 同一个字，页面、控制台、接口返回数据是三种形态，大大增加数据分析难度
- 每次进入页面得出的结果都不一致
- 数字作为更加敏感的数据，虽然看起来都是莫名字符，但比汉字多处理一层
总结
本文从分析如何爬取数据出发，定位到前端需要在反爬中如何处理的方案，并做了关键步骤的详细剖析和解释，希望大家看完后会有所启发。
在做反爬过程中，需要明确的一点是，反爬没有终点，可以说是一条不归路，有反爬就有反反爬。最合适的方案，就是让爬虫收集数据的成本不断增加，ROI不断降低，直到放弃，那么反爬也就算是成功了。
关注公众号：不zhi前端，一起学习，一起进步~
