jsp乱码解决专项方案大全文库.doc

资源描述

jsp乱码处理方案大全文库.txt生活是过出来，不是想出来。放得下是曾经，放不下是记忆。不管我在哪里，我离你全部只有一转身距离。一、JSP页面显示乱码下面显示页面(display.jsp)就出现乱码： <html> <head> <title>JSP汉字处理</title> <meta http-equiv="Content-Type" content="text/html; charset=gb2312"> </head> <body> <% out.print("JSP汉字处理"); %> </body> </html> 对不一样WEB服务器和不一样JDK版本，处理结果就不一样。原因：服务器使用编码方法不一样和浏览器对不一样字符显示结果不一样而造成。处理措施：在JSP页面中指定编码方法(gb2312),即在页面第一行加上：<%@ page contentType="text/html; charset=gb2312"%>，就能够消除乱码了。完整页面以下： <%@ page contentType="text/html; charset=gb2312"%> <html> <head> <title>JSP汉字处理</title> <meta http-equiv="Content-Type" content="text/html; charset=gb2312"> </head> <body> <% out.print("JSP汉字处理"); %> </body> </html> 二、表单提交汉字时出现乱码下面是一个提交页面(submit.jsp)，代码以下： <html> <head> <title>JSP汉字处理</title> <meta http-equiv="Content-Type" content="text/html; charset=gb2312"> </head> <body> <form name="form1" method="post" action="process.jsp"> <div align="center"> <input type="text" name="name"> <input type="submit" name="Submit" value="Submit"> </div> </form> </body> </html> 下面是处理页面(process.jsp)代码： <%@ page contentType="text/html; charset=gb2312"%> <html> <head> <title>JSP汉字处理</title> <meta http-equiv="Content-Type" content="text/html; charset=gb2312"> </head> <body> <%=request.getParameter("name")%> </body> </html> 假如submit.jsp提交英文字符能正确显示，假如提交汉字时就会出现乱码。原因：浏览器默认使用UTF -8编码方法来发送请求，而UTF- 8和GB2312编码方法表示字符时不一样，这么就出现了不能识别字符。处理措施:经过request.seCharacterEncoding ("gb2312")对请求进行统一编码，就实现了汉字正常显示。修改后process.jsp代码以下： <%@ page contentType="text/html; charset=gb2312"%> <% request.seCharacterEncoding("gb2312"); %> <html> <head> <title>JSP汉字处理</title> <meta http-equiv="Content-Type" content="text/html; charset=gb2312"> </head> <body> <%=request.getParameter("name")%> </body> </html> 三、数据库连接出现乱码只要包含汉字地方全部是乱码，处理措施：在数据库数据库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网站：总结： 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正確转化为编码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");説明将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=" + .URLEncoder.encode(keywords) 　　然后在接收参数页面使用以下语句接收　　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乱码问题~~~ 作者：佚名起源：本站整理公布时间：-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默认编码了，通常不调整话为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 中汉字编码问题（作者：张建芳，转自IBM DeveloperWorks 中国网站　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- 汉字字符集　　其实处理 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-国家标准公布，它将在很快未来完成它历史使命。　　GB18030-(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 设置错误引起）。处理类似字符 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 内容发送出去。依靠于各 JAVA App Server 实现方法，有将查询 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位 JAVA char在网络传送时高8位会被丢弃，也为了确保Servlet页面中汉字（包含内嵌和servlet运行过程中得到）是期望内码，能够用 PrintWriter ōut=res.getWriter() 替换 ServletOutputStream ōut=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 方法重新解析得到字符串；或以 hack HttpUtils 类方法解决。参考文章 2、3 全部有介绍，不过最好将其中汉字 encoding GB2312、 CP1381 全部改为 GBK，不然碰到 GBK 汉字时，还是会有问题。　　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 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，在 Application Server 命令行参数中指定- 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-bit SBCS)，那么应用程序在写数据之前须将 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特征字符全部有字符串。通常来说，英文字符不管怎么转换或处理，全部不会失真（假如碰到了，能够尝试着增加连续英文字母长度）。 4.结束语　　其实 JSP/Servlet 汉字encoding 并没有想像那么复杂，即使定位和处理问题没有定规，多种运行环境也各不尽然，但后面原理是一样。了解字符集知识是处理字符问题基础。不过，伴随汉字字符集改变，不仅仅是 java 编程，汉字信息处理中问题还是会存在一段时间。 5.参考文章 1) Character 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 作者介绍　　张建芳，软件工程师，毕业于北京理工大学计算机应用学院，有多年汉字当地化经验。您可经过和她联络。　/////////////////////////////////////////////////////////////////////////////////////　相关jsp乱码问题处理。 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.xmlConnector节点增加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="0" 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会

展开阅读全文