Python编码检测 chardet 效果不如 UnicodeDammit

实际例子还是上一篇文章的

http://www.angenechemical.com/productshow/AGN-PC-0JCLT7.html

在scrapy中，记录下response的body的时候，self.logger.error(response.body) 会报无数的错

经过手工尝试 

decode("gbk"), 

decode("gb2312"), 

encode("utf-8").strip()

都不行后，最后尝试出了, decode("windows-1252") 有效，编码是windows-1252

为此甚至还更改了 logging模块emit的源码。因为logging的emit 直接上来就是stram.write(fs%msg)  不行的话再来encode("utf-8")

那么如果其他不能encode("utf-8")的时候，还是需要先一步 decode(编码的)

在这里引入 chardet 检测结果是

import chardet
print "detect charset : "+str(chardet.detect(msg))
detect charset : {'confidence': 0.99, 'language': 'Chinese', 'encoding': 'GB2312'

很明显，chardet 给出的gb2312 是明显错误的，因为我们decode("gb2312") 一样会出错不成功。

引入 UnicodeDammit 检测，

from bs4 import UnicodeDammit
dammit = UnicodeDammit(msg)
print "dammit.original_encoding", dammit.original_encoding
dammit.original_encoding windows-1252

UnicodeDammit　给出电费windows-1252 毫无疑问是正确的结果，我们预期的结果

关于UnicodeDammit， UnicodeDammit 是bs4里面的(哈哈哈...没想到bs4还有这个大杀器)，为什么UnicodeDammit这么好用，因为UnicodeDammit 已经综合考虑了chardet 的结果，

chrdet 是学习了大量的文本，然后再来算出最有可能的编码方式

UnicodeDammit 是

1. 先从申明的编码方式尝试解析

2. 尝试从开头的几个字符开始解析

3. chardet 检测出来的推荐编码

4. utf-8 解析

5. windows-1252 解析

使用 UnicodeDammit 的同时，其实也经过了chardet的检测，同时它还加上了windows-1252的尝试解析，如果连windows-1252解析还无效的话，那就真没救了~~~

UnicodeDammit 文档：https://www.crummy.com/software/BeautifulSoup/bs4/doc/#unicode-dammit

编码说明：

https://stackoverflow.com/questions/436220/determine-the-encoding-of-text-in-python