Question

字符编码问题

Answer 1

一. Unicode编码， /uff01，四位六进制码

在Java中，String.getBytes(String decode)方法会根据指定的decode编码返回某字符串在该编码下的byte数组表示 ，如

byte[] b_gbk = "中".getBytes("GBK");

byte[] b_utf8 = "中".getBytes("UTF-8");

byte[] b_iso88591 = "中".getBytes("ISO8859-1");

byte[] b_unicode = "中".getBytes("unicode");

将分别返回“中”这个汉字在GBK、UTF-8和ISO8859-1编码下的byte数组表示，此时b_gbk的长度为2，b_utf8的长度为3，b_iso88591的长度为1,b_unicode 的长度为4（系统的的unicode采用的是big-endian就是前面是两个字节来表示这个的，unicode采用的都是两个字节编码，所以后面是4个字节 ）。

而与getBytes相对的，可以通过new String(byte[], decode)的方式来还原这个“中”字时，这个new String(byte[], decode)实际是使用decode指定的编码来将byte[]解析成字符串。

String s_gbk = new String(b_gbk,"GBK");

String s_utf8 = new String(b_utf8,"UTF-8");

String s_iso88591 = new String(b_iso88591,"ISO8859-1");

通过打印s_gbk、s_utf8和s_iso88591，会发现，s_gbk和s_utf8都是“中”，而只有s_iso88591是一个不认识的字符，为什么使用ISO8859-1编码再组合之后，无法还原“中”字呢，其实原因很简单，因为ISO8859-1编码的编码表中，根本就没有包含汉字字符，当然也就无法通过"中".getBytes("ISO8859-1");来得到正确的“中”字在ISO8859-1中的编码值了，所以再通过new String()来还原就无从谈起了。

因此，通过String.getBytes(String decode)方法来得到byte[]时，一定要确定decode的编码表中确实存在String表示的码值，这样得到的byte[]数组才能正确被还原。

有时候，为了让中文字符适应某些特殊要求（如http header头要求其内容必须为iso8859-1 编码），可能会通过将中文字符按照字节方式来编码的情况，如 String s_iso88591 = new String("中".getBytes("UTF-8"),"ISO8859-1")，这样得到的s_iso8859-1字符串实际是三个在ISO8859-1中的字符，在将这些字符传递到目的地后，目的地程序再通过相反的方式String s_utf8 = new String(s_iso88591.getBytes("ISO8859-1"),"UTF-8")来得到正确的中文汉字“中”。这样就既保证了遵守协议规定、也支持中文。

String的getBytes()方法是得到一个字串的字节数组，这是众所周知的。但特别要注意的是，本方法将返回该操作系统默认的编码格式的字节数组。如果你在使用这个方法时不考虑到这一点，你会发现在一个平台上运行． 良好的系统，放到另外一台机器后会产生意想不到的问题。

二. utf-8和Unicode到底有什么区别？是存储方式不同？编码方式不同？它们看起来似乎很相似，但是实际上他们并不是同一个层次的概念

要想先讲清楚他们的区别，首先应该讲讲Unicode的来由。

众所周知，在盘古开天辟地之前,sorry ,走错片场了(⊙o⊙)…在计算机发明的时候 ,由于计算机你只能表示二进制的数据，美帝人民为了交流通信方便，约定了一个编码系统，就是ASCII码，把abc..xyz...ABC...XYZ...!@#...等字符分别和0,1,2,3,4......对应，发现差不多刚好128个数，半个字节的长度，为了防止以后需要为新的符号编码，于是干脆取一个字节，最高位置为0。后七位从0-127分别对每一个符号编码。
于是，计算机每次读取一个字节，然后参照ASCII表把这些编码翻译成字符。美国人民很高兴，拿着自己玩去了.......
后来欧洲人也玩计算机，发现不行啊，还有很多符号（法语，德语）ASCII没办法表示啊，于是欧洲人自己也撸了一套编码，一个字节的长度，把最高位也用掉了。这套编码叫ISO。

和ASCII表类似，计算机也是每次只读一个字节，然后按照ISO表，解码出字符。于是欧洲人民也很高兴。
中国人不高兴了，特么我们汉字有几万个，常用的就有几千个，没有两个字节根本交不了货。于是勤劳勇敢的中国人民就破天荒的用了两个字节来表示中文。整出一套GBK。为了现实我中华民族兼容并蓄，我们兼容了ASCII编码。

gbk编码规定，计算机不能在每次都只读一个字节那么死板了，你要先看看第一位是不是为0，要是为0 的话，就当作ASCII码来读入一个字节，不然的话就读入两个字节。
计算机 : WTF ?? !!
于是天下就很乱了，欧洲人看不懂我们发过去的信息，我们也看不懂他们的东西，美国人看不懂我的东西，不过我们能看懂他们的信息。。。哈哈。

总之，天下大乱，群雄并起，百姓生灵涂........

这个时候，就有个国际组织站出来了，说，这么着吧，我来撸一套编码，把大家的编码都归纳进来。于是unicode编码就出现了。这套编码表的编号从0一直算到了100多万（三个字节）。每一个区间都对应着一种语言的编码。目前几乎收纳了全世界大部分的字符。所有的字符都有唯一的编号，这就解决了解码的冲突，于是天下大定！但是，unicode把大家都归纳进来，却没有为编码的二进制传输和二进制解码做出规定。只留下一句：大哥只能帮你到这里了。

我知道你一定在想，要个毛的规定啊，每次让计算机读取三个字节然后参照Unicode表解码就好了。想法是好的，但是如果类似于1号编码这样的小数据编号也要三个字节的话，那么也就是0x000001,这简直就是浪费啊，明明一个字节就可以表示了，你非得整三个，所以你到底是几个意思呢？

不管怎么样，大哥虽然走了，但是问题还得解决啊，于是，就出现了如下解决方案：uft-8，utf-16，utf-32这些编码方案。utf-16是用两个字节来编码所有的字符，utf-32则选择用4个字节来编码。下面只讲一下utf-8这种解决方案，因为它用的最多，用得最多是因为在当时它的方案最好，最节省资源。

utf-8
utf-8为了节省资源，采用变长编码，编码长度从1个字节到6个字节不等

我知道你想说，明明看起来utf-16更加节省资源，节省空间，正常人都看得出来。但实际上，当时，互联网上绝大部分存在的资源都是英文的，英文在utf-16中也是2个字节，而在utf-8中则是1个字节。在当时，显然是utf-8更加节省资源。现在我们在中文世界里来比较他们，则是utf-16更加节省资源。