java乱码问题
1.控制台输出乱码问题
1.1原理：
JAVA使用UNICODE来存储字符数据，处理字符时通常有叁个步骤：
- 按指定的字符编码形式，从源输入流中读取字符数据
- 以UNICODE编码形式将字符数据存储在内存中
- 按指定的字符编码形式，将字符数据编码并写入目的输出流中。
所以JAVA处理字符时总是经过了两次编码转换，一次是从指定编码转换为UNICODE编码，一次是从UNICODE编码转换为指定编码。如果在读入时用 错误的形式解码字符，则内存存储的是错误的UNICODE字符。而从最初文件中读出的字符数据，到最终在屏幕终端显示这些字符，期间经过了应用程序的多次 转换。如果中间某次字符处理，用错误的编码方式解码了从输入流读取的字符数据，或用错误的编码方式将字符写入输出流，则下一个字符数据的接收者就会编解码 出错，从而导致最终显示乱码。
1.2分析：
在JAVA文件中硬编码中文字符，在eclipse中运行，控制台输出了乱码。
例如，我们在JAVA文件中写入以下代码：
String text = “大家好”;
System.out.println（text）;
如果我们是在eclipse里编译运行，可能看到的结果是类似这样的乱码：？？？？。那么，这是为什么呢？
我们先来看看整个字符的转换过程。
1. 在eclipse窗口中输入中文字符，并保存成UTF-8的JAVA文件。这里发生了多次字符编码转换。不过因为我们相信eclipse的正确性，所以我们不用分析其中的过程，只需要相信保存下的JAVA文件确实是UTF-8格式。
2. 在eclipse中编译运行此JAVA文件。这里有必要详细分析一下编译和运行时的字符编码转换。
- 编译：我们用javac编译JAVA文件时，javac不会智能到猜出你所要编译的文件是什么编码类型的，所以它需要指定读取文件所用的编码类型。默认 javac使用平台缺省的字符编码类型来解析JAVA文件。平台缺省编码是操作系统决定的，我们使用的是中文操作系统，语言区域设置通常都是中国大陆，所以平台缺省编码类型通常是GBK。这个编码类型我们可以在JAVA中使用Properties pro=System.getProperty()，pro. getProperty(“file.encoding”)来查看。所以javac会默认使用GBK来解析JAVA文件。如果我们要改变javac所用的编码类型，就要加上-encoding参数，如javac -encoding utf-8 Test.java。
这里要另外提一下的是eclipse使用的是内置的编译器，并不能添加参数，如果要为javac添加参数则建议使用ANT来编译。不过这并非出现乱码的塬因，因为eclipse可以为每个JAVA文件设置字符编码类型，而内置编译器会根据此设置来编译JAVA文件。
- 运行：编译后字符数据会以UNICODE格式存入字节码文件中。然后eclipse会调用java命令来运行此字节码文件。因为字节码中的字符总是 UNICODE格式，所以java读取字节码文件并没有编码转换过程。虚拟机读取文件后，字符数据便以UNICODE格式存储在内存中了。
3. 调用System.out.println来输出字符。这里又发生了字符编码转换。
System.out.println使用了PrintStream类来输出字符数据至控制台。PrintStream会使用平台缺省的编码方式来输出字 符。我们的中文系统上缺省方式为GBK，所以内存中的UNICODE字符被转码成了GBK格式，并送到了操作系统的输出服务中。因为我们操作系统是中文系统，所以往终端显示设备上打印字符时使用的也是GBK编码。如果到这一步，我们的字符其实不再是GBK编码的话，终端就会显示出乱码。
那么，在eclipse运行带中文字符的JAVA文件，控制台显示了乱码，是在哪一步转换错误呢？我们一步步来分析。
- 保存JAVA文件成UTF-8后，如果再次打开你没有看到乱码，说明这步是正确的。
- 用eclipse本身来编译运行JAVA文件，应该没有问题。
- System.out.println会把内存中正确的UNICODE字符编码成GBK，然后发到eclipse的控制台去。等等，我们看到在Run Configuration对话框的Common标签里，控制台的字符编码被设置成了UTF-8！问题就在这里。System.out.println已经把字符编码成了GBK，而控制台仍然以UTF-8的格式读取字符，自然会出现乱码。
将控制台的字符编码设置为GBK，乱码问题解决。
（这里补充一点：eclipse的控制台编码是继承了workspace的设置的，通常控制台编码里没有GBK的选项而且不能输入。我们可以先在 workspace的编码设置中输入GBK，然后在控制台的设置中就可以看到GBK的选项了，设置好后再把workspace的字符编码设置改回utf- 8就是。）
1.3从文件中读取中文字控制台输出乱码问题：
原因：从文件中读取出2进制流文件，在转换为string时采用的是默认的是GBK编码，而控制台中设置的编码格式与项目的编码格式一样UTF-8，在控制台中展示时GBK编码转换为UTF-8编码出现乱码（真实过程是GBK->UNICODE->UTF-8）。对于将转换出的string类型数据存入数据库中不存在这一编码转换的问题，所有不用担心数据库中会存储乱码。Console显示乱码只是设置问题，解决方法将console设置改成GBK编码：
2.Jsp中文乱码问题
2.1 JSP文件中硬编码中文字符，在浏览器上显示乱码。
我们用eclipse编写一个JSP页面，使用tomcat浏览这个页面时，整个页面的中文字符都是乱码。这是什么原因呢？
JSP页面从编写到在浏览器上浏览，总共有四次字符编解码。
1. 以某种字符编码保存JSP文件，选中jsp文件查看properties，如果没有特别设置应与项目指定的编码格式相同，有时候查看jsp文件出现中文乱码原因就是jsp文件当前的编码格式与编辑时不一致；
2. Tomcat以指定编码来读取JSP文件并编译。如页面中设置了pageEncoding="XX"，则服务器在读取Jsp页面时，就会使用上面设置的XX来读取，如果没有设置，再看是否设置了contentType="text/html; charset=XXX" ，如果设置了，则用charset中指定的编码方式来读取。如果这两个都没有指定时，则使用默认的编码方式ISO8859-1来读取（编译按照jsp设置格式进行编译）；
3. Jsp页面读取到内存后，在内存中以Unicode编码存在；
4. 当访问jsp时需要根据Jsp文件生成Servlet类文件并解析为class文件（第一次调用），Tomcat服务器的编码格式为UTF-8，生成
servlet文件也是采用的UTF-8编码（可以查看jsp文件生成的对应servlet类）；（注：访问jsp文件其实是执行servlet，servlet执行生成响应html文件发送到browser，所有浏览器解析的其实是servlet生成的html文件，html文件的编码格式在contentType="text/html; charset=XXX设置。）
编码过程：jsp文件格式GBK,jsp页面格式ISO-8859，tomcat编码格式UTF-8，整个编码过程GBK文件->ISO-8859解码编译->jsp入内存使用unicode编码（unicode编码与iso-8859编码只在所占字节数不同）->jsp生成servlet进行UTF-8编码
2.2浏览器上显示乱码的原因在于：
浏览器默认的编码格式是GB2312（简体中文编码格式），而jsp页面的编码格式为iso-8859（默认），浏览器解析html文件时自然会出现中文乱码问题。
解决方法：设置页面编码格式<%@page contentType=text/html; charset=GB2312% >
2.3表单提交后进行响应显示的中文乱码问题：
浏览器默认使用UTF-8的格式发送请求，页面中文数据默认使用的UTF-8编码发送（浏览器必须适用各种语言），服务器接收到的request域中的中文数据也是使用的UTF-8编码，如果将该数据直接显示到页面上就会发生中文乱码问题（编码格式不一致）。
解决办法：指定表单请求的编码格式为gb2312 ，Request.setCharacterEncoding(“gb2312”)。Response同样适用,Response .setCharacterEncoding(“gb2312”),在向response域中存放string时得将数据转换为gb2312。
注：jsp、servlet中获取request的string编码是一样的（默认utf-8，参见上文），而在tomcat生成的servlet java中编码是采用的系统默认的utf-8编码的。
3.文件传输过程的中中文路径、中文名解决：
new String(oldName.getBytes("GBK"), "iso-8859-1"),将中文字编码转换为iso-8859-1
1.1原理：
JAVA使用UNICODE来存储字符数据，处理字符时通常有叁个步骤：
- 按指定的字符编码形式，从源输入流中读取字符数据
- 以UNICODE编码形式将字符数据存储在内存中
- 按指定的字符编码形式，将字符数据编码并写入目的输出流中。
所以JAVA处理字符时总是经过了两次编码转换，一次是从指定编码转换为UNICODE编码，一次是从UNICODE编码转换为指定编码。如果在读入时用 错误的形式解码字符，则内存存储的是错误的UNICODE字符。而从最初文件中读出的字符数据，到最终在屏幕终端显示这些字符，期间经过了应用程序的多次 转换。如果中间某次字符处理，用错误的编码方式解码了从输入流读取的字符数据，或用错误的编码方式将字符写入输出流，则下一个字符数据的接收者就会编解码 出错，从而导致最终显示乱码。
1.2分析：
在JAVA文件中硬编码中文字符，在eclipse中运行，控制台输出了乱码。
例如，我们在JAVA文件中写入以下代码：
String text = “大家好”;
System.out.println（text）;
如果我们是在eclipse里编译运行，可能看到的结果是类似这样的乱码：？？？？。那么，这是为什么呢？
我们先来看看整个字符的转换过程。
1. 在eclipse窗口中输入中文字符，并保存成UTF-8的JAVA文件。这里发生了多次字符编码转换。不过因为我们相信eclipse的正确性，所以我们不用分析其中的过程，只需要相信保存下的JAVA文件确实是UTF-8格式。
2. 在eclipse中编译运行此JAVA文件。这里有必要详细分析一下编译和运行时的字符编码转换。
- 编译：我们用javac编译JAVA文件时，javac不会智能到猜出你所要编译的文件是什么编码类型的，所以它需要指定读取文件所用的编码类型。默认 javac使用平台缺省的字符编码类型来解析JAVA文件。平台缺省编码是操作系统决定的，我们使用的是中文操作系统，语言区域设置通常都是中国大陆，所以平台缺省编码类型通常是GBK。这个编码类型我们可以在JAVA中使用Properties pro=System.getProperty()，pro. getProperty(“file.encoding”)来查看。所以javac会默认使用GBK来解析JAVA文件。如果我们要改变javac所用的编码类型，就要加上-encoding参数，如javac -encoding utf-8 Test.java。
这里要另外提一下的是eclipse使用的是内置的编译器，并不能添加参数，如果要为javac添加参数则建议使用ANT来编译。不过这并非出现乱码的塬因，因为eclipse可以为每个JAVA文件设置字符编码类型，而内置编译器会根据此设置来编译JAVA文件。
- 运行：编译后字符数据会以UNICODE格式存入字节码文件中。然后eclipse会调用java命令来运行此字节码文件。因为字节码中的字符总是 UNICODE格式，所以java读取字节码文件并没有编码转换过程。虚拟机读取文件后，字符数据便以UNICODE格式存储在内存中了。
3. 调用System.out.println来输出字符。这里又发生了字符编码转换。
System.out.println使用了PrintStream类来输出字符数据至控制台。PrintStream会使用平台缺省的编码方式来输出字 符。我们的中文系统上缺省方式为GBK，所以内存中的UNICODE字符被转码成了GBK格式，并送到了操作系统的输出服务中。因为我们操作系统是中文系统，所以往终端显示设备上打印字符时使用的也是GBK编码。如果到这一步，我们的字符其实不再是GBK编码的话，终端就会显示出乱码。
那么，在eclipse运行带中文字符的JAVA文件，控制台显示了乱码，是在哪一步转换错误呢？我们一步步来分析。
- 保存JAVA文件成UTF-8后，如果再次打开你没有看到乱码，说明这步是正确的。
- 用eclipse本身来编译运行JAVA文件，应该没有问题。
- System.out.println会把内存中正确的UNICODE字符编码成GBK，然后发到eclipse的控制台去。等等，我们看到在Run Configuration对话框的Common标签里，控制台的字符编码被设置成了UTF-8！问题就在这里。System.out.println已经把字符编码成了GBK，而控制台仍然以UTF-8的格式读取字符，自然会出现乱码。
将控制台的字符编码设置为GBK，乱码问题解决。
（这里补充一点：eclipse的控制台编码是继承了workspace的设置的，通常控制台编码里没有GBK的选项而且不能输入。我们可以先在 workspace的编码设置中输入GBK，然后在控制台的设置中就可以看到GBK的选项了，设置好后再把workspace的字符编码设置改回utf- 8就是。）
1.3从文件中读取中文字控制台输出乱码问题：
原因：从文件中读取出2进制流文件，在转换为string时采用的是默认的是GBK编码，而控制台中设置的编码格式与项目的编码格式一样UTF-8，在控制台中展示时GBK编码转换为UTF-8编码出现乱码（真实过程是GBK->UNICODE->UTF-8）。对于将转换出的string类型数据存入数据库中不存在这一编码转换的问题，所有不用担心数据库中会存储乱码。Console显示乱码只是设置问题，解决方法将console设置改成GBK编码：
2.Jsp中文乱码问题
2.1 JSP文件中硬编码中文字符，在浏览器上显示乱码。
我们用eclipse编写一个JSP页面，使用tomcat浏览这个页面时，整个页面的中文字符都是乱码。这是什么原因呢？
JSP页面从编写到在浏览器上浏览，总共有四次字符编解码。
1. 以某种字符编码保存JSP文件，选中jsp文件查看properties，如果没有特别设置应与项目指定的编码格式相同，有时候查看jsp文件出现中文乱码原因就是jsp文件当前的编码格式与编辑时不一致；
2. Tomcat以指定编码来读取JSP文件并编译。如页面中设置了pageEncoding="XX"，则服务器在读取Jsp页面时，就会使用上面设置的XX来读取，如果没有设置，再看是否设置了contentType="text/html; charset=XXX" ，如果设置了，则用charset中指定的编码方式来读取。如果这两个都没有指定时，则使用默认的编码方式ISO8859-1来读取（编译按照jsp设置格式进行编译）；
3. Jsp页面读取到内存后，在内存中以Unicode编码存在；
4. 当访问jsp时需要根据Jsp文件生成Servlet类文件并解析为class文件（第一次调用），Tomcat服务器的编码格式为UTF-8，生成
servlet文件也是采用的UTF-8编码（可以查看jsp文件生成的对应servlet类）；（注：访问jsp文件其实是执行servlet，servlet执行生成响应html文件发送到browser，所有浏览器解析的其实是servlet生成的html文件，html文件的编码格式在contentType="text/html; charset=XXX设置。）
编码过程：jsp文件格式GBK,jsp页面格式ISO-8859，tomcat编码格式UTF-8，整个编码过程GBK文件->ISO-8859解码编译->jsp入内存使用unicode编码（unicode编码与iso-8859编码只在所占字节数不同）->jsp生成servlet进行UTF-8编码
2.2浏览器上显示乱码的原因在于：
浏览器默认的编码格式是GB2312（简体中文编码格式），而jsp页面的编码格式为iso-8859（默认），浏览器解析html文件时自然会出现中文乱码问题。
解决方法：设置页面编码格式<%@page contentType=text/html; charset=GB2312% >
2.3表单提交后进行响应显示的中文乱码问题：
浏览器默认使用UTF-8的格式发送请求，页面中文数据默认使用的UTF-8编码发送（浏览器必须适用各种语言），服务器接收到的request域中的中文数据也是使用的UTF-8编码，如果将该数据直接显示到页面上就会发生中文乱码问题（编码格式不一致）。
解决办法：指定表单请求的编码格式为gb2312 ，Request.setCharacterEncoding(“gb2312”)。Response同样适用,Response .setCharacterEncoding(“gb2312”),在向response域中存放string时得将数据转换为gb2312。
注：jsp、servlet中获取request的string编码是一样的（默认utf-8，参见上文），而在tomcat生成的servlet java中编码是采用的系统默认的utf-8编码的。
3.文件传输过程的中中文路径、中文名解决：
new String(oldName.getBytes("GBK"), "iso-8859-1"),将中文字编码转换为iso-8859-1