只爬去了1%的数据就显示信心爬去完毕

[km5ar]

感谢您申报bug，为了表示感谢，如果bug确实存在，您将出现在本项目的贡献者列表里；如果您不但发现了bug，还提供了很好的解决方案，我们会邀请您以pull request的方式成为本项目的代码贡献者（Contributor）；如果您多次提供很好的pull request，我们将邀请您成为本项目的协助者（Collaborator）。当然，是否提供解决方按都是自愿的。不管是否是真正的bug、是否提供解决方案，我们都感谢您对本项目的帮助。

• 问：请您指明哪个版本出了bug（github版/PyPi版/全部）？
  答：pyPi

• 问：您使用的是否是最新的程序（是/否）？
  答：是的

• 问：爬取任意用户都会复现此bug吗（是/否）？
  答：是的

• 问：若只有爬特定微博时才出bug，能否提供出错微博的weibo_id或url（非必填）？
  答：

• 问：若您已提供出错微博的weibo_id或url，可忽略此内容，否则能否提供出错账号的user_id及您配置的since_date，方便我们定位出错微博（非必填）？
  答：

• 问：如果方便，请您描述bug详情，如果代码报错，最好附上错误提示。
  答：不知道为什么一般爬取了 1% 或者2%的数据 就会显示信息爬去完成

这里是我的 config.json 设置 "user_id_list": ["1887344341"], "filter": 0, "since_date": "2019-07-01", "end_date": "2020-05-26", "random_wait_pages": [1, 5], "random_wait_seconds": [6, 10], "global_wait": [[1000, 3600], [500, 2000]], "write_mode": ["csv", "txt"], "pic_download": 0, "video_download": 0,

这里是完成时显示的

------------------------------已获取观察者网(1887344341)的第138页微博------------------------------ Progress: 1%|▎ | 137/11240 [12:33<16:58:11, 5.50s/it] 共爬取1143条微博 信息抓取完毕

[dataabc]

感谢反馈。

该微博共11240页，其中只有137页发布时间在2019-07-01和2020-05-26之间。如果全部爬取这一万多页就是100%，但是只有1%满足配置的筛选条件，所以爬完这些就停止了。如果要获取到100%，给since_date一个较早的时间值就可以了。

如果还有问题，欢迎继续讨论。

[km5ar]

你好， 我认为您的上述描述有错误，因为我看了爬下来的数据，上一次我跑下来最后一个数据是发于 2020年5月20号， 可是刚才我又重新跑了2个多小时， 这次最后一个数据是 2020年5月1号。 所以我的理解是 2019-07-01和2020-05-26之间 是有11240 页 而不是137页

Best, Keyu Chen

Keyu Chen E km5ar@virginia.edu P 347.975.9099 University of Virginia College of Arts & Sciences On Aug 15, 2020, 8:54 AM -0400, Chen Lei notifications@github.com, wrote:

感谢反馈。 该微博共11240页，其中只有137页发布时间在2019-07-01和2020-05-26之间。如果全部爬取这一万多页就是100%，但是只有1%满足配置的筛选条件。如果要获取到100%，给since_date一个较早的时间值就可以了。 如果还有问题，欢迎继续反馈。 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[km5ar]

因为 我想知道的是为什么我设置的是当我设置的时间在 2019-07-01和now 之间的时候， 我跑了3次 每次停止的时间都不一样， 而且最后一个数据点都在2020年5，6 月份左右。。然后我去了博主的主页看。2020年1，2，3，4月和2019年1，2，3，4，5，6，7月都没有爬下来

感谢您的帮忙！

On Aug 15, 2020, 1:55 PM -0400, Keyu Chen km5ar@virginia.edu, wrote:

你好， 我认为您的上述描述有错误，因为我看了爬下来的数据，上一次我跑下来最后一个数据是发于 2020年5月20号， 可是刚才我又重新跑了2个多小时， 这次最后一个数据是 2020年5月1号。 所以我的理解是 2019-07-01和2020-05-26之间 是有11240 页 而不是137页

Best, Keyu Chen

Keyu Chen E km5ar@virginia.edu P 347.975.9099 University of Virginia College of Arts & Sciences On Aug 15, 2020, 8:54 AM -0400, Chen Lei notifications@github.com, wrote:

感谢反馈。 该微博共11240页，其中只有137页发布时间在2019-07-01和2020-05-26之间。如果全部爬取这一万多页就是100%，但是只有1%满足配置的筛选条件。如果要获取到100%，给since_date一个较早的时间值就可以了。 如果还有问题，欢迎继续反馈。 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[km5ar]

我现在目前是每一次大概爬个 2000条左右就会断掉。。。然后我就要把时间设置一下 从断掉的地方接着往下爬

Best, Keyu Chen

Keyu Chen E km5ar@virginia.edu P 347.975.9099 University of Virginia College of Arts & Sciences On Aug 15, 2020, 2:10 PM -0400, Keyu Chen km5ar@virginia.edu, wrote:

因为 我想知道的是为什么我设置的是当我设置的时间在 2019-07-01和now 之间的时候， 我跑了3次 每次停止的时间都不一样， 而且最后一个数据点都在2020年5，6 月份左右。。然后我去了博主的主页看。2020年1，2，3，4月和2019年1，2，3，4，5，6，7月都没有爬下来

感谢您的帮忙！

On Aug 15, 2020, 1:55 PM -0400, Keyu Chen km5ar@virginia.edu, wrote:

你好， 我认为您的上述描述有错误，因为我看了爬下来的数据，上一次我跑下来最后一个数据是发于 2020年5月20号， 可是刚才我又重新跑了2个多小时， 这次最后一个数据是 2020年5月1号。 所以我的理解是 2019-07-01和2020-05-26之间 是有11240 页 而不是137页

Best, Keyu Chen

Keyu Chen E km5ar@virginia.edu P 347.975.9099 University of Virginia College of Arts & Sciences On Aug 15, 2020, 8:54 AM -0400, Chen Lei notifications@github.com, wrote:

感谢反馈。 该微博共11240页，其中只有137页发布时间在2019-07-01和2020-05-26之间。如果全部爬取这一万多页就是100%，但是只有1%满足配置的筛选条件。如果要获取到100%，给since_date一个较早的时间值就可以了。 如果还有问题，欢迎继续反馈。 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[dataabc]

感谢反馈。

是我错了。请问有其它报错信息吗？

[dataabc]

有两种可能： 1.时间筛选接口限制了，虽然要获取发布时间在2019-07-01和2020-05-26之间的微博，但只返回了一部分； 2.可能是速度太快了，被暂时限制了，一段时间后限制自动解除。

对于第一个原因因为不是程序控制的，无法解除；如果是第二种，可以通过降低速度避免，具体是修改config.json配置：

"random_wait_pages": [1, 5],
"random_wait_seconds": [6, 10],
"global_wait": [[1000, 3600], [500, 2000]],

random_wait_pages代表每1到5页随机等待一次，可以适当加快暂停频率（减小数字）；random_wait_seconds代表每次暂停随机等待6至10秒，可以增大等待时间（增大数字）；global_wait是在全局范围控制等待，上面的意思是获取1000页微博等待3600秒，以后再获取500页微博等待2000秒，以后再获取1000页，等待3600秒，以此类推，上面只有两个配置，可以设置任意多个等待配置。

如果还有问题，欢迎继续讨论

[ovack]

@dataabc 我爬的时候发现有这样的问题，可能会造成这个bug的原因： config文件

{
    "user_id_list": "userlist.txt",
    "filter": 1,
    "since_date": "2020-08-01",
    "end_date": "now",
    "random_wait_pages": [
        1,
        5
    ],
    "random_wait_seconds": [
        6,
        10
    ],
    "global_wait": [
        [
            1000,
            3600
        ],
        [
            500,
            2000
        ]
    ],
    "write_mode": [
        "csv",
        "mongo"
    ],
    "pic_download": 1,
    "video_download": 1,
    "cookie": "",
    "mysql_config": {
        "host": "localhost",
        "port": 3306,
        "user": "root",
        "password": "123456",
        "charset": "utf8mb4"
    }
}

复现方式：

爬取一个人的微博，如果完成后手动删除已下载的图片文件，再次执行程序会直接提示已完成，实际目录没有再次下载被删除的图片。

分析：

我大致分析了一下，应该是程序每次爬完会更新userlist.txt这个文件写入更新时间，然后程序再次运行时会优先使用这个时间而不是配置文件里面的since_date，这样会导致如果某一次某几条微博抓取失败，后面再次运行就直接跳过了。

[dataabc]

@ovack

感谢热心反馈。

确实会出现这个情况，程序会优先使用userlist.txt中的since_date。上面的情况略有不同，因为他是通过config.json直接输入user_id，这样程序使用的就是config.json中的since_date。

[bluerthanever]

Edit： 刚回复了又删掉了。感觉不太一样~~但是我觉得发生问题的地方估计是一样的。 https://github.com/dataabc/weiboSpider/blob/16fd1d9dabb9839d3562ad61ed93c7eb577a41e7/weibo_spider/spider.py#L158-L161 我觉得，估计是PageParser的get_one_page的时候，从页面上获取到的weibo数为0，直接return了，后面的页数没有运行。 再具体一点我估计是不是下面这个地方的链接导致的： https://github.com/dataabc/weiboSpider/blob/16fd1d9dabb9839d3562ad61ed93c7eb577a41e7/weibo_spider/parser/page_parser.py#L35 比如直接这样，得到的页面是空的，至少我这边看到是空的： https://weibo.cn/1887344341/profile?starttime=20190501&endtime=20201009&advancedfilter=1&page=832 去掉advancedfilter就有结果了

[dataabc]

@bluerthanever

感谢热心回复。

这也是问题可能的原因，但是目前没有好的解决办法。去掉advancedfilter确实有结果，但是这样starttime和endtime就失效了。猜测当筛选时间后微博结果特别多且页数较大时就有可能会出现这种获取为空的情况，一般微博不会出现这种情况。猜测是微博的限制，暂时没想到解决方法，这个bug只有在end_date参数不为“now”时出现，默认情况下（end_date值为"now"）没有问题。这是因为当end_date值为"now"时获取的是微博列表页，这是没有限制的；当end_date值是具体的日期时，获取的是微博提供的时间筛选列表，这有时候是有限制的，所以end_date尽量使用"now"值。

[dataabc]

@bluerthanever

是否认为不加profile更好？

另外，
https://weibo.cn/1887344341?starttime=20201008&endtime=20201009&advancedfilter=1
这个就只有9页，
https://weibo.cn/1887344341/profile?starttime=20200108&endtime=20201009&advancedfilter=1&page=10
这个就有一千多页，第一页和第九页貌似是一样的，但是后面都是范围外的内容了。

我比较了上面两个链接，它们页数差很多，原因是它们的starttime不同，第一个是20201008，第二个是20200108，换成相同的starttime，页数是一样的，而且它们都会因换页改变总页数。

现在的链接确实不稳定，所以这种筛选时间段（end_date为日期）的方式只是辅助手段，还是以获取微博列表为主。如果发现更稳定的链接，肯定会修改。

[dataabc]

@bluerthanever

第一组，对于微博数很大的情况，带不带profile，在翻页时，总页数都会改变； 第二组，我测试了下面的链接

https://weibo.cn/1887344341/profile?starttime=20201008&endtime=20201009&advancedfilter=1&page=13
https://weibo.cn/1887344341?starttime=20201008&endtime=20201009&advancedfilter=1&page=13

带不带profile，情况也是一样的，不知道是不是我理解错了； 第三组，带不带profile，结果也是一样的。

上面三组，我的测试结果是profile带不带都可以。

咱们在第二组结论是不一样的，而且我没有复现问题，不知道是不是我理解的不对。

[bluerthanever]

唔~好吧，再看了一眼，好像是我弄错了。。。不好意思。。。之前那个删了，有点丢人 那。。。还真是没有别的办法了。

[dataabc]

@bluerthanever

不丢人，能发现两个问题并且解决了一个，已经很棒了，能帮到不少人，真的很感谢。

如果发现其它问题或有其它建议，我们也可以讨论。

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

Closing as stale, please reopen if you'd like to work on this further.