编码问题

因为涉及到中文#xff0c;所以必然地涉及到了编码的问题#xff0c;这一次借这个机会算是彻底搞清楚了。

Unicode是一种编码方案#xff0c;又称万国码…开学前接了一个任务内容是从网上爬取特定属性的数据。

正好之前学了python练练手。

编码问题

因为涉及到中文所以必然地涉及到了编码的问题这一次借这个机会算是彻底搞清楚了。

Unicode是一种编码方案又称万国码可见其包含之广。

但是具体存储到计算机上并不用这种编码可以说它起着一个中间人的作用。

你可以再把Unicode编码(encode)为UTF-8或者GB再存储到计算机上。

UTF-8或者GB也可以进行解码(decode)还原为Unicode。

在python中Unicode是一类对象表现为以u打头的比如u中文而string又是一类对象是在具体编码方式下的实际存在计算机上的字符串。

比如utf-8编码下的中文和gbk编码下的中文并不相同。

可以看如下代码

stru中文

可以看到其实存储在计算机中的只是这样的编码而不是一个一个的汉字在print的时候要知道当时是用的什么样的编码方式才能正确的print出来。

有一个说法提得很好python中的Unicode才是真正的字符串而string是字节串

更多爬取数据分析项目实战点击下方领取↓

项目案例腾讯文档-在线文档https://docs.qq.com/doc/DU1B0ZHlva0hQQVNa

文件编码

既然有不同的编码那么如果在代码文件中直接写string的话那么它到底是哪一种编码呢这个就是由文件的编码所决定的。

文件总是以一定的编码方式保存的。

而python文件可以写上coding的声明语句用来说明这个文件是用什么编码方式保存的。

如果声明的编码方式和实际保存的编码方式不一致就会出现异常。

可以见下面例子

#coding:gbk

pageurllib2.urlopen(url).read()

这样就可以获得到页面的内容。

接下来再用正则匹配去匹配所需要的内容就行了。

这是一个需要登录认证的网站。

也不太难只要导入cookielib和urllib库就行。

import

urllib2.build_opener(urllib2.HTTPCookieProcessor(cookiejar))

这样就装载进一个cookie用urlOpener去open登录以后就可以记住信息。

断线重连

如果只是做到上面的程度不对open进行包装的话只要网络状况有些起伏就直接抛出异常退出整个程序是个很不好的程序。

这个时候只要对异常进行处理多试几次就行了

def

其实正则匹配并不算是一个特别好的方法因为它的容错性很不好网页要完全统一。

如果有稍微的不统一就会失败。

后来看到说有根据xpath来进行选取的下次可以尝试一下。

classahello/span要取出a来如果写成这样的表达式就不行了span

class.*hello/span。

因为*进行了贪婪匹配。

这是要用.?span

class.?hello/span。

跨行匹配。

实现跨行有一种思路是运用DOTALL标志位这样.就会匹配到换行。

但是这样一来整个匹配过程就会变得很慢。

本来的匹配是以行为单位的。

整个过程最多就是O(nc2)n是行数c是平均列数。

现在极有可能变为O((nc)2)。

我的实现方案是运用\n来匹配换行这样可以明确指出匹配最多跨跃多少行。

比如abc\s*\n\s*def就指出查找的是隔一行的。

(.\n)?就可以指定是匹配尽可能少的行。

这里其实还要注意一个点。

有的行末是带有\r的。

也就是说一行是以\r\n结尾的。

当初不知道这一点正则就调试了很久。

现在直接用\s表示行末空格和\r。

无捕获分组。

为了不对捕获的分组造成影响上面的(.\n)可以改为(?:.\n)这样捕获分组时就会忽略它。

单括号要进行转义。

因为单括号在正则里是用来表示分组的所以为了匹配单括号就进行转义。

正则字符串最好用的是带有r前缀的字符串如果不是的话则要对\再进行转义。

快速正则。

写了那么多模式也总结出一规律出来。

先把要匹配的字符相关的段落拿出来。

要匹配的东西用(.?)代替。

把换行\n替换为字符串\s\n\s*再去掉行首行末的空格。

整个过程在vim中可以很快就写好。

Excel操作

这次的数据是放进Excel的。

到后面才意识到如果放进数据库的话可能就没有那么多事了。

但是已经写到一半难以回头了。

搜索Excel可以得出几个方案来一个是用xlrt/xlwt库这个不管电脑上是否安装了Excel都可以运行但只能是xls格式的。

还有一个是直接包装了com需要电脑上安装了软件才行。

我采用的是前一种。

内存不够。

程序一跑起来内存占用就一点一点往上涨。

后面再查了一下知道要用flush_row_data。

但是还是会出错。

一看内存占用没有什么问题一直很平稳。

但最后还是会出现memory

反复地运行。

一点结果都没有。

要命的是bug只在数据量大起来才出现而等数据量大起来往往要好几个小时这debug的成本实在是太高了。

一个偶然的机会突然发现内存占用虽然总体平稳但是会规律性的出现小的高涨而这规律性会不会和flush_row_data有关。

一直疑惑的是data被flush到了哪里。

原来xlwt的作法是很蛋疼的作法。

把数据存在内存里或者flush到一个temp到save的时候再一次性写入。

而问题正出在这一次性写入内存猛涨。

那我要flush_row_data何用为什么不一开始就flush进要写入的地方。

行数限制。

这个是xls格式本身决定的最多行数只能是65536。

而且数据一大文件打开也不方便。

结合以上两点最终采取了这么一个策略如果行数是1000的倍数进行一次flush如果行数超过65536新开一个sheet如果超过3个sheet则新建一个文件。

为了方便把xlwt包装了一下

#coding:utf-8#

__init__(self,name,captionList,typeList,encodingutf8,flushBound1000):

self.namename

self.wbxlwt.Workbook(encodingself.encoding)

self.sheetIndex1

self.wb.save(self.namestr(self.workbookIndex).xls)

self.sheetIndexXLS.MAX_SHEET_NUM:

self.workbookIndex1

self.wbxlwt.Workbook(encodingself.encoding)

self.sheetIndex1

self.sheetself.wb.add_sheet(self.name.encode(self.encoding)str(self.sheetIndex))

for

self.sheet.write(0,i,self.captionList[i])

self.row1

self.sheet.write(self.row,i,float(data[i]))

except

self.sheet.write(self.row,i,data[i])

self.row

self.wb.save(self.namestr(self.workbookIndex).xls)

转换网页特殊字符

由于网页也有自己独特的转义字符在进行正则匹配的时候就有些麻烦。

在官方文档中查到一个用字典替换的方案私以为不错拿来做了一些扩充。

其中有一些是为保持正则的正确性。

html_escape_table

tmp.join(html_escape_table.get(c,c)

for

得出的经验差不多就是这些了。

不过最后写出来的程序自已也不忍再看。

风格很不好。

一开始想着先写着试试。

然后试着试着就不想改了。

最终的程序要跑很久其中网络通信时间占了大部分。

是不是可以考虑用多线程重构一下想想还是就这样吧。