常用编码方式（android）

一、简介

二、unicode码

  Unicode涉及到两个步骤,首先是定义一个规范,给所有的字符指定一个唯一对应的数字,这完全是数学问题,可以跟计算机没半毛钱关系.第二步才是怎么把字符对应的数字保存在计算机中,这才涉及到实际在计算机中占多少字节空间.
所以我们也可以这样理解,Unicode是用0至65535之间的数字来表示所有字符.其中0至127这128个数字表示的字符仍然跟ASCII完全一样.65536是2的16次方.这是第一步.第二步就是怎么把0至65535这些数字转化成01串保存到计算机中.这肯定就有不同的保存方式了.于是出现了UTF(unicode transformation format),有UTF-8,UTF-16.

2.1 Unicode版本1

2.1.1 UTF-8 、UTF-16

   UTF-16 对应任何字符对应的数字都用两个字节来保存.我们通常对Unicode的误解就是把Unicode与UTF-16等同了.但是如果编码内容英文偏多，使用UTF-16编码，每个字符占用两个字节（16bit）过于浪费。
  UTF-8,这里的8非常容易误导人,8并不是指一个字节,而是表示一个字符是可变的,有可能是用一个字节表示一个字符,也可能是两个,三个…是根据字符对应的数字大小来确定.
  于是UTF-8和UTF-16的优劣很容易就看出来了.如果全部英文或英文与其他文字混合,但英文占绝大部分,用UTF-8就比UTF-16节省了很多空间.而如果全部是中文这样类似的字符或者混合字符中中文占绝大多数.UTF-16就占优势了,可以节省很多空间.

2.1.2.举个例子.

  假如中文字"汉"对应的unicode是6C49(这是用十六进制表示,用十进制表示是27721为啥不用十进制表示呢?很明显用十六进制表示要短点.其实都是等价的没啥不一样.就跟你说60分钟和1小时一样.).你可能会问当用程序打开一个文件时我们怎么知道那是用的UTF-8还是UTF-16啊.自然会有点啥标志,在文件的开头几个字节就是标志.

EF BB BF 表示UTF-8
FE FF 表示UTF-16.

• 用UTF-16表示"汉"
    假如用UTF-16表示的话就是01101100 01001001(共16 bit,两个字节).程序解析的时候知道是UTF-16就把两个字节当成一个单元来解析.这个很简单.
• 用UTF-8表示"汉"
    用UTF-8就有复杂点.因为此时程序是把一个字节一个字节的来读取,然后再根据字节中开头的bit标志来识别是该把1个还是两个或三个字节做为一个单元来处理.UTF-8 转换表表示如下：
  

  0xxxxxxx,如果是这样的01串,也就是以0开头后面是啥就不用管了XX代表任意bit.就表示把一个字节做为一个单元.就跟ASCII完全一样.
  110xxxxx 10xxxxxx.如果是这样的格式,则把两个字节当一个单元
  1110xxxx 10xxxxxx 10xxxxxx 如果是这种格式则是三个字节当一个单元.

  这是约定的规则.你用UTF-8来表示时必须遵守这样的规则.我们知道UTF-16不需要用啥字符来做标志,所以两字节也就是2的16次能表示65536个字符.

  而UTF-8由于里面有额外的标志信息,所有一个字节只能表示2的7次方128个字符,两个字节只能表示2的11次方2048个字符.而三个字节能表示2的16次方,65536个字符.
  由于"汉"的编码27721大于2048了所有两个字节还不够,只能用三个字节来表示.所以要用1110xxxx 10xxxxxx 10xxxxxx这种格式.把27721对应的二进制从左到右填充XXX符号(实际上不一定从左到右,也可以从右到左,这是涉及到另外一个问题.根据填充方式不一样,就出现了Big-Endian,Little-Endian的术语.Big-Endian就是从左到右,Little-Endian是从右到左.
  由上面我们可以看出UTF-8在局部的字节错误（丢失、增加、改变）不会导致连锁性的错误，因为 UTF-8 的字符边界很容易检测出来，所以容错性较高。

2.2 Unicode版本2

  以上都是unicode的第一个版本.但65536显然不算太多的数字,用它来表示常用的字符是没一点问题.足够了,但如果加上很多特殊的就也不够了.于是从1996年开始又来了第二个版本.用四个字节表示所有字符.这样就出现了UTF-8,UTF16,UTF-32.原理和之前完全一样,
  UTF-32就是把所有的字符都用32bit也就是4个字节来表示.
  UTF-8,UTF-16就视情况而定了.UTF-8可以选择1至8个字节中的任一个来表示.
  UTF-16只能是选两字节或四字节…由于unicode版本2的原理完全是一样的,就不多说了.
  具体是哪种编码方式,需要判断文本开头的标志,下面是所有编码对应的开头标志

编码开头标志	对应编码
EF BB BF	UTF-8
FE FF	UF-16/UCS-2, little endian
FF FE	UTF-16/UCS-2, big endian
FF FE 00 00	UTF-32/UCS-4, little endian.
00 00 FE FF	UTF-32/UCS-4, big-endian.

  其中的UCS就是前面说的ISO制定的标准,和Unicode是完全一样的,只不过名字不一样.ucs-2对应utf-16,ucs-4对应UTF-32.UTF-8是没有对应的UCS

2.3 对比分析

2.3.1 UTF-16

• 缺陷

1. UTF-16 能表示的字符数有 6 万多，看起来很多，但是实际上目前 Unicode 5.0 收录的字符已经达到 99024 个字符，早已超过 UTF-16 的存储范围；这直接导致 UTF-16 地位颇为尴尬——如果谁还在想着只要使用 UTF-16 就可以高枕无忧的话，恐怕要失望了
2. UTF-16 存在大小端字节序问题，这个问题在进行信息交换时特别突出——如果字节序未协商好，将导致乱码；如果协商好，但是双方一个采用大端一个采用小端，则必然有一方要进行大小端转换，性能损失不可避免（大小端问题其实不像看起来那么简单，有时会涉及硬件、操作系统、上层软件多个层次，可能会进行多次转换）
3. 另外，容错性低有时候也是一大问题——局部的字节错误，特别是丢失或增加可能导致所有后续字符全部错乱，错乱后要想恢复，可能很简单，也可能会非常困难。（这一点在日常生活里大家感觉似乎无关紧要，但是在很多特殊环境下却是巨大的缺陷）

2.3.2 UTF-8

• 缺陷
     1、文化上的不平衡——对于欧美地区一些以英语为母语的国家 UTF-8 简直是太棒了，因为它和 ASCII一样，一个字符只占一个字节，没有任何额外的存储负担；但是对于中日韩等国家来说，UTF-8 实在是太冗余，一个字符竟然要占用 3个字节，存储和传输的效率不但没有提升，反而下降了。所以欧美人民常常毫不犹豫的采用 UTF-8，而我们却老是要犹豫一会儿
     2、 变长字节表示带来的效率问题——大家对 UTF-8 疑虑重重的一个问题就是在于其因为是变长字节表示，因此无论是计算字符数，还是执行索引操作效率都不高。为了解决这个问题，常常会考虑把 UTF-8 先转换为 UTF-16 或者 UTF-32 后再操作，操作完毕后再转换回去。而这显然是一种性能负担。
• 优点
    1、 字符空间足够大，未来 Unicode 新标准收录更多字符，UTF-8 也能妥妥的兼容，因此不会再出现 UTF-16 那样的尴尬
    2、不存在大小端字节序问题，信息交换时非常便捷
    3、容错性高，局部的字节错误（丢失、增加、改变）不会导致连锁性的错误，因为 UTF-8 的字符边界很容易检测出来，这是一个巨大的优点（正是为了实现这一点，咱们中日韩人民不得不忍受 3 字节 1 个字符的苦日子）

2.3.3如何选择

    无论是 UTF-8 和 UTF-16/32 都各有优缺点，因此选择的时候应当立足于实际的应用场景。在我的习惯中，存储在磁盘上或进行网络交换时都会采用 UTF-8，而在程序内部进行处理时则转换为 UTF-16/32。对于大多数简单的程序来说，这样做既可以保证信息交换时容易实现相互兼容，同时在内部处理时会比较简单，性能也还算不错。
  在一些特殊的领域，字符编码的选择会成为一个很关键的问题。特别是一些高性能网络处理程序里更是如此。这时采用一些特殊的设计技巧，可以缓解性能和字符集选择之间的矛盾。例如对于内容检测/过滤系统，需要面对任何可能的字符编码，这时如果还采用把各种不同的编码都转换为同一种编码后再处理的方案，那么性能下降将会很显著。而如果采用多字符编码支持的有限状态机方案，则既能够无需转换编码，同时又能够以极高的性能进行处理。当然如何从规则列表生成有限状态机，如何使得有限状态机支持多编码，以及这将带来哪些限制，已经又成了另外的问题了。
转自：Unicode(UTF-8, UTF-16)令人混淆的概念

三、Base64

3.1 base64简介

   Base64 ，就是选出64个字符: 小写字母 a-z 、大写字母 A-Z 、数字0-9、符号"+"、"/"（再加上作为垫字的"="，实际上是65个字符）作为一个基本字符集。然后，其他所有符号都转换成这个字符集中的字符。
具体来说，转换方式可以分为四步。

第一步，将每三个字节作为一组，一共是24个二进制位。
第二步，将这24个二进制位分为四组，每个组有6个二进制位。
第三步，在每组前面加一组00，扩展成32个二进制位，即四个字节。
第四步，根据 下面的 base64 编码索引表，得到扩展后的每个字节的对应符号，这就是 Base64 的编码值。

3.1.1 例子

转换前 10101101,10111010,01110110
转换后 00101011, 00011011 ,00101001 ,00110110
十进制 43 27 41 54
对应码表中的值 r b p 2
  所以上面的24位编码，编码后的Base64值为 rbp2
  解码同理，把 rbq2 的二进制位连接上再重组得到三个8位值，得出原码。（解码只是编码的逆过程，有关MIME的RFC还有很多，如果需要详细情况请自行查找。）
  第一个字节，根据源字节的第一个字节处理。
  规则：源第一字节右移两位，去掉低2位，高2位补零。既：00 + 高6位
  第二个字节，根据源字节的第一个字节和第二个字节联合处理。
  规则：第一个字节高6位去掉然后左移四位，第二个字节右移四位即：源第一字节低2位 + 源第2字节高4位
  第三个字节，根据源字节的第二个字节和第三个字节联合处理，
  规则：第二个字节去掉高4位并左移两位（得高6位），第三个字节右移6位并去掉高6位（得低2位），相加即可
  第四个字节，规则，源第三字节去掉高2位即可
  用更接近于编程的思维来说，编码的过程是这样的：第一个字符通过右移2位获得第一个目标字符的Base64表位置，根据这个数值取到表上相应的字符，就是第一个目标字符。然后将第一个字符与0x03(00000011)进行与(&)操作并左移4位,接着第二个字符右移4位与前者相或(|)，即获得第二个目标字符。再将第二个字符与0x0f(00001111)进行与(&)操作并左移2位,接着第三个字符右移6位与前者相或(|)，获得第三个目标字符。最后将第三个字符与0x3f(00111111)进行与(&)操作即获得第四个目标字符。/在以上的每一个步骤之后，再把结果与 0x3F 进行 AND 位操作，就可以得到编码后的字符了。

  原文的字节数量应该是3的倍数，如果这个条件不能满足的话，具体的解决办法是这样的：原文剩余的字节根据编码规则继续单独转(1变2，2变3；不够的位数用0补全)，再用=号补满4个字节。这就是为什么有些Base64编码会以一个或两个等号结束的原因，但等号最多只有两个。因为一个原字节至少会变成两个目标字节，所以余数任何情况下都只可能是0，1，2这三个数中的一个。如果余数是0的话，就表示原文字节数正好是3的倍数（最理想的情况）。如果是1的话，转成2个Base64编码字符，为了让Base64编码是4的倍数，就要补2个等号；同理，如果是2的话，就要补1个等号。
   如果只有两个字节 按照上面的规则，将16位划分为三组，最后一组除了前面加一组00，末尾也加一组00，按照索引表得到编码值后，在末尾加上一个 = .
   如果只有一个字节 按照上面的规则，将8位划分为两组，最后一组除了前面加00，末尾加两组00，按照索引表得到编码值后，在末尾加上两个 = .
参考：百度百科:Base64

3.2 Base64 java 加解密

3.2.1 早期做法

   早期在Java上做Base64的编码与解码，会使用到JDK里sun.misc套件下的BASE64Encoder和BASE64Decoder这两个类别，用法如下：

final BASE64Encoder encoder = new BASE64Encoder();
final BASE64Decoder decoder = new BASE64Decoder();
final String text = "字串文字";
final byte[] textByte = text.getBytes("UTF-8");
//编码
final String encodedText = encoder.encode(textByte);
System.out.println(encodedText);
//解码
System.out.println(new String(decoder.decodeBuffer(encodedText), "UTF-8"));

   从以上程式可以发现，在Java用Base64一点都不难，不用几行程式码就解决了！只是这个sun.mis c套件所提供的Base64功能，编码和解码的效率并不太好，而且在以后的Java版本可能就不被支援了，完全不建议使用。

3.2.1 Java8 操作

   Java 8的java.util套件中，新增了Base64的类别，可以用来处理Base64的编码与解码，用法如下：

final Base64.Decoder decoder = Base64.getDecoder();
final Base64.Encoder encoder = Base64.getEncoder();
final String text = "字串文字";
final byte[] textByte = text.getBytes("UTF-8");
//编码
final String encodedText = encoder.encodeToString(textByte);
System.out.println(encodedText);
//解码
System.out.println(new Strin
g(decoder.decode(encodedText), "UTF-8"));

3.2.2 Apache Commons Codec做法

   Apache Commons Codec有提供Base64的编码与解码功能，会使用到org.apache.commons.codec.binary套件下的Base64类别，用法如下：

final Base64 base64 = new Base64();
final String text = "字串文字";
final byte[] textByte = text.getBytes("UTF-8");
//编码
final String encodedText = base64.encodeToString(textByte);
System.out.println(encodedText);
//解码
System.out.println(new String(base64.decode(encodedText), "UTF-8"));

   以上的程式码看起来又比早期用sun.mis c套件还要更精简，效能实际执行起来也快了不少。缺点是需要引用Apache Commons Codec，很麻烦。

四、ASCII 码

   学过计算机的人都知道 ASCII 码，总共有 128 个，用一个字节的低 7 位表示，0~31 是控制字符如换行回车删除等；32~126 是打印字符，可以通过键盘输入并且能够显示出来。

五、 ISO-8859-1

  　128 个字符显然是不够用的，于是 ISO 组织在 ASCII 码基础上又制定了一些列标准用来扩展 ASCII 编码，它们是 ISO-8859-1~ISO-8859-15，其中 ISO-8859-1 涵盖了大多数西欧语言字符，所有应用的最广泛。ISO-8859-1 仍然是单字节编码，它总共能表示 256 个字符。 GB2312
它的全称是《信息交换用汉字编码字符集 基本集》，它是双字节编码，总的编码范围是 A1-F7，其中从 A1-A9 是符号区，总共包含 682 个符号，从 B0-F7 是汉字区，包含 6763 个汉字。

六、 GBK 《汉字内码扩展规范》

  全称叫《汉字内码扩展规范》，是国家技术监督局为 windows95 所制定的新的汉字内码规范，它的出现是为了扩展 GB2312，加入更多的汉字，它的编码范围是 8140~FEFE（去掉 XX7F）总共有 23940 个码位，它能表示 21003 个汉字，它的编码是和 GB2312 兼容的，也就是说用 GB2312 编码的汉字可以用 GBK 来解码，并且不会有乱码。

七、GB18030 《信息交换用汉字编码字符集》

  全称是《信息交换用汉字编码字符集》，是我国的强制标准，它可能是单字节、双字节或者四字节编码，它的编码与 GB2312 编码兼容，这个虽然是国家标准，但是实际应用系统中使用的并不广泛。