福田做商城網(wǎng)站建設多少錢友情鏈接百科
開學前接了一個任務,內(nèi)容是從網(wǎng)上爬取特定屬性的數(shù)據(jù)。正好之前學了python,練練手。
編碼問題
因為涉及到中文,所以必然地涉及到了編碼的問題,這一次借這個機會算是徹底搞清楚了。
Unicode是一種編碼方案,又稱萬國碼,可見其包含之廣。但是具體存儲到計算機上,并不用這種編碼,可以說它起著一個中間人的作用。你可以再把Unicode編碼(encode)為UTF-8,或者GB,再存儲到計算機上。UTF-8或者GB也可以進行解碼(decode)還原為Unicode。
在python中Unicode是一類對象,表現(xiàn)為以u打頭的,比如u'中文',而string又是一類對象,是在具體編碼方式下的實際存在計算機上的字符串。比如utf-8編碼下的'中文'和gbk編碼下的'中文',并不相同??梢钥慈缦麓a:
1 2 3 4 5 6 7 8 9 |
|
可以看到,其實存儲在計算機中的只是這樣的編碼,而不是一個一個的漢字,在print的時候要知道當時是用的什么樣的編碼方式,才能正確的print出來。有一個說法提得很好,python中的Unicode才是真正的字符串,而string是字節(jié)串
更多爬取數(shù)據(jù)分析項目實戰(zhàn)點擊下方領取↓
項目案例騰訊文檔-在線文檔https://docs.qq.com/doc/DU1B0ZHlva0hQQVNa
文件編碼
既然有不同的編碼,那么如果在代碼文件中直接寫string的話,那么它到底是哪一種編碼呢?這個就是由文件的編碼所決定的。文件總是以一定的編碼方式保存的。而python文件可以寫上coding的聲明語句,用來說明這個文件是用什么編碼方式保存的。如果聲明的編碼方式和實際保存的編碼方式不一致就會出現(xiàn)異常??梢砸娤旅胬?#xff1a; 以utf-8保存的文件聲明為gbk
1 2 3 4 5 6 7 8 9 |
|
提示錯誤 File "test.py", line 1 SyntaxError: Non-ASCII character '\xe6' in file test.py on line 1, but no encodi ng declared; see?PEP 263 – Defining Python Source Code Encodings | peps.python.org?for details 改為
1 2 3 4 5 6 7 8 9 |
|
輸出正常結果 u'\u6c49' '\xe6\xb1\x89' '\xba\xba' '\xe6\xb1\x89'
更多內(nèi)容可參見這篇文章Python字符編碼詳解 - AstralWind - 博客園
基本方法
其實用python爬取網(wǎng)頁很簡單,只有簡單的幾句話
1 2 |
|
這樣就可以獲得到頁面的內(nèi)容。接下來再用正則匹配去匹配所需要的內(nèi)容就行了。
但是,真正要做起來,就會有各種各樣的細節(jié)問題。
登錄
這是一個需要登錄認證的網(wǎng)站。也不太難,只要導入cookielib和urllib庫就行。
1 2 3 |
|
這樣就裝載進一個cookie,用urlOpener去open登錄以后就可以記住信息。
斷線重連
如果只是做到上面的程度,不對open進行包裝的話,只要網(wǎng)絡狀況有些起伏,就直接拋出異常,退出整個程序,是個很不好的程序。這個時候,只要對異常進行處理,多試幾次就行了:
1 2 3 4 5 6 7 8 9 |
|
正則匹配
其實正則匹配并不算是一個特別好的方法,因為它的容錯性很不好,網(wǎng)頁要完全統(tǒng)一。如果有稍微的不統(tǒng)一,就會失敗。后來看到說有根據(jù)xpath來進行選取的,下次可以嘗試一下。
寫正則其實是有一定技巧的:
- 非貪婪匹配。比如這樣一個標簽:<span class='a'>hello</span>,要取出a來,如果寫成這樣的表達式,就不行了:<span class=.*>hello</span>。因為*進行了貪婪匹配。這是要用.?:<span class=.?>hello</span>。
- 跨行匹配。實現(xiàn)跨行有一種思路是運用DOTALL標志位,這樣.就會匹配到換行。但是這樣一來,整個匹配過程就會變得很慢。本來的匹配是以行為單位的。整個過程最多就是O(nc2),n是行數(shù),c是平均列數(shù)?,F(xiàn)在極有可能變?yōu)镺((nc)2)。我的實現(xiàn)方案是運用\n來匹配換行,這樣可以明確指出匹配最多跨躍多少行。比如:abc\s*\n\s*def,就指出查找的是隔一行的。(.\n)?就可以指定是匹配盡可能少的行。
- 這里其實還要注意一個點。有的行末是帶有\(zhòng)r的。也就是說一行是以\r\n結尾的。當初不知道這一點,正則就調(diào)試了很久?,F(xiàn)在直接用\s,表示行末空格和\r。
- 無捕獲分組。為了不對捕獲的分組造成影響,上面的(.\n)可以改為(?:.\n),這樣捕獲分組時,就會忽略它。
- 單括號要進行轉義。因為單括號在正則里是用來表示分組的,所以為了匹配單括號就進行轉義。正則字符串最好用的是帶有r前綴的字符串,如果不是的話,則要對\再進行轉義。
- 快速正則。寫了那么多模式,也總結出一規(guī)律出來。先把要匹配的字符相關的段落拿出來。要匹配的東西用(.?)代替。把換行\(zhòng)n替換為字符串\s\n\s*,再去掉行首行末的空格。整個過程在vim中可以很快就寫好。
Excel操作
這次的數(shù)據(jù)是放進Excel的。到后面才意識到如果放進數(shù)據(jù)庫的話,可能就沒有那么多事了。但是已經(jīng)寫到一半,難以回頭了。
搜索Excel,可以得出幾個方案來,一個是用xlrt/xlwt庫,這個不管電腦上是否安裝了Excel,都可以運行,但只能是xls格式的。還有一個是直接包裝了com,需要電腦上安裝了軟件才行。我采用的是前一種。
基本的讀寫沒有問題。但是數(shù)據(jù)量一大起來,就有問題了。
- 內(nèi)存不夠。程序一跑起來,內(nèi)存占用就一點一點往上漲。后面再查了一下,知道要用flush_row_data。但是還是會出錯。一看內(nèi)存占用,沒有什么問題,一直很平穩(wěn)。但最后還是會出現(xiàn)memory error。這真是見鬼了。又是反復地查, 反復地運行。一點結果都沒有。要命的是bug只在數(shù)據(jù)量大起來才出現(xiàn),而等數(shù)據(jù)量大起來往往要好幾個小時,這debug的成本實在是太高了。一個偶然的機會,突然發(fā)現(xiàn)內(nèi)存占用,雖然總體平穩(wěn),但是會規(guī)律性的出現(xiàn)小的高漲,而這規(guī)律性,會不會和flush_row_data,有關。一直疑惑的是data被flush到了哪里。原來xlwt的作法是很蛋疼的作法。把數(shù)據(jù)存在內(nèi)存里,或者flush到一個temp,到save的時候,再一次性寫入。而問題正出在這一次性寫入,內(nèi)存猛漲。那我要flush_row_data何用?為什么不一開始就flush進要寫入的地方。
- 行數(shù)限制。這個是xls格式本身決定的,最多行數(shù)只能是65536。而且數(shù)據(jù)一大,文件打開也不方便。
結合以上兩點,最終采取了這么一個策略,如果行數(shù)是1000的倍數(shù),進行一次flush,如果行數(shù)超過65536,新開一個sheet,如果超過3個sheet,則新建一個文件。為了方便,把xlwt包裝了一下
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 |
|
轉換網(wǎng)頁特殊字符
由于網(wǎng)頁也有自己獨特的轉義字符,在進行正則匹配的時候就有些麻煩。在官方文檔中查到一個用字典替換的方案,私以為不錯,拿來做了一些擴充。其中有一些是為保持正則的正確性。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
|
結
得出的經(jīng)驗差不多就是這些了。不過最后寫出來的程序自已也不忍再看。風格很不好。一開始想著先寫著試試。然后試著試著就不想改了。
最終的程序要跑很久,其中網(wǎng)絡通信時間占了大部分。是不是可以考慮用多線程重構一下?想想,還是就這樣吧。