文章采集接口(万方数据吐槽一下万方，顺带吐槽万方的原因是什么？ )

　　文章采集接口(万方数据吐槽一下万方，顺带吐槽万方的原因是什么？

)

　　最近对万方数据的爬取代码进行了重构，速度在每小时10w左右。因为是公司项目，代码暂时不会开源，先说一下思路和一些注意事项。万方。

　　第一张图：

　　其实道理很简单。医学期刊分为16类。然后先手动取这16个类别对应的唯一id拼接这个类型的URL，然后翻页请求获取类型。每个期刊的信息如下。

　　然后我们得到每个期刊的id，我们可以拼接每个期刊的首页url，但是这时候我们会发现万方里面的期刊首页有两套路由：我称之为new/old version

　　新版本：

　　老板：

　　这两个版本的网址不同，那么如何区分一个期刊是新版还是旧版呢？毕竟我们现在只知道期刊的id。我这里使用的方法是默认把每个期刊都当作旧版，然后用journal id拼接旧版url。

　　如果这个期刊真的是旧版，那么可以到期刊主页请求，如果是新版，则跳转到新版主页。最后我们只需要观察它的response.url就清楚了。

　　为什么要区分期刊是新版还是旧版？我认为这与请求期刊中所有文章问题的下一步有关。

　　因为万方的每一个期刊都是正规的，所以有一个时间树指示这个文章属于哪个期刊、年份和期数，所以我们想要得到这个期刊@>中的所有文章，你首先需要解析这个期刊的时间树，但是新版和旧版的时间树不一样。

　　看图：

　　你看见过吗？这就是为什么我们要在上一步中区分期刊是新版还是旧版。

　　现在知道该期刊是新版还是旧版了，下一步需要请求时间树来获取该期刊的所有年份和每年发行几期，认为这些信息将用于下一个请求 文章 。

　　本来是要求去时间树分析的。拿到有用的资料后，我根据每一期的每一期去索取。文章json 应该是个很美的东西，但是得到的反馈并不是很好，因为我发现最后只请求了一小部分文章，其他的都没有请求，而且返回空的 json。

　　一头雾水，然后就开始玩起来了，像换代理，换UA，加cookie是一个操作，结果是一个猛的操作，结果是250，很尴尬。最后，经过长时间的折腾，终于找到了问题的关键，那就是：

　　看到了，时间树分析了2019年的7个问题文章，分别是01、02到07，但是在请求的时候是1到7，0没了。. . 所以请求的结果都是空的。

　　但即便如此，请求文章的每一期时还是会出现问题，但是这个问题只出现在老版本中，即解析时间树后，请求文章一期一期问题，是有道理的。表示请求的结果会是一个json，

　　但是在老版本中，会不会返回一个html，导致我的程序报错，因为我一直都是按照json处理返回的结果，到现在还没想明白为什么突然返回不返回json而是返回html ，我猜应该是请求太快了吧？

　　所以我又添加了一个进程。当我发现返回的不是json的时候，我把期刊的id+year+issue number放到redis里，然后再设置一个job从redis里取出来，再次请求。只需从集合中删除 json，或者再次将其放入集合中，然后循环请求。

　　这样，通过最终解析本期请求的文章json，得到文章的内容，文章的作者信息也在这个json中。

　　这是整个过程。下一步是呕吐：

　　不得不说，万方真的很喜欢改版。起初，它被称为万方医疗。后来改为万方数据。巧合的是，在我采集期间又修改了一遍，是我现场找到的，从中找到了一个界面：

　　这个界面是万方改版的时候出现的。它在修订之前或之后都不存在。它只出现了一段时间，现在在网页上看不到。

　　该接口用于请求16个类别中的哪些期刊。返回的json收录了每个期刊的所有信息，比期刊首页显示的信息更完整，有两点对我的工作有用。这是一个很大的帮助。每个期刊的时间树必须请求一次。这无疑会减慢爬虫速度，会出现请求不可用的情况。该界面收录日志的时间树。一是如果要获取这个期刊的影响因子，需要请求期刊首页解析页面。不再需要它了。json里面也有，省了很多工作，不过万方官网没有这个接口。如果显示，则表示他们在显示时没有使用该界面。

　　这是请求这个接口的formdata：（code_name是16个分类的唯一标识）