许久不更，省身自愧。假期里事情没做成几件，跑些步也把膝盖搞得残废，年关将至，且以陋文一篇辞旧迎新。
近期想到可以积累一些双语语料以备后用，于是去尝试去一些在线翻译寻求资源，总结下来还是百度翻译的查询结果相对完全（相对于Google翻译和有道翻译），除了能提供相当数量的双语例句外，还有同义词辨析以及来自WordNet的完整词义列表。
-
以查询单词take为例：👇
-
英英释义：一共42种不同的释义结果，可用于语义消歧任务，其数据来源于WordNet，也是语义消歧任务的常用外部知识源。👇
-
双语例句：最直接的想法可以作为机器翻译任务的数据源，注意到这里的双语例句中的take是带有词义标注的，所以用途可能会更为广泛。👇
-
其他几个栏目下的数据笔者简单概括，不再截图赘述：
-
词语用例即一些常用搭配，如take after，take in等，虽然take有非常多的常用搭配，而且有些搭配还有很多的不同释义，笔者认为这些常用搭配的短语在英文语句分词时应当作为整体考虑，因为拆分下来可能并不能找到适合的take语义与其匹配，并且短语后的介词可能也不是其本身的含义。
- 以短语搭配take in为例，常用释义为收留，其他还有 吸收，理解，改小 等含义，显然拆分为take与in后并不能体现这些释义，因此take in就应当视为一个单词考虑。
- 好在并不是所有单词都有如此多的常见搭配，可能通过枚举解决此类问题，通过更加合理的预训练，这样可能会使得模型在一些下游任务的表现得到提升。
-
同反义词以及同义词辨析是百度翻译与其他几个在线翻译最大的突出点，有道翻译没有这一项数据，Google翻译则过于简略缺少例句参考，百度翻译在这一项中除了有同义词的例举释义外，也给出了双语例句作为参考。假设某种任务是让机器辨析某个英文句子中的单词（如take）是否可以用其他类似单词替代（如常见的同义词grasp，capture，hold等），这就可以作为一个可能的数据增强来源。
-
-
既然有如此多具有潜在利用价值的数据可供挖掘，那么如何获取就是关键问题了，当然百度作为巨头自然会对公开数据进行一些加密，笔者通过半天的摸索，基本弄得非常明白，以为爬取思路很有趣味，非常值得借鉴与参考，不辞繁琐且与众友分享一二。
让我们回头再来看一下查询take单词的页面：👇
可以看到网址上清楚得记录了，显然这表示我们在从英文（）翻译到中文（），需要翻译的文本是take，且所有需要爬取的数据都在这个页面上（以双语例句为例可以看到包含在标签中）：👇
似乎问题非常简单，直接获取该页面上的页面源代码即可解决：👇
我们将得到的页面源代码写出到外部文件，查找标签后失望的发现这里面写得都是一些模板语言，缺乏数据填充，并没有需要的东西：👇
此路不通，须当另辟蹊径，也许之后还会回到这段朴素的页面源代码上呢？所谓返璞归真，约莫如此罢。
既然页面源代码上显示为需要数据填充的模板语言，那么前端必然是向后端发起了数据请求，通过抓包应当可以获得需要的数据。👇
不出所料在监听中我们看到了这个数据包，通过上图对应照勉强可以看出右边红框中的数据就是左边的例句 I’ll take any you don’t want.。
查看消息头可以发现这是一个POST请求（左图），表单数据（右图）也非常简单：👇
- 注：cookie没有打码大家也别深究了，截屏中没有登录百度账号，所以cookie里面没有什么有用的信息，事实上百度翻译爬取中cookie是必要的，后文中将会在页面Javascript中看到这一点，为了便于后续代码运行，本文使用明文cookie。
问题似乎又解决了，让我们来试试是否可行：👇
这里同样将POST请求得到的数据导出到外部文件中，可以看到非常完整的页面数据，虽然看起来很乱，但是笔者可以肯定的说页面上所有有用的信息，包括双语例句，同义词辨析等等条目都包含在这段中了，至于如何解析出可用的数据，那就是后话了。👇
大功告成！让我们用上面的代码再试试其他单词的查询结果吧，将上述代码第8行的修正为试试：👇
显然问题没有那么简单，替换成新的单词就无法适用这个方法，回头我们再来看看这张表单数据，里面有两个字段非常令人在意：👇
这个和我们并不知道它们是如何生成的，但是我们可以推断这是用于认证而加密得到的字符串，因此必须弄明白这两个字段从何而来，才能彻底解决百度翻译结果的爬取问题。
我们继续做抓包工作，不过这次我们试试监听中的数据：👇
很不幸地，我们又看到一大堆的文件，而且从数据包的大小来看还都是些又臭又长的代码，如何从这些定位到我们需要的文件，再从文件中定位到字段与的生成逻辑？这里笔者分享自己的定位思路：
- ① 首先先看这里21个文件的文件名一列，像，一看就是页面风格设计的文件，是一个智能验证（显然这里的与并不是很智能），直接可以排除；
- ② 接下来看文件的文件大小一列，一般来说，那种几都不到的文件里都是一些功能性的小工具，或是存放一些小规模的静态数据，基本可以忽略；
- ③ 然后看文件的加载时间一列，注意到这个页面上的数据当时就完全加载了，如果文件都加载得这么慢，那么利用这段还要接着去请求后端数据岂不是会慢得离谱，因此可以只考察那些0毫秒的文件。
- ④ 最后，上面三个策略只是缩小筛选范围，最重要的是这一点，即便不用上面三点的方法也能迅速确定到上图红框中的文件：试想，那个包含了向后端请求数据的文件中一定会有什么？必然会包含表单数据！表单数据中有什么？表单数据中有和这两个字符串！所以只要下载（或直接复制）每个文件的代码，然后全文搜索或，即可确定哪个文件中有我们想看的逻辑。
至此，可以定位到这个文件（文件名的后缀可能随时间推移会变化），注意到走遍红框中有和两个字段：👇
我们将红框中的这段代码复制到下面的框中优化格式查看：👇
这与上文中的表单数据基本吻合，可能多了一个字段，不过这并不重要，因为我们只关心和两个字段的生成逻辑，接下来我们分别就两个字段的生成逻辑代码进行定位。
3.1 生成token的逻辑
首先从较为简单的开始，它的值为，显然不是所有的变量都叫，所谓就是页面的全局变量，通常可以在页面源代码中找到它的定义，即使不能，它的位置也一般在像这种以为前缀的文件中（如果不是当我没说，最坏的结果应该是藏在之前抓包的其他文件中了）。
此时我们回到1 朴素的页面源代码爬取章节中的页面源代码里，用相同的代码拿到页面源代码再看看：👇（完全相同，当然其实这里已经可以直接请求即可，无需带上后面的“查询字符串”了。）
在导出的外部文件中搜索即可定位到下面的页面源代码中的部分：👇
似乎运气不太好，竟然是一个空字符串，别急，再往下面拉几行看看：👇
token为空表示第一次访问百度网站服务器端没有收到baiduid cookie，会导致翻译接口校验不通过，通过刷新解决
原来这里需要带上访问才能得到的值，值得注意的是，这里的请求头与上文POST请求时请求头并不完全相同，是不可以直接套用的，通过访问后抓包，取得下图中的请求头即可：👇
此时我们加入完整的请求头再来一遍：👇
重新查看导出的外部文件中的页面源代码，已经有的值了：👇
另外如果直接在浏览器的控制台中输入变量名也可以直接获取全局变量的值：👇
至此如何获取的方法已经明晰，下文中笔者将给出如何取出这个值的一种相对比较鲁棒的脚本方法（即如果页面源代码发生一些变化也能正确定位这个随机变化的值）。
3.2 生成sign的逻辑
的值为，想要在这个200多的文件中找到某个函数逻辑，似乎全文阅读一遍是不现实的，而且一看就是局部定义的函数，是无法通过控制台输出看到结果的。
不过好消息是我们可以直接看出这个函数的参数是什么：参数为，而恰好是字段的值，即查询的单词（take），这可能算是迷茫中的慰藉了。
接下来的工作就相对偏于经验了，而这本身也是爬虫的魅力所在，因为每一个爬虫都可能是不一样的，同样，在这里适用的逻辑溯源思路并不一定能用在其他复杂爬虫上。笔者仅将自己的思路作为分享。
- ① 首先往找到的表单上方溯寻，找到最近的一个的位置（这里如果你是用的相对高级的编辑器，只需要用鼠标框住，则所有的整词都会高亮出来，非常便于寻找），如下图中上边两个红框所示：👇
- ② 上图中可以看到函数是由一个函数定义得到的，一段代码中这里乱七八糟的函数会有很多，不过这个函数的参数并不多见：，似乎是一段路由，试着全文搜索这段路由字符串，于是从700多行的表单数据我们找到了200多行处的特征路由字符串：👇（红框中为一个完整的函数体）
-
③ 显然被定义为一个方法的接口路由，推测所谓的函数可能是调用这个接口方法，上图红框中是一个完整的函数体，可以推断的逻辑就在这个红框中了。简单整理一下这段代码：👇
-
④ 这里面有三个函数，，，你猜猜看哪个函数是加密的主函数？
- 笔者的水平实属半吊子，我虽然不太清楚这个函数到底是什么意思，但是最后一句已经给出提示，导出的是！，那么肯定是把函数作为路由的调用函数呗；
- 回头再来看最外层的三个参数，，：
- 就只用在处，其余地方用到的都是局部变量；
- 压根就没用到过，所用之处都是局部变量；
- 就更好了，内部的三个函数，，都用参数，所以根本也是没用到过的；
- 所以只需要搞明白的参数到底是什么即可，这玩意儿猜都能猜出来，刚刚的参数是啥来着，是查询的单词呀，那么这里的还能是什么，只能也是查询的单词了；
至此分析结束，我们来检验一下分析的结论是否正确。这里笔者稍微打个岔，如果要将逻辑复现成相对费时费力，而且一旦逻辑改变将需要从头分析，因此这里推荐使用库来直接执行代码，简单使用安装即可：👇
然后我们将上面三个函数，，复制成字符串来执行一下试试看（别忘了尾巴上有个）：👇
报错显示：
好家伙，又是变量，观察一下出现在函数中：
显然是全局变量的一个属性值，但是是什么呢？往上翻一行就可以看到：
让我们到浏览器的控制台里看看这是什么东西：👇
！！！，一切都破案了，让我们回到1 朴素的页面源代码爬取中的页面源代码里，我们找到了的值👇
最后我们修改一下这段代码中的函数，为它添加一个参数，并将其中的替换成即可：👇
输出结果恰为POST表单数据中的字段值（形式类似，但值是不会相同的）：
至此，所有问题已经得到解决，总结来看我们主要是解决了与两个字段的生成逻辑，只需要做最后的代码整合即可。
虽然分析的过程较为漫长，但是代码本身是非常简洁的：👇
特别地，笔者在提取页面源代码的变量值的逻辑写在函数中，笔者的思路是提取页面源代码上所有的标签中的内容，然后使用库进行执行，再取的变量值即可，这相对于较硬的搜索逻辑找到和要相对鲁棒一些，不过为了减少抓取的标签数量，笔者做了一些限制，并且没加入一段都使用异常抛出，因为本身来说这个全局变量是包含了一些自有属性的，直接复制并不能正常运行。
请求头中的可能需要定时更换，不过其有效期应该是比较持久的，不必过于担忧，此外可以加入代理的手段，不过可能会出一些问题，那是后话了。
最后关于得到的数据的解析方法，其实得到的数据是相当大的，笔者在类中另写了三个测试方法，有需要的可以添加到上面的类代码中：👇
本文完，之后笔者将更新一些阅读笔记，目前想看一些文本摘要方向的内容，不过可能还会继续看text-to-SQL方向的东西，谁知道呢~
本文地址：http://www.tpjde.com/quote/897.html 推平第 http://www.tpjde.com/ , 查看更多