zxing读取中文条码的乱码问题

看来很多人对于中文的乱码其实没有什么理解,我建议搜索一下几种编码的详细说明(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

相关推荐