始地方用下
面代码指定字符集编码即可，
2、数据库乱码
这种乱码会使你插入数据库的中文变成乱码，或者读出显示时也是乱码，解决方法如下：
在数据库连接字符串中加入编码字符集 String Url=\
user=root&password=root&useUnicode=true&characterEncoding=GB2312\
并在页面中使用如下代码：
response.setContentType(\
request.setCharacterEncoding(\
3、中文作为参数传递乱码
当我们把一段中文字符作为参数传递个另一页面时，也会出现乱码情况，解决方法如下：
在参数传递时对参数编码，比如
RearshRes.jsp?keywords=\
然后在接收参数页面使用如下语句接收
keywords=new String(request.getParameter(\
4、JSP页面乱码加这句
<%@ page contentType=\
errorPage=\
/////////////////////////////////////////////////////////////////////////////////////////
JSP/JDBC MySQL乱码问题~~~
作者：佚名 来源：本站整理 发布时间：2005-7-1 12:24:30
綠起：
JSP的request 默认为ISO8859_1，所以在处理中文的时候，
要显示中文的话，必须转成GBK的，如下
String str=new String(request.getParameter(\
out.println(str); 这样就可以显示中文了 MYSQL操作时的中文问题：
这个要看MySQL的默认编码了，一般不调整的话为latin1其实和ISO8859_1一样，所以操
作的时候要处理 和他一致，不然就会乱码的
1.插入中文：
String sql2=\
stmt.executeUpdate(sql2); 不用编码就可以插入了 2.显示插入的中文：
因为存入的是latin，所以显示的时候就要GBK一下
String x=new String((rs.getString(\
out.println(x); 3.设定存储编码：
当然在MySQL为latin1编码时，也可以存的时候用GBK了
Connection con=DriverManager.getConnection(\
useUnicode=true&characterEncoding=GBK\
str1=\中文\
String sql2=\
这样也可以很成功的插入了，呵呵
////////////////////////////////////////////////////////////////////////////////////////
JSP/Servlet 中的汉字编码问题
（作者：张建芳，转自IBM DeveloperWorks 中国网站 2001年04月18日 15:08） 网上就 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 的字位。其所有字符都可以一对一映射到 Unicode 2.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个外，是因为 Java font 设