zxing读取中文条码的乱码问题
Litchi 2011-12-12
看来很多人对于中文的乱码其实没有什么理解，我建议搜索一下几种编码的详细说明（GBK，UTF－8,GB2312），我很难简单解释清楚。实际上，几乎所有条码扫描软件都是外国人做的，其实几乎都是只支持UTF8的，或者少数支持韩文日文编码等，似乎都比较无视中国的汉字编码，而且中文的编码本身都比较多，估计外国人也比较头疼。
另外一个条码的短板就是缺少字符编码的定义，所以实际上所有的条码软件都是靠猜编码来显示的，也就是说条码数据读出来的，但是找不到合适的显示方式，那么你看到的就是乱码了，而实际上没有准确的方法可以猜出文字的编码，所以这些软件基本只能读出utf8了，接触过网站或者java开发的人基本上都习惯于用utf8编码，也就是避免出现乱码的原因了，但是大多数国内条码都比较不靠谱的（或者说由于不懂），用了默认的GBK编码，所以你看到包含中文的条码基本也就是乱码了。解决方法，也是用GBK解码就是了，至于由于错误用了utf8解gbk，是无法直接转化为正确的中文的，要么你自己按utf8的编码规则反向解回去，要么修改源码指定编码。
//************************************************************************************
这两天接了一个条码的项目，发现用zxing读取的条码中文部分都是乱码，先和android的项目同事沟通得知中文编码是GBK码，一开始认定是需要从gbk转utf8的问题，g到转换方法，但是死活不行，又试了很多编码都无法解开乱码，搞到11点多，无奈罢手。这几天寒流下来，天气很冷，出门整个人一缩，赶紧拉上拉链。倒霉催的拉链不知道哪里咬住边了，不上不下，加上搞了半天没弄成火气就大，很像一下把它扯下来。我不停对自己说，不要着急不要着急，生气扯坏东西解决不了任何问题，只会变得更遭，慢慢来，它只是一个拉链，不是吗？找了一个亮点的地方查看，外面没有卡住，由于卡紧脖子，没法翻开里面看，靠摸索没法感觉到哪里卡住。我慢慢上下撮把拉链弄开一点，虽然卡的紧，但是又耐心还是可以松开一些，直到可以翻转拉链头，才看到衣服一边的里子已经整个卡进拉链头的两边，难怪摸不出来，慢慢解开拉链，暗示自己，其实很简单的，长时间无法解决问题一般是解决的思路不对，或者忽略了某些可能的方向，找对了方向，问题往往很简单。首先做一个分析：
1 中文是GBK确定无疑
2 GBK转utf8的方法很简单，搜索结果很一致，说明方法没问题，那么问题应该是源字符串那里。
3 zxing默认是转成utf8出来的，可以比对一下转换前后和对应中文的内码
4 怀疑zxing识别内码有问题，需要根据3的结果判定是否着手分析其源码。
第二天通过比对中文各种编码的内码，发现zxing转utf8前的字符流已经和中文的各种内码完全不一样，向上追溯，发现其实zxing解析出条码流时会尝试判别编码，并进而转为utf8，后面再转utf8实际上已经没有必要了，最关键的是zxing其实的iso版其实无法识别GBK，所以做了一次错误的转码，这样转出来的数据，开发者不管怎么再转都无法复原为中文的了。恩，正如炒熟的种子永远无法发芽，如果老是在栽培方式上找问题，是永远无法获得答案的。
综上，正确的方向往往决定你解决问题的效率，冷静的分析问题很重要。附编码列表：
//************************************************************************************
http://hi.baidu.com/zhmsong/blog/item/9e167ffc623e96f5fc037f99.html
European languages
ASCII, ISO-8859-{1,2,3,4,5,7,9,10,13,14,15,16}, KOI8-R, KOI8-U, KOI8-RU, CP{1250,1251,1252,1253,1254,1257}, CP{850,866}, Mac{Roman,CentralEurope,Iceland,Croatian,Romania}, Mac{Cyrillic,Ukraine,Greek,Turkish}, Macintosh
Semitic languages
ISO-8859-{6,8}, CP{1255,1256}, CP862, Mac{Hebrew,Arabic}
Japanese
EUC-JP, SHIFT_JIS, CP932, ISO-2022-JP, ISO-2022-JP-2, ISO-2022-JP-1
Chinese
EUC-CN, HZ, GBK, CP936, GB18030, EUC-TW, BIG5, CP950, BIG5-HKSCS, BIG5-HKSCS:2001, BIG5-HKSCS:1999, ISO-2022-CN, ISO-2022-CN-EXT
Korean
EUC-KR, CP949, ISO-2022-KR, JOHAB
Armenian
ARMSCII-8
Georgian
Georgian-Academy, Georgian-PS
Tajik
KOI8-T
Kazakh
PT154, RK1048
Thai
TIS-620, CP874, MacThai
Laotian
MuleLao-1, CP1133
Vietnamese
VISCII, TCVN, CP1258
Platform specifics
HP-ROMAN8, NEXTSTEP
Full Unicode
UTF-8
UCS-2, UCS-2BE, UCS-2LE
UCS-4, UCS-4BE, UCS-4LE
UTF-16, UTF-16BE, UTF-16LE
UTF-32, UTF-32BE, UTF-32LE
UTF-7
C99, JAVA
Full Unicode, in terms of uint16_t or uint32_t
(with machine dependent endianness and alignment)
UCS-2-INTERNAL, UCS-4-INTERNAL
Locale dependent, in terms of char or wchar_t
(with machine dependent endianness and alignment, and with semantics depending on the OS and the current LC_CTYPE locale facet)
char, wchar_t
When configured with the option --enable-extra-encodings, it also provides support for a few extra encodings:【额外支持：】
European languages
CP{437,737,775,852,853,855,857,858,860,861,863,865,869,1125}
Semitic languages
CP864
Japanese
EUC-JISX0213, Shift_JISX0213, ISO-2022-JP-3
Chinese
BIG5-2003 (experimental)
Turkmen
TDS565
Platform specifics
ATARIST, RISCOS-LATIN1
