下面是处理页面(process.jsp)代码: <%@ page contentType="text/html; charset=gb2312"%>
<%=request.getParameter("name")%> 如果 submit.jsp 提交英文字符能正确显示, 如果提交中文时就会出现 乱码。原因:浏览器默认使用 UTF -8 编码方式来发送请求, UTF- 8 和 GB2312 编码方式表示字符时 而 不一样,这样就出现了不能识别字符。 解决办法:通过 request.seCharacterEncoding ("gb2312")对请求进行 统一编码,就实现了中文的正常
显示。修改后的 process.jsp 代码如下: <%@ page contentType="text/html; charset=gb2312"%> <% request.seCharacterEncoding("gb2312"); %>
<%=request.getParameter("name")%> 三、数据库连接出现乱码 只要涉及中文的地方全部是乱码, 解决办法: 在数据库的数据库 URL 中加上 useUnicode=true&;characterEncoding=GBK 就 OK 了。
四、数据库的显示乱码 在 mysql4.1.0 中,varchar 类型,text 类型就会出现中文乱码,对于 varchar 类型把它设为 binary 属性就 可以解决中文问题, 对于 text 类型就要用一个编码转换类来处理, 实 现如下: public class Convert { /** 把 ISO-8859-1 码转换成 GB2312 */ public static String ISOtoGB(String iso){ String gb; try{ if(iso.equals("") || iso == null){ return ""; } else{ iso = iso.trim(); gb = new String(iso.getBytes("ISO-8859-1"),"GB2312"); return gb; } } catch(Exception e){ System.err.print("编码转换错误:"+e.getMessage());
return ""; } } } 把它编译成 class,就可以调用 Convert 类的静态方法 ISOtoGB()来 转换编码。
如果你还有什么不懂之处:我给大家推荐一个好的 JSP-JAVA 网站: phy.hbnu.edu/dsp/
总结: 1. 在 jsp 中<%@ page contentType="text/html; charset=A" %>如 果指定了,那么在改 jsp 中所有构造 的 String(不是引用),如果沒有指定编码,那么这些 String 的编码 是 A
的。 从 request 的得到的 String 如果沒有指定 request 的编码的话, 他 是 iso-8859-1 的 从别的地方得到的 String 是使用原來初始的编码的,比如从数据 库得到 String,如果数据库的编码
是 B,那么该 String 的编码是 B 而不是 A 的,也不是系统默认的。 此时,如果要输出的 String 的编码不是 A,那么,很可能显示乱码 的,所以首先要将 String 正確转化 为编码 A 的 String,然后输出。 2. 在 jsp 中<%@ page contentType="text/html; charset=A" %>沒 有指定,那么相当于指定了<%@ page contentType="text/html; charset=ISO-8859-1" %> 3. Servelte 中如果执行了像 response.setContentType("text/html;charset=A");説明将 response 的 字符输出流编码设置为 A,所有要输出的 String 的编码要转化为 A 的, 否則会得到乱码的。 Servelet 中从 request 得到的 String 的编码和 jsp 中一样的, 但是 在 servlet java 文件中构造的 String 是使用的系统默认的编码的。 servelt 中从外部得到的 String 在 是使用原来的编码的,比如从编 码为 B 的数据库得到的数据是编码为 B 的,不是 A,也不是系统默认的 编码。
//////////////////////////////////////////////////////////////////////////////////////////
转载:JSP 中文乱码问题解决方法小结 在使用 JSP 的过程中,最使人头疼的一个问题就是中文乱码问 题,以下是我在软件开发中遇到的乱 码问题以及解决方法。 1、
JSP 页面乱码 这种乱码的原因是应为没有在页面里指定使用的字符集编码, 解 决方法:只要在页面开始地方用下 面代码指定字符集编码即可,
2、数据库乱码 这种乱码会使你插入数据库的中文变成乱码, 或者读出显示时也 是乱码,解决方法如下: 在数据库连接字符串中加入编码字符集 String Url="jdbc:
mysql://localhost/digitgulf? user=root&;password=root&;useUnicode=true&;characterEncoding= GB2312"; 并在页面中使用如下代码: response.setContentType("text/html;charset=gb2312"); request.setCharacterEncoding("gb2312");
3、中文作为参数传递乱码 当我们把一段中文字符作为参数传递个另一页面时, 也会出现乱 码情况,解决方法如下: 在参数传递时对参数编码,比如 RearshRes.jsp?keywords=" + java.net.URLEncoder.encode(key
words) 然后在接收参数页面使用如下语句接收 keywords=new String(request.getParameter("keywords").getBytes("8859_1")); 4、JSP 页面乱码加这句 <%@ page contentType="text/html; charset=gb2312" language="java" import="java.sql.*" errorPage="err.jsp" %> ///////////////////////////////////////////////////////////////////////////////////////// JSP/JDBC MySQL 乱码问题~~~ 作者:佚名 来源:本站整理 发布时间:2005-7-1 12:24:30 綠起: 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/js p?
useUnicode=true&;characterEncoding=GBK","root",""); str1="中文"; String sql2="INSERT INTO test (name) VALUES('"+str1+"')"; 这样也可以很成功的插入了,呵呵 //////////////////////////////////////////////////////////////////////////////////////// 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 常见的 encod