服务器Servlet层接收中文参数，使用new String(getBytes(ISO-8859-1),UTF-8)中文编码避免乱码

服务器Servlet层接收中文参数，使用new String(getBytes(ISO-8859-1),UTF-8)中文编码避免乱码

下文转载自：https://blog.csdn.net/qq_28863045/article/details/79503945

new String(getBytes(ISO-8859-1),UTF-8)来避免乱码，当然UTF-8可以换成GBK，unicode。

tomcat默认全部都是用ISO-8859-1编码,不管你页面用什么显示,Tomcat最终还是会替你将所有字符转做ISO-8859-1.那么,当在另目标页面再用GBK翻译时就会将本来错的编码翻译成GBK的编码,这时的文字会乱码. 

所以需要先将得到"字符"(不管是什么)都先用字节数组表示,且使用ISO-8859-1进行翻译,得到一个在ISO-8859-1编码环境下的字节数组.例如:AB表示成[64,65].然后再用GBK编码这个数组,并翻译成一个字符串.

在Java中，String的getBytes()方法是得到一个操作系统默认的编码格式的字节数组。这个表示在不同情况下，返回的东西不一样！ String.getBytes(String decode)方法会根据指定的decode编码返回某字符串在该编码下的byte数组表示，

1.  
   String s_gbk = new String(b_gbk,"GBK");
2.  
   String s_utf8 = new String(b_utf8,"UTF-8");
3.  
   String s_iso88591 = new String(b_iso88591,"ISO8859-1");
4.  
   String s_unicode = new String(b_unicode, "unicode");

将分别返回“深”这个汉字在GBK、UTF-8、ISO8859-1和unicode编码下的byte数组表示，此时b_gbk的长度为2，b_utf8的长度为3，b_iso88591的长度为1，unicode为4。     而与getBytes相对的，可以通过new String(byte[], decode)的方式来还原这个“深”字时，这个new String(byte[], decode)实际是使用decode指定的编码来将byte[]解析成字符串。

1.  
   byte[] b_gbk = "深".getBytes("GBK");
2.  
   byte[] b_utf8 = "深".getBytes("UTF-8");
3.  
   byte[] b_iso88591 = "深".getBytes("ISO8859-1");
4.  
   byte[] b_unicode = "深".getBytes("unicode");

通过打印s_gbk、s_utf8、s_iso88591和unicode，会发现，s_gbk、s_utf8和unicode都是“深”，而只有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编码）和tomcat中全部用ISO-8859-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(String decode)方法会根据指定的decode编码返回某字符串在该编码下的byte数组表示

这里是encode ，not decode，从字符串到字节数组是编码的过程，从字节数组到字符串（即 new String（byte[] , charsetname））才是解码的过程，byte[]中存的才是码

那么我们可以得到一个编码转换的过程 
假设:GBK码("你")->URLencode后变成->(%3F%2F)->Tomcat自动替你转一次ISO-8859-1->得到字符串( 23 43 68 23 42 68 每一个符号表示为ISO-8859-1中的一个编码)->接收页面--->再转一次为ISO-8859-1的Byte数组[23,43,68,23,42,68]--->用GBK再转为可读的文字--->(%3F%2F"---->转为("你")     =>即为new String(getBytes(ISO-8859-1),UTF-8)

除了UTF-16，其它字符集定义时都重复。
举例：

比如汉字“我”，假设它的值是22530（只是假设，具体多少我没查） 

而日文的“マ”的值也可能是22530(也是假设)或韩文的“?” 

在网络上传输是不能以高字节传输，因为网络底层最后只认无符号char,相当于java中的byte,所以 
22530这个int要转换为字节数组， 

byte[0] = (22530 >> 8)&0xFF; 
byte[1] = 22530 &0xFF; 
具体多少我没算，假设是byte[125，231] 

这样的字节传到服务端到是表示汉字“我”还是日文的“マ”还是其它狗屁？ 
一般通讯协议中会告诉对字符集，比如HTTP在请求时告诉服务端： 
ContentType="xxxxxxxxxx";charset="GKB"; 
这时服务端就知道现在接收到的［125，231］是GKB的“我”而不是其它文字。 

上面是标准的通信过程。但如果有些水平很差的程序员在提交请求时没有通知服务端字符集，那服务端就没办法了。 
只好按最常用的字符集来猜一个默认的。 

这还不错，最要命的是写服务器的程序员水平和见识很差时，就要命了。就象写老版本的TOMCAT的程序员，他自己生在西方，以为全世界所有人都用的是26个字母加一些符号，所以他不管客户端提交什么都按ISO-8859-1来算，结果可想而知。 

没办法，谁让我们用GBK的人不会写tomcat呢，只好先把让那个差劲的程序员错误生成的String用ISO-8859-1还原成 
［125，231］，再重新用GKB生成String.

 用于得到服务器传来的字符重新生成GBK编码