爬蟲亂碼處理方法

1、亂碼的解決方法根據(jù)原因來找解決方法，就非常簡單了。(1)確定源網(wǎng)頁的編碼A編碼A往往在網(wǎng)頁中的三個位置，httpheader的content、網(wǎng)頁的metacharset中、網(wǎng)頁頭中Document定義中。在獲取源網(wǎng)頁編碼時，依次判斷下這三部分數(shù)據(jù)即可，從前往后，優(yōu)先級亦是如此。理論上這樣做是對的，但國內(nèi)一些網(wǎng)站確是很不符合規(guī)范，比如寫的gbk，實際是utf-8，有的是寫的utf-8，但實際是gbk，當然這是很少的一批網(wǎng)站，但確實存在。所以在確定網(wǎng)頁編碼時，應該對該特殊情況做特別處理，如中文檢查、默認編碼等策略。還有一種情況，是以上三者中均沒有編碼信息，則一般采用cpdetector等第三方網(wǎng)頁編碼智能識別工具來做，其原理即為統(tǒng)計字節(jié)數(shù)組的特征來概率計算得出實際編碼，有一定的準確率，但我實際的時候發(fā)現(xiàn)，其準確率還是很有限的。但綜合上述的三種編碼確認方式后，幾乎可以完全解決中文亂碼問題，在我基于nutch1.6二次開發(fā)的網(wǎng)絡爬蟲系統(tǒng)中，編碼正確經(jīng)統(tǒng)計可以達到99.99%，也證明了上述方法策略的可行性。（2）程序通過編碼B對源網(wǎng)頁數(shù)據(jù)還原顯然，這里的B是要和A相等的，在java中，如得到的源網(wǎng)頁的字節(jié)數(shù)組為source_byte_array，那么經(jīng)過轉(zhuǎn)換為Stringstr=newString(source_byte_array,B);即在內(nèi)存上這些字節(jié)數(shù)組對應的字符是正確編碼和可顯示的，此時的打印輸出結(jié)果是正常的，此步驟往往用于debug或是控制臺輸出做測試。（3）統(tǒng)一轉(zhuǎn)碼網(wǎng)絡爬蟲系統(tǒng)數(shù)據(jù)來源很多，不可能使用數(shù)據(jù)時，再轉(zhuǎn)化為其原始的數(shù)據(jù)，假使這樣做是很廢事的。所以一般的爬蟲系統(tǒng)都要對抓取下來的結(jié)果進行統(tǒng)一編碼，從而在使用時做到一致對外，方便使用。此時即是在（2）的基礎上，做一個統(tǒng)一的編碼轉(zhuǎn)換即可，在java中的實現(xiàn)如下源網(wǎng)頁的字節(jié)數(shù)組為source_byte_array

轉(zhuǎn)換為正常的字符串：

Stringnormal_source_str=newString(source_byte_array,C),此時可以用javaapi直接存儲，但往往不直接寫入字符串，因為一般的爬蟲存儲都是多個源網(wǎng)頁存儲到一個文件中，所以要記錄字節(jié)偏移量，故下一步。再將得到的str轉(zhuǎn)換為統(tǒng)一的編碼C格式的字節(jié)數(shù)組,則byte[]new_byte_array=normal_source_str.getBytes(C)即可，此時即可用javaioapi將數(shù)組寫入文件，并記錄相應的字節(jié)數(shù)組偏移量等，待真正使用時，直接io讀取即可。一，通過httpheader中的content_type中的charset來獲得，該編碼是最準確的。二，通過得到源網(wǎng)頁的meta的charset來獲得編碼。三，通過智能探測，如cpdetector，它是目前口碑最好的java實現(xiàn)的智能探測編碼，是基于統(tǒng)計實現(xiàn)的，所以注定會有一定的錯誤率，經(jīng)過我的實測，若干特殊網(wǎng)頁，它確實是不準確的，如網(wǎng)頁的meta中charset和實際的瀏覽器識別的正常顯示的charset不相同的情況，它的識別也是錯誤的，所以最后我堅決沒用它，而用了基于簡單規(guī)則的方式，實際測試1000個種子網(wǎng)址證明，沒發(fā)現(xiàn)任何亂碼，除了一個站點它自身是亂碼之外。重點說下亂碼的解決策略：一、首先讀取httpheader中的content_type的charset,如果有，則認定該charset是肯定準確的，直接做為解碼的編碼格式即可。

二、再按系統(tǒng)默認編碼即UTF-8，去按行讀取源網(wǎng)頁中的meta和title的值，由于這兩個值均為英文標簽，所以在獲取時肯定不會受到亂碼的影響，故可以按UTF-8方式準確獲取charset和title的值，此時的title有可能是亂碼。三、由于有不少中文站點中，雖然meta中的charset顯示的是utf-8或是GBK，但實際的瀏覽器解析到的正常編碼正好相反為gbk或是UTF-8，面對這種特例，而又發(fā)現(xiàn)只有在國內(nèi)的站點會有如此情況，故做規(guī)則如下：（1）首先判斷此時的title若均為標點、字母、數(shù)字、中英文符號、GB18030的中文字符等，則認為此次的默認編碼就是源網(wǎng)頁的實際編碼，而不管獲得的charset是怎樣的，并將charset設成為系統(tǒng)的默認編碼utf-8。（2）如果title滿足第(1)條件，則用得到的charset去解碼原始的字節(jié)流(如果charset就是utf-8，則省略后一步，直接將該charset作為實際的編碼處理，即utf-8，原因在于很多俄文、西里爾文的標題多是UTF-8編碼，但均不屬于中文行列）。并獲取新解析出來的源網(wǎng)頁字符串的title。此時的新解碼的charset即為最終的源網(wǎng)頁認定的charset。解碼完成后，在保存源網(wǎng)頁的實際數(shù)據(jù)時，先對得到的原始字節(jié)數(shù)組按上一步得到的charset解碼，即Stringsource_webpage_string=newString(original_byte_array,charset);此時得到的source_webpage_string即為正常的源網(wǎng)頁中，再進行重編碼：new_byte_array=source_webpage_string.getBytes(system.defaultEncoding);//即utf-8再用utf-8對正常的串進行編此時得到的source_webpage_string即為正常的源網(wǎng)頁中，再進行重編碼：new_byte_array=source_webpage_string.getBytes(system.defaultEncoding);//即utf-8再用utf-8對正常的串進行編碼，得到統(tǒng)一編碼下的字節(jié)數(shù)組，通過javaio寫入到即定的大文件中即可。當然如果charset值就是默認的utf-8，則無需解碼，直接存儲即可。有人會問為何要先解碼？答案是：解碼是為了統(tǒng)一編碼。做為爬蟲系統(tǒng)，會有來自成千上萬個站點的網(wǎng)頁存儲到系統(tǒng)中，而網(wǎng)頁的編碼有很多，像GBK、Unicode、big5、shift-js、windows-1521等等，如果直接存儲而不統(tǒng)一編碼在應用端讀取的時候，就要讀出字節(jié)數(shù)組后按原始的編碼解析才能得到非亂碼顯示，到視圖端顯示的時候也要如此轉(zhuǎn)化，顯然這樣