网络爬虫的乱码处理
关于爬虫乱码有很多群友的各式各样的问题，下边简单总结下关于网络爬虫的乱码处理。注意，这里不仅是中文乱码，还包括一些如日文、韩文 、俄文、藏文之类的乱码处理，因为他们的解决方式 是一致的，故在此统一说明。
网络爬虫，有两种选择，一是选择nutch、hetriex，二是自写爬虫，两者在处理乱码时，原理是一致的，但前者处理乱码时，要看懂源码后进行修改才可以，所以要废劲一些；而后者更自由方便，可以在编码处理时进行处理。这也是很多人在用框架写爬虫会出现各种各样的乱码时，无从下手的原因了，像比较成熟的nutch在处理乱码时也是比较简单的，所以依然会出现乱码，所以需要二次开发才能真正解决乱码问题。
1、网络爬虫出现乱码的原因
源网页编码和爬取下来后的编码转换不一致。如源网页为gbk编码的字节流，而我们抓取下后程序直接使用utf-8进行编码并输出到存储文件中，这必然会引起乱码，即当源网页编码和抓取下来后程序直接使用处理编码一致时，则不会出现乱码，此时再进行统一的字符编码也就不会出现乱码了。注意区分源网编码A、程序直接使用的编码B、统一转换字符的编码C。
A、就是web page的服务器端编码
B、抓取到的数据，原始情况为字节数组，它是由A来编码的，只有B=A时，才可以保证不出现乱码，否则当字符集不兼容时，总是会出现乱码,此步骤往往用于测试。
C、统一转码是指得到网页的原始编码A后，再进行的统一编码，主要是为了将各个网页的数据统一成一类编码，往往选择字符集较大的utf-8为宜。
每个网页都有自己的编码，像gbk、utf-8、iso8859-1，以及日文的jp系统编码、西欧、俄文等编码各不相同，当进行漫爬时总是会扩展出各种编码，有的爬虫是对web网页进行简单的编码识别再进行统一编码，有的是不做源网页的判断直接统一按utf-8来处理，这显然是会造成乱码情况。
2、乱码的解决方法
根据原因来找解决方法，就非常简单了。
(1) 确定源网页的编码A
编码A往往在网页中的三个位置，http header的content、网页的meta charset中、网页头中Document定义中。在获取源网页编码时，依次判断下这三部分数据即可，从前往后，优先级亦是如此。
理论上这样做是对的，但国内一些网站确是很不符合规范，比如写的gbk，实际是utf-8，有的是写的utf-8，但实际是gbk，当然这是很少的一批网站，但确实存在。所以在确定网页编码时，应该对该特殊情况做特别处理，如中文检查、默认编码等策略。
还有一种情况，是以上三者中均没有编码信息，则一般采用cpdetector等第三方网页编码智能识别工具来做，其原理即为统计字节数组的特征来概率计算得出实际编码，有一定的准确率，但我实际的时候发现，其准确率还是很有限的。
但综合上述的三种编码确认方式后，几乎可以完全解决中文乱码问题，在我基于nutch1.6二次开发的网络爬虫系统中，编码正确经统计可以达到99.99%，也证明了上述方法策略的可行性。
（2）程序通过编码B对源网页数据还原
显然，这里的B是要和A相等的，在java中，如得到的源网页的字节数组为source_byte_array，那么经过转换为String str=new String(source_byte_array,B);即在内存上这些字节数组对应的字符是正确编码和可显示的，此时的打印输出结果是正常的，此步骤往往用于debug或是控制台输出做测试。
（3） 统一转码
网络爬虫系统数据来源很多，不可能使用数据时，再转化为其原始的数据，假使这样做是很废事的。所以一般的爬虫系统都要对抓取下来的结果进行统一编码，从而在使用时做到一致对外，方便使用。此时即是在（2）的基础上，做一个统一的编码转换即可，在java中的实现如下
源网页的字节数组为source_byte_array
转换为正常的字符串： String normal_source_str=new String(source_byte_array,C),此时可以用java api直接存储，但往往不直接写入字符串，因为一般的爬虫存储都是多个源网页存储到一个文件中，所以要记录字节偏移量，故下一步。
再将得到的str转换为统一的编码C格式的字节数组,则byte[] new_byte_array=normal_source_str.getBytes(C)即可，此时即可用java io api将数组写入文件，并记录相应的字节数组偏移量等，待真正使用时，直接io读取即可。