編碼問題
因?yàn)樯婕暗街形模员厝坏厣婕暗搅司幋a的問題，這一次借這個(gè)機(jī)會(huì)算是徹底搞清楚了。
問題要從文字的編碼講起。原本的英文編碼只有0~255，剛好是8位1個(gè)字節(jié)。為了表示各種不同的語言，自然要進(jìn)行擴(kuò)充。中文的話有GB系列。可能還聽說過Unicode和UTF-8，那么，它們之間是什么關(guān)系呢？
Unicode是一種編碼方案，又稱萬國(guó)碼，可見其包含之廣。但是具體存儲(chǔ)到計(jì)算機(jī)上，并不用這種編碼，可以說它起著一個(gè)中間人的作用。你可以再把Unicode編碼(encode)為UTF-8，或者GB，再存儲(chǔ)到計(jì)算機(jī)上。UTF-8或者GB也可以進(jìn)行解碼(decode)還原為Unicode。
在python中Unicode是一類對(duì)象，表現(xiàn)為以u(píng)打頭的，比如u'中文'，而string又是一類對(duì)象，是在具體編碼方式下的實(shí)際存在計(jì)算機(jī)上的字符串。比如utf-8編碼下的'中文'和gbk編碼下的'中文'，并不相同。可以看如下代碼：

可以看到，其實(shí)存儲(chǔ)在計(jì)算機(jī)中的只是這樣的編碼，而不是一個(gè)一個(gè)的漢字，在print的時(shí)候要知道當(dāng)時(shí)是用的什么樣的編碼方式，才能正確的print出來。有一個(gè)說法提得很好，python中的Unicode才是真正的字符串，而string是字節(jié)串
文件編碼
既然有不同的編碼，那么如果在代碼文件中直接寫string的話，那么它到底是哪一種編碼呢？這個(gè)就是由文件的編碼所決定的。文件總是以一定的編碼方式保存的。而python文件可以寫上coding的聲明語句，用來說明這個(gè)文件是用什么編碼方式保存的。如果聲明的編碼方式和實(shí)際保存的編碼方式不一致就會(huì)出現(xiàn)異常。可以見下面例子： 以u(píng)tf-8保存的文件聲明為gbk

提示錯(cuò)誤 File "test.py", line 1 SyntaxError: Non-ASCII character '/xe6' in file test.py on line 1, but no encodi ng declared; see http://www.python.org/peps/pep-0263.html for details 改為

輸出正常結(jié)果 u'/u6c49' '/xe6/xb1/x89' '/xba/xba' '/xe6/xb1/x89'

基本方法
其實(shí)用python爬取網(wǎng)頁很簡(jiǎn)單，只有簡(jiǎn)單的幾句話

這樣就可以獲得到頁面的內(nèi)容。接下來再用正則匹配去匹配所需要的內(nèi)容就行了。
但是，真正要做起來，就會(huì)有各種各樣的細(xì)節(jié)問題。
登錄
這是一個(gè)需要登錄認(rèn)證的網(wǎng)站。也不太難，只要導(dǎo)入cookielib和urllib庫(kù)就行。

這樣就裝載進(jìn)一個(gè)cookie，用urlOpener去open登錄以后就可以記住信息。
斷線重連
如果只是做到上面的程度，不對(duì)open進(jìn)行包裝的話，只要網(wǎng)絡(luò)狀況有些起伏，就直接拋出異常，退出整個(gè)程序，是個(gè)很不好的程序。這個(gè)時(shí)候，只要對(duì)異常進(jìn)行處理，多試幾次就行了：

正則匹配
其實(shí)正則匹配并不算是一個(gè)特別好的方法，因?yàn)樗娜蒎e(cuò)性很不好，網(wǎng)頁要完全統(tǒng)一。如果有稍微的不統(tǒng)一，就會(huì)失敗。后來看到說有根據(jù)xpath來進(jìn)行選取的，下次可以嘗試一下。
寫正則其實(shí)是有一定技巧的：
非貪婪匹配。比如這樣一個(gè)標(biāo)簽：<span class='a'>hello</span>，要取出a來，如果寫成這樣的表達(dá)式，就不行了：<span class=.*>hello</span>。因?yàn)?進(jìn)行了貪婪匹配。這是要用.?：<span class=.?>hello</span>。
跨行匹配。實(shí)現(xiàn)跨行有一種思路是運(yùn)用DOTALL標(biāo)志位，這樣.就會(huì)匹配到換行。但是這樣一來，整個(gè)匹配過程就會(huì)變得很慢。本來的匹配是以行為單位的。整個(gè)過程最多就是O(nc2)，n是行數(shù)，c是平均列數(shù)。現(xiàn)在極有可能變?yōu)镺((nc)2)。我的實(shí)現(xiàn)方案是運(yùn)用/n來匹配換行，這樣可以明確指出匹配最多跨躍多少行。比如：abc/s*/n/s*def，就指出查找的是隔一行的。(./n)?就可以指定是匹配盡可能少的行。
這里其實(shí)還要注意一個(gè)點(diǎn)。有的行末是帶有/r的。也就是說一行是以/r/n結(jié)尾的。當(dāng)初不知道這一點(diǎn)，正則就調(diào)試了很久。現(xiàn)在直接用/s，表示行末空格和/r。
無捕獲分組。為了不對(duì)捕獲的分組造成影響，上面的(./n)可以改為(?:./n)，這樣捕獲分組時(shí)，就會(huì)忽略它。
單括號(hào)要進(jìn)行轉(zhuǎn)義。因?yàn)閱卫ㄌ?hào)在正則里是用來表示分組的，所以為了匹配單括號(hào)就進(jìn)行轉(zhuǎn)義。正則字符串最好用的是帶有r前綴的字符串，如果不是的話，則要對(duì)/再進(jìn)行轉(zhuǎn)義。
快速正則。寫了那么多模式，也總結(jié)出一規(guī)律出來。先把要匹配的字符相關(guān)的段落拿出來。要匹配的東西用(.?)代替。把換行/n替換為字符串/s/n/s*，再去掉行首行末的空格。整個(gè)過程在vim中可以很快就寫好。
Excel操作
這次的數(shù)據(jù)是放進(jìn)Excel的。到后面才意識(shí)到如果放進(jìn)數(shù)據(jù)庫(kù)的話，可能就沒有那么多事了。但是已經(jīng)寫到一半，難以回頭了。
搜索Excel，可以得出幾個(gè)方案來，一個(gè)是用xlrt/xlwt庫(kù)，這個(gè)不管電腦上是否安裝了Excel，都可以運(yùn)行，但只能是xls格式的。還有一個(gè)是直接包裝了com，需要電腦上安裝了軟件才行。我采用的是前一種。
基本的讀寫沒有問題。但是數(shù)據(jù)量一大起來，就有問題了。
內(nèi)存不夠。程序一跑起來，內(nèi)存占用就一點(diǎn)一點(diǎn)往上漲。后面再查了一下，知道要用flush_row_data。但是還是會(huì)出錯(cuò)。一看內(nèi)存占用，沒有什么問題，一直很平穩(wěn)。但最后還是會(huì)出現(xiàn)memory error。這真是見鬼了。又是反復(fù)地查， 反復(fù)地運(yùn)行。一點(diǎn)結(jié)果都沒有。要命的是bug只在數(shù)據(jù)量大起來才出現(xiàn)，而等數(shù)據(jù)量大起來往往要好幾個(gè)小時(shí)，這debug的成本實(shí)在是太高了。一個(gè)偶然的機(jī)會(huì)，突然發(fā)現(xiàn)內(nèi)存占用，雖然總體平穩(wěn)，但是會(huì)規(guī)律性的出現(xiàn)小的高漲，而這規(guī)律性，會(huì)不會(huì)和flush_row_data，有關(guān)。一直疑惑的是data被flush到了哪里。原來xlwt的作法是很蛋疼的作法。把數(shù)據(jù)存在內(nèi)存里，或者flush到一個(gè)temp，到save的時(shí)候，再一次性寫入。而問題正出在這一次性寫入，內(nèi)存猛漲。那我要flush_row_data何用？為什么不一開始就flush進(jìn)要寫入的地方。
行數(shù)限制。這個(gè)是xls格式本身決定的，最多行數(shù)只能是65536。而且數(shù)據(jù)一大，文件打開也不方便。
結(jié)合以上兩點(diǎn)，最終采取了這么一個(gè)策略，如果行數(shù)是1000的倍數(shù)，進(jìn)行一次flush，如果行數(shù)超過65536，新開一個(gè)sheet，如果超過3個(gè)sheet，則新建一個(gè)文件。為了方便，把xlwt包裝了一下

轉(zhuǎn)換網(wǎng)頁特殊字符
由于網(wǎng)頁也有自己獨(dú)特的轉(zhuǎn)義字符，在進(jìn)行正則匹配的時(shí)候就有些麻煩。在官方文檔中查到一個(gè)用字典替換的方案，私以為不錯(cuò)，拿來做了一些擴(kuò)充。其中有一些是為保持正則的正確性。

結(jié)
得出的經(jīng)驗(yàn)差不多就是這些了。不過最后寫出來的程序自已也不忍再看。風(fēng)格很不好。一開始想著先寫著試試。然后試著試著就不想改了。
最終的程序要跑很久，其中網(wǎng)絡(luò)通信時(shí)間占了大部分。是不是可以考慮用多線程重構(gòu)一下？想想，還是就這樣吧。