效果图html
字符java
字符是早于计算机而存在,从人类有文明那时起,人们就用一个个符号表明世间万象。如ABC,如“1、2、三”。正则表达式
字符集算法
字符集是全部字符的集合。工具
XXX字符集网站
给字符集中的每个字符套上一个序号后的字符集。常见的XXX字符集有ASCLL字符集、Unicode字符集等等,不一样种字符集为每一个字符编的序号不一样,包含的字符数量也不一样。编码
GBK、UTF-8spa
GBK、UTF-8是一种编码编码格式。固然,你也能够说unicode是一种编码格式,由于它的的确确为每一个字符编了一个码,没错,但是unicode的编码彻底没有规律,最多只能把其当映射表用。.net
咱们知道,计算机只能识别1和0,假如计算机存储中文字符“字”在硬盘,确定是存储一串二进制串。3d
那么问题来了,中文字符【字】在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字符集中的序号:
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
四、GBK简体中文表
若有错误的地方,欢迎指出。