[新功能提议] 关于输出、避免限制、下载、断点续写 about weibo-crawler HOT 1 OPEN

感谢反馈，非常用心的建议。看到这么细致的建议，有点受宠若惊。

关于输出

当初设计输出微博目的只是为了告诉使用者，程序正在获取信息中，并且展示微博的部分信息给使用者。建议很有意义，只是如果写入文件，是不是这些打印信息只写入文件里，不在显示在shell里。如果这样，优点是更简单，进度条没有被覆盖，清晰明了；缺点是不如打印更直观。打印微博其实是在告诉使用者：这条打印的微博已经获取了。如果不打印，使用者看到的只有进度条，具体获得了哪些微博只能打开打印写入的文件。但是如果这样，csv等结果文件信息更多，打印文件有的内容，结果文件都有，是否有必要即写打印又写结果。所以，我更倾向于直接打印微博。打印中添加原微博地址是一个非常好的建议，这个后面会加上，将打印写入文件目前还不确定是否要加上这个功能。

关于避免限制

非常好的建议，因为使用者要爬的微博多种多样。对应只爬少量微博的使用者，sleep时间不需要太长，对于要爬大量微博的使用者，sleep又需要很长。目前默认的sleep无法适应所有情况。我再考虑将sleep策略单独写一个方法。如每爬10页等待多少秒，每爬100页等待多少秒，等等。即便这样也不一定适用所有情况。我在纠结要不要在config.json文件中加参数，让使用者更具自己的情况配置等待策略。纠结的原因是这样确实更灵活，缺点是参数会越来越多，增加使用成本。
长微博目前的策略是先获取其在微博列表中的微博内容（此时是不完整的微博，微博内容太长，只展示了一部分），然后再尝试获取这条微博的详情页，如果成功，就用新获取的完整微博替换之前不完整的。如果获取失败（比如被限制了），就只用原来不完整的内容作为微博内容，毕竟不完整比没有好一点。
微博条数只有在爬全部微博（原创+转发）时才有意思。一页微博有10条，但这10条即可以是原创也可以是转发，如果只爬原创，这一页微博中到底有多少条是原创不好说，只能计数统计。这样在爬原创时，就有两类微博数，筛选过的能够获得的微博数和原创微博数，还有每页微博不为10条的情况，确实无法通过数量精确判断是否被限制。

关于下载

主要是视频下载，以前出现过大小只有1k的情况，当时出现这个问题的情况已经修复了。现在如果还有这种情况，可能是还没有发现的问题。建议很好，我下一步打算图片和视频下载也和写结果文件一样，爬取一定的页数就写入，这样比集中写入确实要好。还有一类下载的情况，weibo_id会写入not_downloaded.txt，这一类可以统一下载。因为知道weibo_id，就可以最多视频url。再考虑有没有必要写一个专门的项目，专门下载not_downloaded.txt中微博的视频文件。

关于断点续写

非常好的建议。个人认为，如果一个微博中途在某页被限制了。这种情况，记录页数非常有必要，可以通过restart_page继续爬。也可以记录end_date，因为在被限制后，目标微博账号可能还会发新微博，导致出错页后移。比如上次程序在第10页被限制了，再次再爬时，现在微博账号可能又发了些新微博，以前出错页的微博被新微博挤到后面了。这种情况需要解决两个问题，如何爬新微博，如何爬上次没有获取的微博。当然，如果两次爬取间隔非常短。比如第一次被限制后，过一会马上继续爬。这种情况发生新微博挤旧微博的概率很小，可以直接通过restart_page继续爬。

上面的建议非常好，看得出来，是经过认真思考提出来的。上面提到的建议，我认为有必要修改和添加的功能，会陆续加上，时间大致在春节之后。如果还有其它建议，欢迎反馈:smile:
再次感谢建议，非常认真仔细，有深度。上面我的思考由于时间仓促，不一定全面和正确，如果有错误欢迎指正，还有其它建议也欢迎反馈

from weibo-crawler.