关于jsp乱码问题的产生原因 及 解决方法。

http://blog.csdn.net/caoxiaohong/article/details/1781777

JSP/JDBC MySQL乱码问题
JSP的request 默认为ISO8859_1，所以在处理中文的时候，要显示中文的话，必须转成GBK的，如下String str=new String(request.getParameter("name").getBytes("ISO8859-1"),"GBK"); out.println(str); 这样就可以显示中文了

MYSQL操作时的中文问题：
这个要看MySQL的默认编码了，一般不调整的话为latin1其实和ISO8859_1一样，所以操作的时候要处理和他一致，不然就会乱码的

1.插入中文：
String sql2="INSERT INTO test (name) VALUES('"+request.getParameter("name")+"')";
stmt.executeUpdate(sql2);
不用编码就可以插入了

2.显示插入的中文：
因为存入的是latin，所以显示的时候就要GBK一下
String x=new String((rs.getString("title")).getBytes("ISO8859_1"),"GBK");
out.println(x);

3.设定存储编码：
当然在MySQL为latin1编码时，也可以存的时候用GBK了
Connection con=DriverManager.getConnection("jdbc:mysql://localhost:3306/jsp?
useUnicode=true&characterEncoding=GBK","root","");
str1="中文";
String sql2="INSERT INTO test (name) VALUES('"+str1+"')";
这样也可以很成功的插入了，呵呵

JSP/Servlet 中的汉字编码问题

　　网上就 JSP/Servlet 中 DBCS 字符编码问题有许多优秀的文章和讨论，本文对它们作一些整理，并结合 IBM WebSphere Application Server 3.5（WAS）的解决方法作一些说明，希望它不是多余的。

1.问题的起源

　　每个国家（或区域）都规定了计算机信息交换用的字符编码集，如美国的ASCII， 中国的GB2312-80，日本的JIS等，作为该国家/区域内信息处理的基础，有着统一编码的重要作用。字符编码集按长度分为SBCS（单字节字符 集），DBCS（双字节字符集）两大类。早期的软件（尤其是操作系统），为了解决本地字符信息的计算机处理，出现了各种本地化版本（L10N），为了区 分，引进了LANG，Codepage等概念。但是由于各个本地字符集代码范围重叠，相互间信息交换困难；软件各个本地化版本独立维护成本较高。因此有必 要将本地化工作中的共性抽取出来，作一致处理，将特别的本地化处理内容降低到最少。这也就是所谓的国际化（I18N）。各种语言信息被进一步规范为 Locale信息。处理的底层字符集变成了几乎包含了所有字形的 Unicode。

　　现在大部分具有国际化特征的软件核心字符处理都是以Unicode 为基础的，在软件运行时根据当时的Locale/Lang/Codepage设置确定相应的本地字符编码设置，并依此处理本地字符。在处理过程中需要实现 Unicode和本地字符集的相互转换，甚或以Unicode为中间的两个不同本地字符集的相互转换。这种方式在网络环境下被进一步延伸，任何网络两端的 字符信息也需要根据字符集的设置转换成可接受的内容。

　　Java 语言内部是用 Unicode 表示字符的，遵守 Unicode V2.0。Java 程序无论是从/往文件系统以字符流读/写文件，还是往 URL 连接写 HTML 信息，或从 URL 连接读取参数值，都会有字符编码的转换。这样做虽然增加了编程的复杂度，容易引起混淆，但却是符合国际化的思想的。

　　从理论上来说，这些根据字符集设置而进行的字符转换不应该产生太多问题。而事实是由于应用程序的实际运行环境不同，Unicode和各个本地字符集的补充、完善，以及系统或应用程序实现的不规范，转码时出现的问题时时困扰着程序员和用户。

2.GB2312-80，GBK，GB18030-2000 汉字字符集

　　其实解决 JAVA 程序中的汉字编码问题的方法往往很简单，但理解其背后的原因，定位问题，还需
要了解现有的汉字编码和编码转换。

　　GB2312-80是在国内计算机汉字 信息技术发展初始阶段制定的，其中包含了大部分常用的一、二级汉字，和9区的符号。该字符集是几乎所有的中文系统和国际化的软件都支持的中文字符集，这也 是最基本的中文字符集。其编码范围是高位0xa1－0xfe，低位也是 0xa1-0xfe；汉字从 0xb0a1 开始，结束于 0xf7fe；

　　GBK是GB2312-80的扩展，是 向上兼容的。它包含了20902个汉字，其编码范围是0x8140-0xfefe，剔除高位0x80的字位。其所有字符都可以一对一映射到 Unicode2.0，也就是说JAVA实际上提供了GBK字符集的支持。这是现阶段Windows和其它一些中文操作系统的缺省字符集，但并不是所有的 国际化软件都支持该字符集，感觉是他们并不完全知道GBK是怎么回事。值得注意的是它不是国家标准，而只是规范。随着GB18030-2000国标的发 布，它将在不久的将来完成它的历史使命。

　　GB18030-2000(GBK2K)在GBK的基础上进一步扩展了汉字，增加了藏、蒙等少数民族的字形。GBK2K从根本上解决了字位不够，字形不足的问题。它有几个特点：

　　●它并没有确定所有的字形，只是规定了编码范围，留待以后扩充。
　　●编码是变长的，其二字节部分与 GBK 兼容；四字节部分是扩充的字形、字位，其编码范围是首字节 0x81-0xfe、二字节0x30-0x39、三字节 0x81-0xfe、四字节0x30-0x39。
　　●它的推广是分阶段的，首先要求实现的是能够完全映射到 Unicode 3.0 标准的所有字形。
　　●它是国家标准，是强制性的。
　　现在还没有任何一个操作系统或软件实现了 GBK2K 的支持，这是现阶段和将来汉化的工作内容。

3.JSP/Servlet 汉字编码问题及在 WAS 中的解决办法

　　3.1 常见的 encoding 问题的现象

　　网上常出现的 JSP/Servlet encoding 问题一般都表现在 browser 或应用程序端，如:
　　●浏览器中看到的 Jsp/Servlet 页面中的汉字怎么都成了 ’?’ ?
　　●浏览器中看到的 Servlet 页面中的汉字怎么都成了乱码？
　　●JAVA 应用程序界面中的汉字怎么都成了方块？
　　●Jsp/Servlet 页面无法显示 GBK 汉字。
　　●Jsp/Servlet 不能接收 form 提交的汉字。
　　●JSP/Servlet 数据库读写无法获得正确的内容。
　　隐藏在这些问题后面的是各种错误的字符转换和处理（除第3个外，是因为Javafont设置错误引起的）。解决类似的字符encoding问题，需要了解Jsp/Servlet 的运行过程，检查可能出现问题的各个点。

　　3.2 JSP/Servlet web 编程时的 encoding 问题
　　运行于Java 应用服务器的 JSP/Servlet 为 Browser 提供 HTML 内容，
　　其中有字符编码转换的地方有：

　　a.JSP 编译。Java 应用服务器将根据 JVM 的 file.encoding 值读取 JSP 源文件，并转换为内部字符编码进行 JSP 编译，生成 JAVA 源文件，根据file.encoding值写回文件系统。如果当前系统语言支持GBK，那么这时候不会出现encoding问题。如果是英文的系统，如 LANG 是 en_US的Linux,AIX或Solaris，则要将JVM的file.encoding值置成GBK。系统语言如果是GB2312，则根据需要，确 定要不要设置file.encoding，将 file.encoding 设为 GBK 可以解决潜在的 GBK 字符乱码问题

　　b.Java需要被编译为.class才能在JVM中执行，这个过程存在与a.同样的file.encoding问题。从这里开始servlet和jsp的运行就类似了，只不过 Servlet 的编译不是自动进行的。

　　c.Servlet需要将HTML页面 内容转换为browser可接受的encoding内容发送出去。依赖于各JAVAAppServer的实现方式，有的将查询 Browser的accept-charset和accept-language参数或以其它猜的方式确定encoding值，有的则不管。因此 constant-encoding也许是最好的解决方法。对于中文网页，可在JSP或Servlet中设置 contentType="text/html;charset=GB2312"；如果页面中有GBK字符，则设置为contentType="text /html; charset=GBK"，由于IE 和 Netscape对GBK的支持程度不一样，作这种设置时需要测试一下。

　　因为16位JAVAchar在网络传送 时高8位会被丢弃，也为了确保Servlet页面中的汉字（包括内嵌的和servlet运行过程中得到的）是期望的内码，可以用 PrintWriterout=res.getWriter()取代 ServletOutputStreamout=res.getOutputStream(),PrinterWriter将根据contentType 中指定的charset作转换(ContentType需在此之前指定！);也可以用OutputStreamWriter封装 ServletOutputStream类并用write(String)输出汉字字符串。 对于 JSP，JAVA Application Server 应当能够确保在这个阶段将嵌入的汉字正确传送出去。

　　d.这是URL字符encoding问 题。如果通过get/post方式从browser返回的值中包含汉字信息，servlet将无法得到正确的值。SUN的 J2SDK 中，HttpUtils.parseName 在解析参数时根本没有考虑 browser 的语言设置，而是将得到的值按 byte 方式解析。这是网上讨论得最多的 encoding问题。因为这是设计缺陷，只能以bin方式重新解析得到的字符串；或者以hackHttpUtils类的方式解决。参考文章2、3均有介 绍，不过最好将其中的中文 encoding GB2312、 CP1381 都改为 GBK，否则遇到 GBK 汉字时，还是会有问题。

　　ServletAPI2.3提供一个新 的函数HttpServeletRequest.setCharacterEncoding用于在调用 request.getParameter(“param_name”) 前指定应用程序希望的 encoding，这将有助于彻底解决这个问题。

　　WebSphere Application Server 对标准的 Servlet API 2.x 作了扩展，提供较好的多语言支持。上述c,d情况，WAS 都要查询 Browser 的语言设置，在缺省状况下zh、zh-cn 等均被映射为 JAVA encoding CP1381（注意：CP1381 只是等同于 GB2312 的一个 codepage，没有 GBK 支持）。这样做我想是因为无法确认 Browser 运行的操作系统是支持GB2312, 还是 GBK，所以取其小。但是实际的应用
系统还是要求页面中出现 GBK 汉字，最著名的是朱总理名字中的“?”(rong2 ，0xe946，/u9555)，所以有时还是需要将 Encoding/Charset 指定为 GBK。当然 WAS 中变更缺省的 encoding 没有上面说的那么麻烦，针对 a,b，参考文章 5 ），在 Application Server 的命令行参数中指定-Dfile.encoding=GBK即可；针对d，在ApplicationServer的命令行参数中指定 -Ddefault.client.encoding=GBK。如果指定了-Ddefault.client.encoding=GBK，那么c情况下可 以不再指定charset。

　　3.3 数据库读写时的 encoding 问题

　　JSP/Servlet 编程中经常出现 encoding 问题的另一个地方是读写数据库中的数据。流行的关系数据库系统都支持数据库 encoding，也就是说在创建数据库时可以指定它自己的字符集设置，数据库的数据以指定的编码形式存储。当应用程序访问数据时，在入口和出口处都会有 encoding 转换。对于中文数据，应当保证数据的完整性。GB2312，GBK，UTF-8 等都是可选的数据库 encoding；如果选择 ISO8859-1(8-bitSBCS)，那么应用程序在写数据之前须将16Bit的一个汉字或Unicode拆分成两个8-bit的字符，读数据之后 则需将两个字节合并起来，同时还有判别其中的 SBCS 字符。没有充分利用数据库 encoding 的作用，反而增加了编程的复杂度，ISO8859-1不是推荐的数据
库 encoding。JSP/Servlet编程时，可以先用数据库管理系统提供的功能检查其中的中文数据是否正确。

　　然后应当注意的是读出来的数据的 encoding，JAVA 程序中一般得到的是 Unicode。写数据时则相反。

　　3.4 定位问题时常用的技巧

　　定位中文encoding问题通常采用 最笨的也是最有效的办法——在你认为有嫌疑的程序处理后打印字符串的内码。通过打印字符串的内码，你可以发现什么时候中文字符被转换成Unicode，什 么时候Unicode被转回中文内码，什么时候一个中文字成了两个Unicode字符，什么时候中文字符串被转成了一串问号，什么时候中文字符串的高位被 截掉了……

　　取用合适的样本字符串也有助于区分问题的类型。如：”aa啊aa?aa”等中英相间、GB、GBK特征字符均有的字符串。一般来说，英文字符无论怎么转换或处理，都不会失真（如果遇到了，可以尝试着增加连续的英文字母长度）。

 

 

1 最基本的乱码问题。

这个乱码问题是最简单的乱码问题。一般新会出现。就是页面编码不一致导致的乱码。

<%@ page language="java" pageEncoding="UTF-8"%>

<%@ page contentType="text/html;charset=iso8859-1"%>

<html>

<head>

<title>中文问题</title>

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

</head>

</head>

<body>

  我是个好人

</body>

</html>

三个地方的编码。

第一个地方的编码格式为jsp文件的存储格式。Eclipse会根据这个编码格式保存文件。并编译jsp文件，包括里面的汉字。

第二处编码为解码格式。因为存为UTF-8的文件被解码为iso8859-1，这样 如有中文肯定出乱码。也就是必须一致。而第二处所在的这一行，可以没有。缺省也是使用iso8859-1的编码格式。所以如果没有这一行的话，“我是个好 人”也会出现乱码。必须一致才可以。

  第三处编码为控制浏览器的解码方式。如果前面的解码都一致并且无误的话，这个编码格式没有关系。有的网页出现乱码，就是因为浏览器不能确定使用哪种编码格式。因为页面有时候会嵌入页面，导致浏览器混淆了编码格式。出现了乱码。

2 表单使用Post方式提交后接收到的乱码问题

这个问题也是一个常见的问题。这个乱码也是tomcat的内部编码格式iso8859-1在捣 乱，也就是说post提交时，如果没有设置提交的编码格式，则会以iso8859-1方式进行提交，接受的jsp却以utf-8的方式接受。导致乱码。既 然这样的原因，下面有几种解决方式，并比较。

A 接受参数时进行编码转换

String str = new String(request.getParameter("something").getBytes("ISO-8859-1"),"utf-8") ； 这样的话，每一个参数都必须这样进行转码。很麻烦。但确实可以拿到汉字。

B 在请求页面上开始处，执行请求的编码代码， request.setCharacterEncoding("UTF-8")，把提交内容的字符集设为UTF－8。这样的话，接受此参数的页面就不必在转码了。直接使用

String str = request.getParameter("something")；即可得到汉字参数。但每页都需要执行这句话。这个方法也就对post提交的有效 果，对于get提交和上传文件时的enctype="multipart/form-data"是无效的。稍后下面单独对这个两个的乱码情况再进行说明。

C 为了避免每页都要写request.setCharacterEncoding("UTF-8")，建议使用过滤器对所有jsp

  进行编码处理。这个网上有很多例子。请大家自己查阅。

3 表单get提交方式的乱码处理方式。

如果使用get方式提交中文，接受参数的页面也会出现乱码，这个乱码的原因也是tomcat的内部编码格式iso8859-1导致。Tomcat会以get的缺省编码方式iso8859-1对汉字进行编码，编码后追加到url，导致接受页面得到的参数为乱码/、。

解决办法：

A 使用上例中的第一种方式，对接受到的字符进行解码，再转码。

B Get走的是url提交，而在进入url之前已经进行了iso8859-1的编码处理。要想影响这个编码则需要在server.xml的Connector节点增加useBodyEncodingForURI="true"

属性配置，即可控制tomcat对get方式的汉字编码方式，上面这个属性控制get提交也是 用request.setCharacterEncoding("UTF-8")所设置的编码格式进行编码。所以自动编码为utf-8，接受页面正常接受 就可以了。但我认为真正的编码过程是，tomcat又要根据

<Connector port="8080"

maxThreads="150" minSpareThreads="25" maxSpareThreads="75"

enableLookups="false" redirectPort="8443" acceptCount="100"

debug="0" connectionTimeout="20000" useBodyEncodingForURI="true"

disableUploadTimeout="true" URIEncoding=”UTF-8”/>

里面所设置的URIEncoding=”UTF-8”再进行一次编码，但是由于已经编码为utf-8，再编码也不会有变化了。如果是从url获取编码，接受页面则是根据URIEncoding=”UTF-8”来进行解码的。

4 上传文件时的乱码解决

  上传文件时，form表单设置的都是enctype="multipart/form-data"。这种方式以流方式提交文件。如果使用apach的上传 组件，会发现有很多乱码想象。这是因为apach的先期commons-fileupload.jar有bug，取出汉字后进行解码，因为这种方式提交， 编码又自动使用的是tomcat缺省编码格式iso-8859-1。但出现的乱码问题是： 句号，逗号，等特殊符号变成了乱码，汉字如果数量为奇数，则会出现乱码，偶数则解析正常。

    解决方式： 下载commons-fileupload-1.1.1.jar 这个版本的jar已经解决了这些bug。

但是取出内容时仍然需要对取出的字符进行从iso8859-1到utf-8转码。已经能得到正常所有汉字以及字符。

5 Java代码关于url请求，接受参数的乱码

url的编码格式，取决于上面所说的URIEncoding=”UTF-8”。 如果设定了这个编码格式，则意味着所有到url的汉字参数，都必须进行编码才可以。否则得到的汉字参数值都是乱码，例如

一个链接 Response.sendDerect（“/a.jsp?name=张大维”）；而在a.jsp里面直接使用

String name"）；得到的就是乱码。因为规定了必须是utf-8才可以，所以，这个转向应该这样写：

    Response.sendDerect（“/a.jsp?name=URLEncode.encode(“张大维”,”utf-8”)；才可以。

如果不设置这个参数URIEncoding=”UTF-8”， 会怎么样呢? 不设置则就使用了缺省的编码格式iso8859-1。问题又出来了，第一就是参数值的个数如果是奇数个数，则就可以正常解析，如果使偶数个数，得到最后字 符就是乱码。还有就是如果最后一个字符如果是英文，则就能正常解析，但中文的标点符号仍出现乱码。权宜之计，如果您的参数中没有中文标点符号，则可以在参 数值最后加一个英文符号来解决乱码问题，得到参数后再去掉这个最后面的符号。也可以凑或使用。

6 脚本代码关于url请求，接受到的参数乱码

脚本中也会进行页面转向的控制，也会涉及到附带参数，并在接受页面解析这个参数的情况。如果这 个汉字参数不进行URIEncoding=”UTF-8”所指定的编码处理，则接受页面接受到的汉字也是乱码。脚本处理编码比较麻烦，必须有相应的编码脚 本对应文件，然后调用脚本中的方法对汉字进行编码即可。

7 关于jsp在MyEclipse中打开的乱码问题

对于一个已经存在的项目，Jsp文件的存储格式可能是utf-8。如果新安装的 eclipse，则缺省打开使用的编码格式都是iso8859-1。所以导致jsp里面的汉字出现乱码。这个乱码比较容易解决，直接到 eclipse3.1的偏好设置里面找到general-〉edidor，设置为您的文件打开编码为utf-8即可。Eclipse会自动重新以新的编码 格式打开。汉字即可正常显示。

8 关于html页面在eclipse中打开出现乱码情况

由于大部分页面都是由dreamweaver制作，其存储格式跟eclipse的识别有差别导致。

一般这种情况，在eclipse中新建一个jsp，直接从dreamweaver复制页面内容粘贴到jsp即可。