1、jsp乱码处理方案大全文库.txt生活是过出来，不是想出来。放得下是曾经，放不下是记忆。不管我在哪里，我离你全部只有一转身距离。一、JSP页面显示乱码 下面显示页面(display.jsp)就出现乱码：
2、本，处理结果就不一样。原因：服务器使用编码方法不一样和浏览器 对不一样字符显示结果不一样而造成。处理措施：在JSP页面中指定编码方法(gb2312),即在页面第一 行加上：<%@ page contentType="text/html; charset=gb2312"%>，就能够消除乱码了。完整页面以下 ： <%@ page contentType="text/html; charset=gb2312"%>
5、v="Content-Type" content="text/html; charset=gb2312">
<%=request.getParameter("name")%> 假如submit.jsp提交英文字符能正确显示，假如提交汉字时就会出现乱码。原因：浏览器默认使用UTF -8编码方法来发送请求，而UTF- 8和GB2312编码方法表示字符时不一样，这么就出现了不能识别字符。 处理措施:经过request.seCharacterEncoding ("gb2312")对请求进行统一编码，就实现了汉字正6、常 显示。修改后process.jsp代码以下： <%@ page contentType="text/html; charset=gb2312"%> <% request.seCharacterEncoding("gb2312"); %>
7、 三、数据库连接出现乱码 只要包含汉字地方全部是乱码，处理措施：在数据库数据库URL中加上 useUnicode=true&characterEncoding=GBK 就OK了。 四、数据库显示乱码 在mysql4.1.0中,varchar类型，text类型就会出现汉字乱码，对于varchar类型把它设为binary属性就 能够处理汉字问题，对于text类型就要用一个编码转换类来处理，实现以下： public class Convert { /** 把ISO-8859-1码转换成GB2312 */ public static String IS
8、OtoGB(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类静
9、态方法ISOtoGB()来转换编码。 假如你还有什么不懂之处：我给大家推荐一个好JSP-JAVA网站： 总结： 1. 在jsp中<%@ page contentType="text/html; charset=A" %>假如指定了，那么在改jsp中全部结构 String（不是引用），假如沒有指定编码，那么这些String编码是A。 从request得到String假如沒有指定request编码话，她是iso-8859-1 从别地方得到String是使用原來初始编码，比如从数据库得到String,假如数据库编码 是B,那么该St
10、ring编码是B而不是A，也不是系统默认。 此时，假如要输出String编码不是A,那么，很可能显示乱码，所以首先要将String正確转化 为编码AString,然后输出。 2. 在jsp中<%@ page contentType="text/html; charset=A" %>沒有指定，那么相当于指定了<%@ page contentType="text/html; charset=ISO-8859-1" %> 3． Servelte中假如实施了像 response.setContentType("text/html;charset=A");説明将re
11、sponse 字符输出流编码设置为A,全部要输出String编码要转化为A，否則会得到乱码。 Servelet中从request得到String编码和jsp中一样，不过在servlet java文件中结构 String是使用系统默认编码。在servelt中从外部得到String 是使用原来编码，比如从编 码为B数据库得到数据是编码为B,不是A,也不是系统默认编码。 ////////////////////////////////////////////////////////////////////////////////////////// 转载：JSP
12、汉字乱码问题处理方法小结 在使用JSP过程中，最使人头疼一个问题就是汉字乱码问题，以下是我在软件开发中碰到乱 码问题和处理方法。 1、JSP页面乱码 这种乱码原因是应为没有在页面里指定使用字符集编码，处理方法：只要在页面开始地方用下 面代码指定字符集编码即可， 2、数据库乱码 这种乱码会使你插入数据库汉字变成乱码，或读出显示时也是乱码，处理方法以下： 在数据库连接字符串中加入编码字符集 String Url="jdbc:mysql://localhost/digitgulf? user=root&password
13、root&useUnicode=true&characterEncoding=GB2312"; 并在页面中使用以下代码： response.setContentType("text/html;charset=gb2312"); request.setCharacterEncoding("gb2312"); 3、汉字作为参数传输乱码 当我们把一段汉字字符作为参数传输个另一页面时，也会出现乱码情况，处理方法以下： 在参数传输时对参数编码，比如 RearshRes.jsp?keywords=" + .URLEncoder.encode(key
14、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" %> ///////////////////////////////////////////////////////////
15、////////////////////////////// JSP/JDBC MySQL乱码问题~~~ 作者：佚名 起源：本站整理 公布时间：-7-1 12:24:30 綠起： JSPrequest 默认为ISO8859_1，所以在处理汉字时候， 要显示汉字话，必需转成GBK，以下 String str=new String(request.getParameter("name").getBytes("ISO8859-1"),"GBK"); out.println(str); 这么就能够显示汉字了 MYSQL操作时汉字问题： 这个要看MySQL默认编码了，通常
16、不调整话为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");
17、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+"')"; 这么也能够很成功插入了，呵呵 /////////////////
18、/////////////////////////////////////////////////////////////////////// JSP/Servlet 中汉字编码问题 （作者：张建芳，转自IBM DeveloperWorks 中国网站 04月18日 15:08） 网上就 JSP/Servlet 中 DBCS 字符编码问题有很多优异文章和讨论，本文对它们作部分整理， 并结合 IBM WebSphere Application Server 3.5（WAS）处理方法作部分说明，期望它不是多出。 1.问题起源 每个国家（或区域）全部要求了计算机信息
19、交换用字符编码集，如美国 ASCII，中国 GB2312 -80，日本 JIS 等，作为该国家/区域内信息处理基础，有着统一编码关键作用。字符编码集按 长度分为 SBCS（单字节字符集），DBCS（双字节字符集）两大类。早期软件（尤其是操作系统）， 为了处理当地字符信息计算机处理，出现了多种当地化版本（L10N），为了区分，引进了 LANG， Codepage 等概念。不过因为各个当地字符集代码范围重合，相互间信息交换困难；软件各个当地化版 本独立维护成本较高。所以有必需将当地化工作中共性抽取出来，作一致处理，将尤其当地化处理 内容降低到最少。这也就是所谓国
20、际化（I18N）。多种语言信息被深入规范为 Locale 信息。处理 底层字符集变成了几乎包含了全部字形 Unicode。 现在大部分含有国际化特征软件关键字符处理全部是以 Unicode 为基础，在软件运行时依据当 时 Locale/Lang/Codepage 设置确定对应当地字符编码设置，并依此处理当地字符。在处理过程中 需要实现 Unicode 和当地字符集相互转换，甚或以 Unicode 为中间两个不一样当地字符集相互转 换。这种方法在网络环境下被深入延伸，任何网络两端字符信息也需要依据字符集设置转换成可 接收内容。 Java 语言
21、内部是用 Unicode 表示字符，遵守 Unicode V2.0。Java 程序不管是从/往文件系统 以字符流读/写文件，还是往 URL 连接写 HTML 信息，或从 URL 连接读取参数值，全部会有字符编码 转换。这么做即使增加了编程复杂度，轻易引发混淆，但却是符合国际化思想。 从理论上来说，这些依据字符集设置而进行字符转换不应该产生太多问题。而事实是因为应用程 序实际运行环境不一样，Unicode 和各个当地字符集补充、完善，和系统或应用程序实现不规范 ，转码时出现问题时时困扰着程序员和用户。 2.GB2312-80，GBK，GB18030-
22、汉字字符集 其实处理 JAVA 程序中汉字编码问题方法往往很简单，但了解其背后原因，定位问题，还需 要了解现有汉字编码和编码转换。 GB2312-80 是在中国计算机汉字信息技术发展初始阶段制订，其中包含了大部分常见一、二级 汉字，和 9 区符号。该字符集是几乎全部汉字系统和国际化软件全部支持汉字字符集，这也是 最基础汉字字符集。其编码范围是高位0xa1－0xfe，低位也是 0xa1-0xfe；汉字从 0xb0a1 开始，结 束于 0xf7fe； GBK 是 GB2312-80 扩展，是向上兼容。它包含了 20902 个汉字，其编码范围是
23、 0x8140- 0xfefe，剔除高位 0x80 字位。其全部字符全部能够一对一映射到 Unicode 2.0，也就是说 JAVA 实际 上提供了 GBK 字符集支持。这是现阶段 Windows 和其它部分汉字操作系统缺省字符集，但并不是 全部国际化软件全部支持该字符集，感觉是她们并不完全知道 GBK 是怎么回事。值得注意是它不是 国家标准，而只是规范。伴随 GB18030-国家标准公布，它将在很快未来完成它历史使命。 GB18030-(GBK2K) 在 GBK 基础上深入扩展了汉字，增加了藏、蒙等少数民族字形。 GBK2K 从根本上处理了字位不够，
24、字形不足问题。它有多个特点： ●它并没有确定全部字形，只是要求了编码范围，留待以后扩充。 ●编码是变长，其二字节部分和 GBK 兼容；四字节部分是扩充字形、字位，其编码范围是首 字节 0x81-0xfe、二字节0x30-0x39、三字节 0x81-0xfe、四字节0x30-0x39。 ●它推广是分阶段，首先要求实现是能够完全映射到 Unicode 3.0 标准全部字形。 ●它是国家标准，是强制性。 现在还没有任何一个操作系统或软件实现了 GBK2K 支持，这是现阶段和未来汉化工作内容。 3.JSP/Servlet 汉字编
25、码问题及在 WAS 中处理措施 3.1 常见 encoding 问题现象 网上常出现 JSP/Servlet encoding 问题通常全部表现在 browser 或应用程序端，如: ●浏览器中看到 Jsp/Servlet 页面中汉字怎么全部成了 ’?’ ? ●浏览器中看到 Servlet 页面中汉字怎么全部成了乱码？ ●JAVA 应用程序界面中汉字怎么全部成了方块？ ●Jsp/Servlet 页面无法显示 GBK 汉字。 ●Jsp/Servlet 不能接收 form 提交汉字。 ●JSP/Servle
26、t 数据库读写无法取得正确内容。 隐藏在这些问题后面是多种错误字符转换和处理（除第3个外，是因为 Java font 设置错误引 起）。处理类似字符 encoding 问题，需要了解 Jsp/Servlet 运行过程，检验可能出现问题 各个点。 3.2 JSP/Servlet web 编程时 encoding 问题 运行于Java 应用服务器 JSP/Servlet 为 Browser 提供 HTML 内容，其过程以下图所表示： 其中有字符编码转换地方有： a.JSP 编译。Java 应用服务器将依据 JVM fil
27、e.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 字符乱码问题 。
28、 b.Java 需要被编译为 .class 才能在 JVM 中实施，这个过程存在和a.一样 file.encoding 问 题。从这里开始 servlet 和 jsp 运行就类似了，只不过 Servlet 编译不是自动进行。 c.Servlet 需要将 HTML 页面内容转换为 browser 可接收 encoding 内容发送出去。依靠于各 JAVA App Server 实现方法，有将查询 Browser accept-charset 和 accept-language 参数或 以其它猜方法确定 encoding 值，有则不管。所以 constan
29、t-encoding 可能是最好处理方法。 对于汉字网页，可在 JSP 或 Servlet 中设置 contentType="text/html; charset=GB2312"；假如页面 中有GBK字符，则设置为contentType="text/html; charset=GBK"，因为IE 和 Netscape对GBK支持程 度不一样，作这种设置时需要测试一下。 因为16位 JAVA char在网络传送时高8位会被丢弃，也为了确保Servlet页面中汉字（包含内嵌 和servlet运行过程中得到）是期望内码，能够用 PrintWriter ōut=re
30、s.getWriter() 替换 ServletOutputStream ōut=res.getOutputStream(), PrinterWriter 将依据contentType中指定 charset作转换(ContentType需在此之前指定！);也能够用OutputStreamWriter封装 ServletOutputStream 类并用write(String)输出汉字字符串。 对于 JSP，JAVA Application Server 应该能够确保在这个阶段将嵌入汉字正确传送出去。 d.这是 URL 字符 encoding 问题。假如
31、经过 get/post 方法从 browser 返回值中包含汉字信息 ， servlet 将无法得到正确值。SUN J2SDK 中，HttpUtils.parseName 在解析参数时根本没有考 虑 browser 语言设置，而是将得到值按 byte 方法解析。这是网上讨论得最多 encoding 问题 。因为这是设计缺点，只能以 bin 方法重新解析得到字符串；或以 hack HttpUtils 类方法解 决。参考文章 2、3 全部有介绍，不过最好将其中汉字 encoding GB2312、 CP1381 全部改为 GBK，不然 碰到 GBK 汉字时，还是会有问
32、题。 Servlet API 2.3 提供一个新函数 HttpServeletRequest.setCharacterEncoding 用于在调用 request.getParameter(“param_name”) 前指定应用程序期望 encoding，这将有利于根本处理这个 问题。 WebSphere Application Server 对标准 Servlet API 2.x 作了扩展，提供很好多语言支持。 上述c,d情况，WAS 全部要查询 Browser 语言设置，在缺省情况下zh、zh-cn 等均被映射为 JAVA encodin
33、g CP1381（注意：CP1381 只是等同于 GB2312 一个 codepage，没有 GBK 支持）。这么做我 想是因为无法确定 Browser 运行操作系统是支持GB2312, 还是 GBK，所以取其小。不过实际应用 系统还是要求页面中出现 GBK 汉字，最著名是朱总理名字中“?”(rong2 ，0xe946，\u9555)，所 以有时还是需要将 Encoding/Charset 指定为 GBK。当然 WAS 中变更缺省 encoding 没有上面说 那么麻烦，针对 a,b，参考文章 5 ），在 Application Server 命令行参数中指定 -
34、 Dfile.encoding=GBK 即可； 针对 d，在 Application Server 命令行参数中指定- Ddefault.client.encoding=GBK。假如指定了-Ddefault.client.encoding=GBK，那么c情况下能够不再 指定charset。 3.3 数据库读写时 encoding 问题 JSP/Servlet 编程中常常出现 encoding 问题另一个地方是读写数据库中数据。 流行关系数据库系统全部支持数据库 encoding，也就是说在创建数据库时能够指定它自己字符 集设置，数据库数据以
35、指定编码形式存放。当应用程序访问数据时，在入口和出口处全部会有 encoding 转换。对于汉字数据，应该确保数据完整性。GB2312，GBK，UTF-8 等全部是可选数据库 encoding；假如选择 ISO8859-1(8-bit SBCS)，那么应用程序在写数据之前须将 16Bit 一个汉字或 Unicode 拆分成两个 8-bit 字符，读数据以后则需将两个字节合并起来，同时还有判别其中 SBCS 字符。没有充足利用数据库 encoding 作用，反而增加了编程复杂度，ISO8859-1不是推荐数据 库 encoding。JSP/Servlet编程
36、时，能够先用数据库管理系统提供功效检验其中汉字数据是否正确 。 然后应该注意是读出来数据 encoding，JAVA 程序中通常得到是 Unicode。写数据时则相 反。 3.4 定位问题时常见技巧 定位汉字encoding问题通常采取最笨也是最有效措施——在你认为有嫌疑程序处理后打印字 符串内码。经过打印字符串内码，你能够发觉什么时候汉字字符被转换成Unicode，什么时候 Unicode被转回汉字内码，什么时候一个汉字字成了两个 Unicode 字符，什么时候汉字字符串被转成了 一串问号，什么时候汉字字符串高位被截掉了……
37、 取用适宜样本字符串也有利于区分问题类型。如：”aa啊aa?aa” 等中英相间、GB、GBK特征 字符全部有字符串。通常来说，英文字符不管怎么转换或处理，全部不会失真（假如碰到了，能够尝试着 增加连续英文字母长度）。 4.结束语 其实 JSP/Servlet 汉字encoding 并没有想像那么复杂，即使定位和处理问题没有定规，多种 运行环境也各不尽然，但后面原理是一样。了解字符集知识是处理字符问题基础。不过，伴随 汉字字符集改变，不仅仅是 java 编程，汉字信息处理中问题还是会存在一段时间。 5.参考文章 1) Characte
38、r Problem Review 2) Java 编程技术中汉字问题分析及处理 3) NLS Characters in WebSphere: SBCS/DBCS display on same page 4) GB18030 5) Setting language encoding in web applications: Websphere applications Server 作者介绍 张建芳，软件工程师，毕业于北京理工大学计算机应用学院，有多年汉字当地化经验。您可经过 和她联络。 ////////////////////////////
39、///////////////////////////////////////////////////////// 相关jsp乱码问题处理。 1 最基础乱码问题。 这个乱码问题是最简单乱码问题。通常新会出现。就是页面编码不一致造成乱码。 <%@ page language="java" pageEncoding="UTF-8"%> <%@ page contentType="text/html;charset=iso8859-1"%>