基于python分布式爬虫并解决假死的问题

2024-08-09 15:53:38

python版本：3.5.4

系统：win10 x64

通过网页下载视频

方法一：使用urllib.retrieve函数

放函数只需要两个参数即可下载相应内容到本地，一个是网址，一个是保存位置

import urllib.request
url = 'http://xxx.com/xxx.mp4'
file = 'xxx.mp4'
urllib.request.retrieve(url, file)

但是博主在使用过程中发现，该函数没有timeout方法。使用时，可能由于网络问题导致假死！

方法二：使用urllib.request.urlopen函数

使用方法如下：

import urllib.request
url = 'http://xxx.com/xxx.mp4'
file = 'xxx.mp4'
response = urllib.request.urlopen(url, timeout=5)
data = response.read()
with open(file, 'wb') as video:
    video.write(data)

此函数有timeout设置，可以避免假死。

使程序并行化

伪代码如下：

import urllib.request
import socket
from urllib import error
from queue import Queue
from threading import Thread
import os
class DownloadWorker(Thread):  #定义一个类，继承自thread类，重写其run函数
    def __init__(self, queue):
        Thread.__init__(self)
        self.queue = queue     #标准的多线程实现方法都使用了queue
    def run(self):
        while True:
            link, file = self.queue.get() #从队列中获取一组网址以及对应的保存位置
            try: #使用try except方法进行各种异常处理
                response = urllib.request.urlopen(link, timeout=5)
                data = response.read()
                with open(file, 'wb') as video:
                    video.write(data)
            except error.HTTPError as err:
                print('HTTPerror, code: %s' % err.code)
            except error.URLError as err:
                print('URLerror, reason: %s' % err.reason)
            except socket.timeout:
                print('Time Out!')
            except:
                print('Unkown Error!')
            self.queue.task_done() #标记队列中的一个元素已经被处理
def main():
    queue = Queue() #定义队列
    for x in range(8): #开启8个线程
        worker = DownloadWorker(queue)
        worker.daemon = True
        worker.start()
    for lineData in txtData: #向队列中放入数据
        link = lineData[0]
        file = lineData[1]
        queue.put((link, file))
    queue.join() #等待队列中的数据被处理完毕
if __name__ == '__main__':
    main()

补充：基于python的一个大规模爬虫遇到的一些问题总结

前些天在某个论坛看到一些很感兴趣的信息，想要将其爬取下来，预估了下规模，想要做的是：将整个论坛的所有文章爬取下来，保存为本地的txt。

一开始写了个爬虫，大致思路是：

先从论坛的起始页开始爬起，得到所有分区版面的网址

然后从分区版面得到该区总共的页码数，根据网址规律得到分区版面所有页数的网页

从上面的分区版面的某一页的网页中得到该页所有文章的网址，然后抓取这些文章，保存为本地txt

上面的思路是典型的自上而下的思路，这样第一版本的代码就写好了。

下面进入正题，总结一下遇到的问题：

一、大规模爬虫被网站封禁的问题

上面的爬虫在调试阶段表现还是不错的，后来实测中，跑起来发现，跑了一段时间后就会发生http错误，由于使用的是有线网，且检查后不是网络本身的错误，所以判定为本网站封禁了，于是开始研究这个问题。

一般来说，python爬虫将自己伪装为浏览器时，使用的方法是在urllib2.Request函数中加入headers参数，也即类似于

"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/22.0.1207.1 Safari/537.1"

的user_agent代码片段，但是这样在大规模爬取中，就会被网站判定为一个用于长期快速访问，容易被封禁。本来在开始的代码中，爬虫访问两个网页之间是加入了0.5s的时间延时，就是为了防止这一问题的，结果还是不可以，而如果将延时加大，将会影响到爬虫的效率，而且如此大规模的爬取更是不知要何时才能结束。

于是，考虑伪装成多个浏览器的访问的方法来解决这一问题，具体做的就是，找许多user_agent，保存为一个列表，而在访问网页时，轮流使用以上user_agent，这样就伪装成了许多浏览器。附上具体子函数如下：

user_agent_list = [
        "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/22.0.1207.1 Safari/537.1",
        "Mozilla/5.0 (X11; CrOS i686 2268.111.0) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.57 Safari/536.11",
        "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.6 (KHTML, like Gecko) Chrome/20.0.1092.0 Safari/536.6",
        "Mozilla/5.0 (Windows NT 6.2) AppleWebKit/536.6 (KHTML, like Gecko) Chrome/20.0.1090.0 Safari/536.6",
        "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/19.77.34.5 Safari/537.1",

        "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.9 Safari/536.5",
        "Mozilla/5.0 (Windows NT 6.0) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.36 Safari/536.5",
        "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.3 (KHTML, like Gecko) Chrome/19.0.1063.0 Safari/536.3",
        "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/536.3 (KHTML, like Gecko) Chrome/19.0.1063.0 Safari/536.3",
        "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_0) AppleWebKit/536.3 (KHTML, like Gecko) Chrome/19.0.1063.0 Safari/536.3",

        "Mozilla/5.0 (Windows NT 6.2) AppleWebKit/536.3 (KHTML, like Gecko) Chrome/19.0.1062.0 Safari/536.3",
        "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.3 (KHTML, like Gecko) Chrome/19.0.1062.0 Safari/536.3",
        "Mozilla/5.0 (Windows NT 6.2) AppleWebKit/536.3 (KHTML, like Gecko) Chrome/19.0.1061.1 Safari/536.3",
        "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.3 (KHTML, like Gecko) Chrome/19.0.1061.1 Safari/536.3",
        "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/536.3 (KHTML, like Gecko) Chrome/19.0.1061.1 Safari/536.3",

        "Mozilla/5.0 (Windows NT 6.2) AppleWebKit/536.3 (KHTML, like Gecko) Chrome/19.0.1061.0 Safari/536.3",
        "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.24 (KHTML, like Gecko) Chrome/19.0.1055.1 Safari/535.24",
        "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/535.24 (KHTML, like Gecko) Chrome/19.0.1055.1 Safari/535.24",
        'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.2; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)',
        'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; Media Center PC 6.0; InfoPath.2; MS-RTC LM 8)',
        'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; InfoPath.2)',
        'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0 Zune 3.0)',
        'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MS-RTC LM 8)',
        'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3)',
        'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; MS-RTC LM 8)',
        'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET CLR 4.0.20402; MS-RTC LM 8)',
        'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET CLR 1.1.4322; InfoPath.2)',
        'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)',
        'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; Tablet PC 2.0)',
        'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET CLR 3.0.04506; Media Center PC 5.0; SLCC1)',
        'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)',
        'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0)',
        'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; Tablet PC 2.0; .NET CLR 3.0.04506; Media Center PC 5.0; SLCC1)',
        'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; FDM; Tablet PC 2.0; .NET CLR 4.0.20506; OfficeLiveConnector.1.4; OfficeLivePatch.1.3)',
        'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET CLR 3.0.04506; Media Center PC 5.0; SLCC1; Tablet PC 2.0)',
        'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET CLR 1.1.4322; InfoPath.2)',
        'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.3029; Media Center PC 6.0; Tablet PC 2.0)',
        'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2)',
        'Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 6.0)',
        'Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 5.2; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.0.04506.30)',
        'Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 5.1; Media Center PC 3.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1)',
        'Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 5.1; FDM; .NET CLR 1.1.4322)',
        'Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 5.1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727)',
        'Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 5.1; .NET CLR 1.1.4322; InfoPath.1)',
        'Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 5.1; .NET CLR 1.1.4322; Alexa Toolbar; .NET CLR 2.0.50727)',
        'Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 5.1; .NET CLR 1.1.4322; Alexa Toolbar)',
        'Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)',
        'Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.40607)',
        'Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 5.1; .NET CLR 1.1.4322)',
        'Mozilla/4.0 (compatible; MSIE 7.0b; Windows NT 5.1; .NET CLR 1.0.3705; Media Center PC 3.1; Alexa Toolbar; .NET CLR 1.1.4322; .NET CLR 2.0.50727)',
        'Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)',
        'Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; el-GR)',
        'Mozilla/5.0 (MSIE 7.0; Macintosh; U; SunOS; X11; gu; SV1; InfoPath.2; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)',
        'Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; c .NET CLR 3.0.04506; .NET CLR 3.5.30707; InfoPath.1; el-GR)',
        'Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; c .NET CLR 3.0.04506; .NET CLR 3.5.30707; InfoPath.1; el-GR)',
        'Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 6.0; fr-FR)',
        'Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 6.0; en-US)',
        'Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 5.2; WOW64; .NET CLR 2.0.50727)',
        'Mozilla/4.79 [en] (compatible; MSIE 7.0; Windows NT 5.0; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 1.1.4322; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)',
        'Mozilla/4.0 (Windows; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)',
        'Mozilla/4.0 (Mozilla/4.0; MSIE 7.0; Windows NT 5.1; FDM; SV1; .NET CLR 3.0.04506.30)',
        'Mozilla/4.0 (Mozilla/4.0; MSIE 7.0; Windows NT 5.1; FDM; SV1)',
        'Mozilla/4.0 (compatible;MSIE 7.0;Windows NT 6.0)',
        'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)',
        'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;)',
        'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; YPC 3.2.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .NET CLR 3.5.30729; .NET CLR 3.0.30618)',
        'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; YPC 3.2.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506)',
        'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; Media Center PC 5.0; .NET CLR 2.0.50727)',
        'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 3.0.04506)',
        'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .NET CLR 3.5.30729; .NET CLR 3.0.30618; .NET CLR 1.1.4322)',
       ]

上面大概有60多个user_agent，这样就伪装成了60多个浏览器。尝试这种方法后，发现在此长时间爬取，出错或者访问速度变慢的情况就很少出现了，基本解决了这一问题。

但是，需要注意的是，如果网站不是根据user_agent，而是根据用户的IP来封禁的话，那就不好办了，网上的一些解决办法是云计算之类的，貌似略麻烦，不太适合个人用户，有兴趣的可以看一下相关资料。

二、长时间无人值守网络不稳定的问题

由于规模略大，不可能一直守在电脑前，所以，代码的稳定性（容错性）需要较高，这里，python的try……except……语法就发挥了很好的作用。

前几天的实践证明，出错大多数是由于一时的网络不稳定而出现的，而解决办法也很简单，重新访问以下就好了，于是将抓取网页的函数写成下面的形式

def get_page_first(url):
    global user_agent_index
    user_agent_index+=1
    user_agent_index%=len(user_agent_list)
    user_agent =  user_agent_list[user_agent_index]
    #print user_agent
    print user_agent_index
    headers = { 'User-Agent' : user_agent }
    print u"正在抓取"+url
    req = urllib2.Request(url,headers = headers)
    try:
        response = urllib2.urlopen(req,timeout=30)
        page = response.read()
    except:
        response = urllib2.urlopen(req,timeout=30)
        page = response.read()
    print u"抓取网页"+url
    return page

这里，如果访问一个网页30s无响应，就重新访问。基本解决了这一问题。

三、保存为本地txt时名称出错的问题

由于txt的命名采用的是 “日期--作者——标题”的形式，而一些帖子的标题含有诸如？等txt中不允许出现的命名，这样就会发生报错。这里解决办法是，如果保存文件出错，则先尝试将名称改为“日期--作者——编号”形式，仍然出错，而保存为“日期--编号”的形式。具体代码如下：

try:
                if news_author[0]=='':
                    save_file(path+'//'+news_time[0]+'--'+news_title+'.txt',news)
                else:
                    save_file(path+'//'+news_time[0]+'--'+news_author[0]+u"——"+news_title+'.txt',news)
            except:
                try:
                    save_file(path+'//'+news_time[0]+'--'+news_title+'.txt',news)
                except:
                    save_file(path+'//'+news_time[0]+'--'+str(j)+'-'+str(index)+'.txt',news)

四、保存文件重名覆盖的问题

开始的代码考虑不周，没有想到同一天的帖子中会出现作者和名称都相同的情况，于是后来发现一些版面的总文章数和保存的txt数目不同，后来发现了这一问题。于是将保存文件的子函数修改如下，大致思路就是保存前先检查同名文件是否存在，不存在直接保存；存在的话，在名称后加（i）（i从1开始递增变化），重复上述步骤，直至同名文件不存在：

def save_file(path,inf):
    if not os.path.exists(path):
        f = file(path, 'w')
        f.write(inf)
        f.close
    else:
        i=0
        while(1):
            i+=1
            tpath=path[:-4]
            tpath+='('+str(i)+')'+'.txt'
            if not os.path.exists(tpath):
                break
        f = file(tpath, 'w')
        f.write(inf)
        f.close

五、多线程抓取以及无图版抓取网页抓取速度的一些问题

理论上，大规模的爬虫可以采用多线程的方法加快抓取速度，但是考虑到不要对网站造成过大的压力，也为避免被网站封禁IP，所以主程序中未引入多线程的概念。但是又为了加快进度，就手动打开多个命令行窗口运行爬虫，来同时抓取不同的版面的文章。这样，当一个程序报错，其他的仍然能运行，也是增强了程序的容错性。

实际运行一段时间后，发现该程序的时间延迟最主要是发生在抓取网页的环节，也就是下载网页的时间上，想要提高效率也就是需要改善这一环节。当我正考虑应该采用什么办法解决这一问题时，忽然发现，原来该论坛还提供了无图版的网页（也就是类似于手机版），这样，每个网页的大小就减小了很多，而且文章内容之类所需信息仍然存在，所以就重新修改了代码。然后，发现速度确实有了极大的提升。所以，以后抓取网页前一定要先看看是否存在类似于无图版（手机版）的网页，这样就可以很大的提高速度。

六、整体总结

经过后期一些完善，该代码基本上已经能够连续运行好几天而不出错了，稳定性基本解决了，而且没有漏抓的现象。经过大致十几天日夜兼程，终于抓完了。

以上为个人经验，希望能给大家一个参考，也希望大家多多支持我们。如有错误或未考虑完全的地方，望不吝赐教。

用python爬虫爬取CSDN博主信息

一.项目介绍爬取网址:CSDN首页的Python.Java.前端.架构以及数据库栏目.简单分析其各自的URL不难发现,都是https://www.csdn.net/nav/+栏目名样式,这样我们就可以爬取不同栏目了. 以Python目录页为例,如下图所示: 爬取内容:每篇文章的博主信息,如博主姓名.码龄.原创数.访问量.粉丝数.获赞数.评论数.收藏数 (考虑到周排名.总排名.积分都是根据上述信息综合得到的,对后续分析没实质性的作用,这里暂不爬取.) 不想看代码的朋友可直接跳到第三部分~ 二.S
python爬虫之教你如何爬取地理数据

一.shapely模块 1.shapely shapely是python中开源的针对空间几何进行处理的模块,支持点.线.面等基本几何对象类型以及相关空间操作. 2.point→Point类 curve→LineString和LinearRing类: surface→Polygon类集合方法分别对应MultiPoint.MultiLineString.MultiPolygon 3.导入所需模块 # 导入所需模块 from shapely import geometry as geo from s
python爬虫之你好,李焕英电影票房数据分析

一.前言春节档贺岁片<你好,李焕英>,于2月23日最新数据出来后,票房已经突破42亿,并且赶超其他贺岁片,成为2021的一匹黑马. 从小品演员再到导演,贾玲处女作<你好李焕英>,为何能这么火?接下来荣仔带你运用Python借助电影网站从各个角度剖析这部电影喜得高票房的原因. 二.影评爬取并词云分析毫无疑问, 中国的电影评论伴随着整个社会文化语境的变迁以及不同场域和载体的更迭正发生着明显的变化.在纸质类影评统御了中国电影评论一百年后,又分别出现了电视影评.网络影评.新媒体影评等不
Python爬虫之爬取2020女团选秀数据

一.先看结果 1.1创造营2020撑腰榜前三甲创造营2020撑腰榜前三名分别是希林娜依·高.陈卓璇 .郑乃馨 >>>df1[df1['排名']<=3 ][['排名','姓名','身高','体重','生日','出生地']] 排名姓名身高体重生日出生地 0 1.0 希林娜依·高 NaN NaN 1998年07月31日新疆 1 2.0 陈卓璇 168.0 42.0 1997年08月13日贵州 2 3.0 郑乃馨 NaN NaN 1997年06月25日泰国 1.2青春有
python PyQt5 爬虫实现代码

搞一个图形化界面还是挺酷的,是吧安装库什么的应该不用多说了吧.. 一般来说会让你把 designer.exe(编辑图形化界面的东西,跟vb差不多) 当作外部工具导入到 pycharm 界面里(这里不写了),其实就是打开方便点,不做也没什么关系,没有非要从pycharm打开,界面是这样的: 还要导入一个PyUIC 工具包,这个东西好像还是导入比较好,(写文件目录的时候可能由于安装的问题找不到那个文件,我刚开始也没找到,还不如直接在C盘搜索那个东西来的直接)不然挺麻烦的.UIC 是用来把你做的图形
Python爬虫之教你利用Scrapy爬取图片

Scrapy下载图片项目介绍 Scrapy是一个适用爬取网站数据.提取结构性数据的应用程序框架,它可以通过定制化的修改来满足不同的爬虫需求. 使用Scrapy下载图片项目创建首先在终端创建项目 # win4000为项目名 $ scrapy startproject win4000 该命令将创建下述项目目录. 项目预览查看项目目录 win4000 win4000 spiders __init__.py __init__.py items.py middlewares.py pipelines
python 用递归实现通用爬虫解析器

我们在写爬虫的过程中,除了研究反爬之外,几乎全部的时间都在写解析逻辑.那么,生命苦短,为什么我们不写一个通用解析器呢?对啊!为什么不呢?开整! 需求分析爬虫要解析的网页类型无外乎 html.json 以及一些二进制文件(video.excel 文件等).既然要做成通用解析器,我们有两种实现方式,一种是将网页内容转换成统一的形式,然后用对应的解析规则去解析,比如全部将网页内容转换成 html 形式,然后用 xpath 去提取. 另外一种是配置文件预先告知的方式,你配置成什么类型,解析器就通过对应
利用Python网络爬虫爬取各大音乐评论的代码

python爬虫--爬取网易云音乐评论方1:使用selenium模块,简单粗暴.但是虽然方便但是缺点也是很明显,运行慢等等等. 方2:常规思路:直接去请求服务器 1.简易看出评论是动态加载的,一定是ajax方式. 2.通过网络抓包,可以找出评论请求的的URL 得到请求的URL 3.去查看post请求所上传的数据显然是经过加密的,现在就需要按着网易的思路去解读加密过程,然后进行模拟加密. 4.首先去查看请求是经过那些js到达服务器的 5.设置断点:依次对所发送的内容进行观察,找到评论对应的UR
Python爬虫部分开篇概念讲解

在学习Python爬虫部分,需要你已经学过Python基础和前端的相关知识. 开发环境介绍: window10 操作系统 Python解释器3.8 集成开发环境pycharm 数据的来源及作用数据的来源有哪些? 用户产生的数据: 百度指数政府统计的数据: 政府数据数据管理公司: 聚合数据自己爬取的数据: 爬取网站上的某些视频数据的作用数据分析智能产品的练习数据其他(比如买卖) 爬虫的相关概念 a) 爬虫的概念爬虫就是应用程序,从网上下载各种各样的资源. 换句话说就是使用编程语言
基于python分布式爬虫并解决假死的问题

python版本:3.5.4 系统:win10 x64 通过网页下载视频方法一:使用urllib.retrieve函数放函数只需要两个参数即可下载相应内容到本地,一个是网址,一个是保存位置 import urllib.request url = 'http://xxx.com/xxx.mp4' file = 'xxx.mp4' urllib.request.retrieve(url, file) 但是博主在使用过程中发现,该函数没有timeout方法.使用时,可能由于网络问题导致假死! 方法
python分布式爬虫中消息队列知识点详解

当排队等待人数过多的时候,我们需要设置一个等待区防止秩序混乱,同时再有新来的想要排队也可以呆在这个地方.那么在python分布式爬虫中,消息队列就相当于这样的一个区域,爬虫要进入这个区域找寻自己想要的资源,当然这个是一定的次序的,不然数据获取就会出现重复.就下来我们就python分布式爬虫中的消息队列进行详细解释,小伙伴们可以进一步了解一下. 实现分布式爬取的关键是消息队列,这个问题以消费端为视角更容易理解.你的爬虫程序部署到很多台机器上,那么他们怎么知道自己要爬什么呢?总要有一个地方存储了他们
基于python 凸包问题的解决

最近在看python的算法书,之前在年前买的书,一直在工作间隙的时候,学习充电,终于看到这本书,但是确实又有点难,感觉作者写的代码太炫技了,有时候注释也不怎么能看懂,终于想到一个方法,就是里面说的算法问题,我就百度python解决他,觉得这个挺好. 下面是凸包问题的一个代码. # -*- coding: utf-8 -*- import turtle import random import time f=open('point.txt','w') for i in range(100): x
深入理解Python分布式爬虫原理

首先,我们先来看看,如果是人正常的行为,是如何获取网页内容的. (1)打开浏览器,输入URL,打开源网页 (2)选取我们想要的内容,包括标题,作者,摘要,正文等信息 (3)存储到硬盘中上面的三个过程,映射到技术层面上,其实就是:网络请求,抓取结构化数据,数据存储. 我们使用Python写一个简单的程序,实现上面的简单抓取功能. #!/usr/bin/python #-*- coding: utf-8 -*- ''''' Created on 2014-03-16 @author: Kris '
IIS假死的解决方法缩短IIS应用池回收时间来实现减少IIS假死

IIS日志: 应用程序:ISAPI 'C:\WINDOWS\system32\inetsrv\asp.dll' 报告它自身有问题,原因如下: 'ASP 不正常,因为执行请求的 100% 被挂起,而且请求队列已经使用了 0%.'. 关于 server 2003+IIS6 出现 'ASP 不正常,因为执行请求的 100% 被挂起现像如下: 站点无法打开,或者打开很慢.HTML可以打开.重新启动或者回收应用程序池可恢复.但过一段时间又会出现日志里会有: ISAPI 'C:\WINDOWS\syst
服务器iis假死的原因及解决方法

打开IIS 你就会看到应用程序池,默认只有一个应用程序池,查看应用程序池的属性,会发现他的回收时间,默认多达,1740分钟,就是说,需要在1740分钟后才回收此应用程序池,如果在这个时间内,达到请求的最高限制,那么就会出现ASP假死的情况,这个就是大型网站出现假死的情况,反而,小型网站确不会出现这样的情况,因为他请求少,流量少,还没达到限制数量.当然要看你的服务器上网站数目而定. 单个网站解决方法: 把应用程序池回收时间缩短到300-600分钟,其间回收过程中,需要占用一点CPU资源,没办法,为
asp运行特别慢之iis6假死现象的一种解决方法

前段时间被WINDOWS2003SERVER的IIS6.0假死问题差点搞死了,琢磨了N个通宵之后才磨出了办法,下面的东西希望能给有相同问题的朋友些帮助: 大家在使用iis6时..如果装了动网论坛.肯定有出现过iis6假死现像..就是asp网页打开慢..但是iis却是正常的..静态网页打开速度一样..这时候..我一直是重启的方法..查了官方的资料结果没有...据官方资料说..win2003很快就要打这个补丁了..是iis6对access驱动支持不理像..也算是一个bug吧..由于我的服务器虚拟主机
win2003 iis6 iis假死

IIS日志: 应用程序:ISAPI 'C:\WINDOWS\system32\inetsrv\asp.dll' 报告它自身有问题,原因如下: 'ASP 不正常,因为执行请求的 100% 被挂起,而且请求队列已经使用了 0%.'. 关于server 2003+IIS6 出现 'ASP 不正常,因为执行请求的 100% 被挂起现像如下: 站点无法打开,或者打开很慢.HTML可以打开.重新启动或者回收应用程序池可恢复.但过一段时间又会出现日志里会有: ISAPI 'C:\WINDOWS\syste
基于python 爬虫爬到含空格的url的处理方法

道友问我的一个问题,之前确实没遇见过,在此记录一下. 问题描述在某网站主页提取url进行迭代,爬虫请求主页时没有问题,返回正常,但是在访问在主页提取到的url时出现了400状态码(400 Bad Request). 结论先贴出结论来,如果url里有空格的话,要把空格替换成%20,也就是url编码,否则就会出现400. 解决过程首先百度了一下400状态码什么意思: 400页面是当用户在打开网页时,返回给用户界面带有400提示符的页面.其含义是你访问的页面域名不存在或者请求错误. 主要有两种形
基于Python实现的百度贴吧网络爬虫实例

本文实例讲述了基于Python实现的百度贴吧网络爬虫.分享给大家供大家参考.具体如下: 完整实例代码点击此处本站下载. 项目内容: 用Python写的百度贴吧的网络爬虫. 使用方法: 新建一个BugBaidu.py文件,然后将代码复制到里面后,双击运行. 程序功能: 将贴吧中楼主发布的内容打包txt存储到本地. 原理解释: 首先,先浏览一下某一条贴吧,点击只看楼主并点击第二页之后url发生了一点变化,变成了: http://tieba.baidu.com/p/2296712428?see_lz=