1.编码的产生：我们的存储的基本单元是一个byte字节，然而人类的语言太多，无法用一个基本单元来表示，然而为了拆分或者一些相应的翻译工作，导致了编码的产生
2.常见的编码格式
ASCll ：用一个字节的低7位共128个来表示，0-31表示控制字符，32-126表示打印字符， ASCll的二进制第一位也就是最高位，目的是用来做奇偶检验的，所谓奇偶校验，是指在代码传送过程中用来检验是否出现错误的一种方法，一般分奇校验和偶校验两种。奇校验规定：正确的代码一个字节中1的个数必须是奇数，若非奇数，则在最高位添1；偶校验规定：正确的代码一个字节中1的个数必须是偶数，若非偶数，则在最高位添1；看到这是似乎对奇偶检验还是较为模糊，不大明白，例如字母A的ASCII码为1000001,若使用偶校验的结果是：01000001，奇检验的结果是11000001；奇偶检验是事先设定好了的，当CPU读取存储的数据时，它会再次把前8位中存储的数据相加，计算结果是否与校验位相一致。从而一定程度上能检测出内存错误，奇偶校验只能检测出错误而无法对其进行修正，同时虽然双位同时发生错误的概率相当低，但奇偶校验却无法检测出双位错，检验到错误的时候，接收数据方就会要求发送方重新传数据
范例：
串行数据在传输过程中，由于干扰，可能使位变为1，(为什么不变0?脉冲)这种情况，称为出现了"误码"。传输中的错误，叫"检错"。发现错误后消除错误叫"纠错"。最简单的检错方法是"奇偶校验"，一般在同步传输方式中常采用奇校验，而在异步传输方式中常采用偶校验
ISO-8859-1：由于128字符不够用，于是ISO组织在ASCll的基础上制定一系列的标准来拓展ASCll编码（ISO-8859-1~ISO-8859-15），ISO-8859-1也是作为java web中默认的解析方式
GB2312:全称是《信息交换用汉字编码字符奇基本集》，占两个字节，其中A1~A9是符号区，B0~F7是汉字区
GBK：全称《汉字内码拓展规范》，是对GB2312的拓展，它的编码是与GB2312相兼容的，也就是说用GB2312编码的汉字可以用GBK来编码而不会乱码
GB18030:我国强制标准，可能是单字节 双字节 四个字节，与GB2312编码是兼容的，我国标准，但是使用并不广泛
UTF-16：定义了Unicode（世界上所有的语言都可以用这本字典来相互翻译，是java和xml的基础）在计算机中的存取方法，用两字节来表示Unicode的转换格式，在表示上相对来说简单方便，但是相对于UTF-8来内存空间增大了很多
UTF-8：对每个编码区域有不同的字码长度，不同类型字符可以有1-6个字节组成
UTF-8的编码原则：
如果是一个字节，最高位为0，
如果一个字节以11开头，表示相应的首字节
如果以10开始，则表示他不是首字节，需要向前查找才能得到当前字符的首字符
例如：
1字节 0xxxxxxx
2字节 110xxxxx 10xxxxxx
3字节 1110xxxx 10xxxxxx 10xxxxxx
4字节 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
5字节 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
6字节 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
说明：UTF-8用来表示字符编码的实际位数最多有31位，即上表中x所表示的位。除去那些控制位（每字节开头的10等），这些x表示的位与UNICODE编码是一一对应的，位高低顺序也相同。 将UNICODE转换为UTF-8编码时应先去除高位0，然后根据所剩编码的位数决定所需最小的UTF-8编码位数（ASCll标准编码为7位）。
3.本地io流的编解码
1)乱码的原因
文件的传输时使用二进制数传输（备注：字符的显示是经过相应的转换之后得到的结果），在转换成二进制的过程中具有编码和解码两个过程，编码与解码一致那么就不会乱码，假如不一致就会乱码。例如传入的文件java默认使用的是gbk解码，而我们原本使用的是utf8编码，那么在解码的时候会相应的乱码。
2）解决方法
a）在知道原文件的编码的情况下
InputStreamReader isr = new InputStreamReader(new FileInputStream(""),"utf-8");
b）在不知道编码的情况下获取本地文件的编码方法如下
//简写EncodingDetect的使用方法
String pathname = "F:/test/file1/file2.txt"; //获取编码格式 String encode = EncodingDetect.getJavaEncode(pathname);
System.out.println(encode);
EncodingDetect.readFile(pathname, encode);
c）在不知道编码的情况下获取网络文件的编码方法如下
public static String getFileEncode(String path) {
/*
* detector是探测器，它把探测任务交给具体的探测实现类的实例完成。
* cpDetector内置了一些常用的探测实现类，这些探测实现类的实例可以通过add方法 加进来，如ParsingDetector、
* JChardetFacade、ASCIIDetector、UnicodeDetector。
* detector按照“谁最先返回非空的探测结果，就以该结果为准”的原则返回探测到的
* 字符集编码。使用需要用到三个第三方JAR包：antlr.jar、chardet.jar和cpdetector.jar
* cpDetector是基于统计学原理的，不保证完全正确。
*/
CodepageDetectorProxy detector = CodepageDetectorProxy.getInstance();
/*
* ParsingDetector可用于检查HTML、XML等文件或字符流的编码,构造方法中的参数用于
* 指示是否显示探测过程的详细信息，为false不显示。
*/
detector.add(new ParsingDetector(false));
/*
* JChardetFacade封装了由Mozilla组织提供的JChardet，它可以完成大多数文件的编码
* 测定。所以，一般有了这个探测器就可满足大多数项目的要求，如果你还不放心，可以
* 再多加几个探测器，比如下面的ASCIIDetector、UnicodeDetector等。
*/
detector.add(JChardetFacade.getInstance());// 用到antlr.jar、chardet.jar
// ASCIIDetector用于ASCII编码测定
// detector.add(ASCIIDetector.getInstance());
// UnicodeDetector用于Unicode家族编码的测定
// detector.add(UnicodeDetector.getInstance());
java.nio.charset.Charset charset = null;
URL url=null;
try {
url = new URL(path);
} catch (MalformedURLException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
try {
charset = detector.detectCodepage(url);
} catch (Exception ex) {
ex.printStackTrace();
}
if (charset != null)
return charset.name();
else
return null;
};
备注：本地文件可以使用EncodingDetect jar包来获取文件的编码，利用统计学得出的结论，并不是百分百正确，但是准确率在百分之99以上，网络爬虫可以使用cpdetector_1.0.10.jar*，基于统计学。
4.mysql数据库乱码
解决方法：如下
useUnicode=true&characterEncoding=utf8&characterSetResults=utf8 //需要与数据的编码集一致，否则可能插入出错（例如数据库是latin1,而我们设置的utf-8），数据库的字符集可以设置也可以查看。（mysql数据库中）
含义如下：本质：useUnicode=true&characterEncoding=utf- 8的作用是指定character_set_client和character_set_connection的值，characterSetResults=utf8对应character_set_results
5.web乱码
1）post请求方式乱码
原因：默认使用的iso-8859-1解析，导致乱码//客户端需要与服务器端保持编解码一致
解决方法：采用request.setcharacter（“utf-8”）（request.setCharacterEncoding()是在接受数据之后进行相应的解码），或者是response.setcharacter（“utf-8”）,也可是以response.setContentType("text/json; charset=UTF-8")来解决，可以使用拦截器拦截设置编码；
a)基于配置的springframework内置拦截器如下,需要放在所有的拦截的最前面，防止在正确解码前以及被解码导致乱码
<filter>
<filter-name>characterEncodingFilter</filter-name>
<filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>utf-8</param-value>
</init-param>
<init-param>
<param-name>forceRequestEncoding</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>forceResponseEncoding</param-name>
<param-value>true</param-value>
</init-param>
</filter>
b)在spring中不基于配置的方式配置拦截器如下
在类路径下建立meta-inf文件夹，然后新建services，然后建立一个文件（javax.servlet.ServletContainerInitializer），在文件中写下全类名（cn.test.config.MainConfig）
package cn.test.config;
import org.springframework.web.filter.CharacterEncodingFilter;
import javax.servlet.*;
import javax.servlet.annotation.HandlesTypes;
import java.util.EnumSet;
import java.util.Set;
public class MainConfig implements ServletContainerInitializer {
@Override
public void onStartup(Set<Class<?>> c, ServletContext ctx) throws ServletException {
// characterEncodingFilter添加拦截器
FilterRegistration.Dynamic characterEncodingFilter = ctx.addFilter("characterEncodingFilter", CharacterEncodingFilter.class);
characterEncodingFilter.setInitParameter("encoding","utf-8");
characterEncodingFilter.setInitParameter("forceRequestEncoding", "true");
characterEncodingFilter.setInitParameter("forceResponseEncoding","true");
characterEncodingFilter.addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST),true,"/*");
}
}
2）get请求方式乱码（post的解决方法对get无效）
原因：对于get方法表单提交的内容在URL解析开始时就已经解码，所以setCharacterEncoding()无效。
解决方法：
在Tomcat的server.xml中的:
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" URIEncoding="GBK" />