告别乱码，针对GBK、UTF-8两种编码的智能URL解码器的java实现（转）

效果图

---

 

 

字符

---

字符是早于计算机而存在，从人类有文明那时起，人们就用一个个符号表明世间万象。如ABC，如“1、2、三”。

字符集

---

字符集是全部字符的集合。

 

XXX字符集

---

给字符集中的每个字符套上一个序号后的字符集。常见的XXX字符集有ASCLL字符集、Unicode字符集等等，不一样种字符集为每一个字符编的序号不一样，包含的字符数量也不一样。

GBK、UTF-8

---

　　GBK、UTF-8是一种编码编码格式。固然，你也能够说unicode是一种编码格式，由于它的的确确为每一个字符编了一个码，没错，但是unicode的编码彻底没有规律，最多只能把其当映射表用。

　　咱们知道，计算机只能识别1和0，假如计算机存储中文字符“字”在硬盘，确定是存储一串二进制串。

　　那么问题来了，中文字符【字】在unicode字符集中的序号是23383，那么直接把23383转化成2进制为101101101010111，而后存储在计算机里面，等须要的时候把101101101010111串拿出来，转成23383，再根据unicode映射表，找到中文字符【字】不就好吗？

　　答案是否认的，若是是这样的话，那计算机怎么知道多少个一、0才表明一个字符呢？因此咱们须要一种编码格式，把23383编码成有规律的一、0串，以便计算机读取。

　　而GBK和UTF-8即是两种不一样的有规则的编码格式。

　　例如：以UTF-8为例子，假如咱们所在的环境使用的是unicode字符集，那么“字”在unicode字符集中的序号是23383，转成二进制是101101101010111，使用UTF-8为其编码，以一种特定的算法（下面会具体讲这种算法），把101101101010111转化成11100101 10101101 10010111三个字节的二进制串，再存储到硬盘中，计算机在读取的时候，假如咱们指定了让计算机以UTF-8编码格式读取并解码，计算机就会把这三个字节拿出来，倒着转回去，就能获得【字】这个中文字符了。

乱码的根源：

假如咱们存储的时候，使用GBK编码格式编码，存储到硬盘，而从硬盘读取出来后，在“倒着转回去”这个步骤却使用UTF-8编码格式转回去，算法不一样，那么就可能出现乱码。

如何避免乱码：

以什么编码格式存储，就用什么编码格式解。

可是，假如用户A使用GBK编码对“字”进行编码，而用户B并不知情，也没A的联系方式，跟A约定不了，没法得知硬盘中的数据是以什么编码格式编码的，怎么办呢？

解决乱码的思路：

一、随意使用一种编码格式解码，看解码后的字符串是否乱码，若是是乱码，就用另外一种编码格式解码。但该方法可能误判。

二、UTF-8编码格式有必定的规律，咱们能够经过正则表达式来验证是不是通过UTF-8编码后的。

 

JAVA自带检测乱码

---

 

1  boolean b = java.nio.charset.Charset.forName("GBK").newEncoder().canEncode(str);

 

当开始接触这种方法时，原觉得java能帮咱们判断乱码，就能够高枕无忧了，后来发现，该方法的成功率并不高。

但咱们能够先用此方法作第一步检测，若是判断不出来，再使用第2种方法。

 

UTF-8的编码规律

---

UTF-8形式的二进制，当一个字节时，两个字节时，3、4、5、六个字节时，都有必定的格式：

1字节	0xxxxxxx
2字节	110xxxxx 10xxxxxx
3字节	1110xxxx 10xxxxxx 10xxxxxx
4字节	11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
5字节	111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
6字节	111111x0 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

很明显，字节数不同的话，第一个字节是不一样的，因此第一个字节可用用来表示该字符究竟占用了多少个字节。

当计算机读取到以0xxxxxxx开头的字节，那么就表明这个字节独自就已经表示某个字符了，计算机将把这个字节单独拿出来解码。

当计算机读取到以110xxxxx开头的字节，那么就表明两个字节才能表示某个字符，计算机就把这个字节以及它后面的一个字节拿出来，表明一个字符进行解码。

……

而除了第一个字节外，后面的字节都是统一的10xxxxxx格式。

有了上面的有规则的格式，按到理咱们就可使用正则表达式来检测一个二进制串是不是UTF-8编码后的串，但代码中操做二进制并不方便，结合URL为16进制的特色，咱们能够用正则表达式判断16进制的串。

 

如何构造正则表达式

---

 

咱们先看看这种编码格式前一个字节的范围：

	二进制	十六进制
1字节	00000000~01111111	00~7f
2字节	11000000~11011111	c0~df
3字节	11100000~11101111	e0~df
4字节	11110000~11110111	f0~f7
5字节	11111000~11111011	f8~fb
6字节	11111100~11111101	fc~fd

以上的范围可用计算机自行验证：

后面格式相同的字节10xxxxxx的范围：

10000000~10111111

80~bf

按照这种格式，UTF-8编码格式最多可用用来表示一个1+5*6=31位的二进制串，共使用6个字节。

按照这种规律，咱们先练一下手，尝试把“字”转化为UTF-8的十六进制：

java使用的字符集是unicode的，因此咱们以unicode为例子。

一、找出“字”在unicdoe字符集中的序号：

?

1 2 3

public static void main(String[] args) { System.out.println(( int ) '字' ); }

结果为：23383

2、把23383转化二进制：　　

23383

101101101010111

可用看出，二进制共15位，按照UTF-8的编码格式，得用3个字节来表示。

咱们把101101101010111从后往前分红三组：101，101101，010111

填充到3字节的UTF-8编码格式中为：

1110xxxx 10xxxxxx 10xxxxxx

11100101 10101101 10010111

3、使用计算器把二进制转化为16进制为：

OxE5 OxAD Ox97

4、使用网上的工具验证一下，结果吻合，说明这种规律是正确的。

 

 

上面已经介绍了UTF-8的规律，那么咱们借助强大的正则表达式，就能够判断一个URL串是通过什么编码格式编码的了。

先把上面的表复制下来容易观察：

	二进制	十六进制
1字节	00000000~01111111	00~7f
2字节	11000000~11011111	c0~df
3字节	11100000~11101111	e0~df
4字节	11110000~11110111	f0~f7
5字节	11111000~11111011	f8~fb
6字节	11111100~11111101	fc~fd

1字节时：[\\x00-\\x7f]---------------------------------1

2字节时：[\\xc0-\\xdf][\\x80-\\xbf]-------------------2

3字节时：[\\xe0-\\xef][\\x80-\\xbf]{2}--------------3

4字节时：[\\xf0-\\xf7][\\x80-\\xbf]{3}--------------4

5字节时：[\\xf8-\\xfb][\\x80-\\xbf]{4}--------------5

6字节时：[\\xfc-\\xfd][\\x80-\\xbf]{5}--------------6

使用或组合在一块儿就是：^([\\x00-\\x7f]|[\\xc0-\\xdf][\\x80-\\xbf]|[\\xe0-\\xef][\\x80-\\xbf]{2}|[\\xf0-\\xf7][\\x80-\\xbf]{3}|[\\xf8-\\xfb][\\x80-\\xbf]{4}|[\\xfc-\\xfd][\\x80-\\xbf]{5})+$

判断过程是这样子的：例如【字】通过UTF-8编码后，为：%e5 %ad %97，共3个字节，符合第3字节的状况，第一个字节e5在[\\xe0-\\xef]范围内，后两个字节ad和97都在[\\x80-\\xbf]范围内。

因此咱们能够说这个字符是通过UTF-8编码的。咱们就可使用UTF-8编码格式对其进行解码了。

java代码以下：

1     protected static final Pattern utf8Pattern = Pattern.compile("^([\\x00-\\x7f]|[\\xc0-\\xdf][\\x80-\\xbf]|[\\xe0-\\xef][\\x80-\\xbf]{2}|[\\xf0-\\xf7][\\x80-\\xbf]{3}|[\\xf8-\\xfb][\\x80-\\xbf]{4}|[\\xfc-\\xfd][\\x80-\\xbf]{5})+$");
2                 Matcher matcher = utf8Pattern.matcher(pureValue);
3                 if (matcher.matches()) {
4                     return "UTF-8";
5                 } else {
6                     return "GBK";
7                 }

 

缺陷

---

　　使用上面的方法，貌似没什么问题，不过GBK编码后是以两个两个字节呈现的，而UTF-8也有两个字节的状况，因此当一个字符经GBK编码后，转化为16进制，而恰好这个16进制的范围落入UTF-8的两个字节的范围，那么就会被误判成UTF-8，从而致使解码错误。那真的有可能会出现这种状况吗？

答案是会的，咱们查看下GBK简体中文编码表。

发现有一部分范围落入了UTF-8的二进制范围了。

从：

一直到：

即UTF-8十六进制中两个字节的范围[\\xc0-\\xdf][\\x80-\\xbf]，GBK都有。

例如上面表的第二个中文【愧】，愧的GBK十六进制是C0 A0，那么彻底符合UTF-8正则表达式中二字节的[\\xc0-\\xdf][\\x80-\\xbf]这个判断，因此会被误认为是UTF-8编码。

注：该缺陷第一次看，是在下方“参考"的第一篇博客里，尝试了一下，的确有缺陷。

 

尝试修复缺陷

---

根据下面"参考"的第一篇博客，修复的思路是把重复的区域都认为是GBK编码。

咱们截取正则表达式的前两种状况（一字节、二字节的状况）来排除：^([\\x01-\\x7f]|[\\xc0-\\xdf][\\x80-\\xbf])+$

假如某个16进制串match该正则表达式，就认为是GBK编码的。

修改后的代码为：

 1     protected static final Pattern utf8Pattern = Pattern.compile("^([\\x01-\\x7f]|[\\xc0-\\xdf][\\x80-\\xbf]|[\\xe0-\\xef][\\x80-\\xbf]{2}|[\\xf0-\\xf7][\\x80-\\xbf]{3}|[\\xf8-\\xfb][\\x80-\\xbf]{4}|[\\xfc-\\xfd][\\x80-\\xbf]{5})+$");
 2     protected static final Pattern publicPattern = Pattern.compile("^([\\x01-\\x7f]|[\\xc0-\\xdf][\\x80-\\xbf])+$");
 3 Matcher publicMatcher = publicPattern.matcher(str);
 4                 if(publicMatcher.matches()) {
 5                     return "GBK";
 6                 }
 7                 
 8                 Matcher matcher = utf8Pattern.matcher(str);
 9                 if (matcher.matches()) {
10                     return "UTF-8";
11                 } else {
12                     return "GBK";
13                 }

 

又一缺陷

---

但这样一来，本来是一个字节或两字节，且是UTF-8编码的，就会被误判为GBK。。。

可是，这总比被误判成UTF-8好，由于咱们查看Unicode编码表：

能够发现，第一个中文是“一”，转化为UTF-8的话已经排到3个字节去了，因此2个字节内不会出现中文。

可是GBK中，中文是两个字节的。

因此，采用上面的修复缺陷的方法，能够保证中文不会乱码。对于某些网站，只需保证中文不会乱码便可，好比说国内的各类中文购物网站。这些网站中商品的标题通常都是中文的，用户通常以中文搜索，咱们尽量保证中文不乱码便可。

因此，该技术仍是有必定用处的。

 

参考

---

一、http://www.cnblogs.com/chengmo/archive/2011/02/19/1958657.html

二、http://www.cnblogs.com/chengmo/archive/2010/10/30/1864004.html

三、unicode编码表

四、GBK简体中文表

http://www.cnblogs.com/xiaoMzjm/p/4648175.html