jsp乱码解决方案大全VIP

1、一、jsp页面显示乱码下面的显示页面(display.jsp)就出现乱码：jsp的中文处理对不同的web服务器和不同的jdk版本，处理结果就不一样。原因：服务器使用的编码方式不同和浏览器对不同的字符显示结果不同而导致的。解决办法：在jsp页面中指定编码方式(gb2312),即在页面的第一行加上：，就可以消除乱码了。完整页面如下：jsp的中文处理二、表单提交中文时出现乱码下面是一个提交页面(submit.jsp)，代码如下：jsp的中文处理下面是处理页面(process.jsp)代码：jsp的中文处理如果submit.jsp提交英文字符能正确显示，如果提交中文时就会出现乱码。原因：浏览器默认使用

2、utf-8编码方式来发送请求，而utf- 8和gb2312编码方式表示字符时不一样，这样就出现了不能识别字符。解决办法:通过request.secharacterencoding (gb2312)对请求进行统一编码，就实现了中文的正常显示。修改后的process.jsp代码如下：jsp的中文处理三、数据库连接出现乱码只要涉及中文的地方全部是乱码，解决办法：在数据库的数据库url中加上useunicode=true&characterencoding=gbk 就ok了。四、数据库的显示乱码在mysql4.1.0中,varchar类型，text类型就会出现中文乱码，对于varchar类型把它设为b

3、inary属性就可以解决中文问题，对于text类型就要用一个编码转换类来处理，实现如下：public class convert /* 把iso-8859-1码转换成gb2312*/public static string isotogb(string iso)string gb;tryif(iso.equals() | iso = null)return ;elseiso = iso.trim();gb = new string(iso.getbytes(iso-8859-1),gb2312);return gb;catch(exception e)system.err.print(编码转换

4、错误：+e.getmessage();return ;把它编译成class，就可以调用convert类的静态方法isotogb()来转换编码。如果你还有什么不懂之处：我给大家推荐一个好的jsp-java网站：总结：1. 在jsp中如果指定了，那么在改jsp中所有构造的string（不是引用），如果沒有指定编码，那么这些string的编码是a的。 从request的得到的string如果沒有指定request的编码的话，他是iso-8859-1的 从别的地方得到的string是使用原來初始的编码的，比如从数据库得到string,如果数据库的编码是b,那么该string的编码是b而不是a的，也不是

5、系统默认的。 此时，如果要输出的string的编码不是a,那么，很可能显示乱码的，所以首先要将string正確转化为编码a的string,然后输出。2. 在jsp中沒有指定，那么相当于指定了3 servelte中如果执行了像 response.setcontenttype(text/html;charset=a);説明将response的字符输出流编码设置为a,所有要输出的string的编码要转化为a的，否則会得到乱码的。 servelet中从request得到的string的编码和jsp中一样的，但是在servlet java文件中构造的string是使用的系统默认的编码的。在servelt

6、中从外部得到的string 是使用原来的编码的，比如从编码为b的数据库得到的数据是编码为b的,不是a,也不是系统默认的编码。 /转载：jsp中文乱码问题解决方法小结在使用jsp的过程中，最使人头疼的一个问题就是中文乱码问题，以下是我在软件开发中遇到的乱码问题以及解决方法。 1、jsp页面乱码 这种乱码的原因是应为没有在页面里指定使用的字符集编码，解决方法：只要在页面开始地方用下面代码指定字符集编码即可， 2、数据库乱码 这种乱码会使你插入数据库的中文变成乱码，或者读出显示时也是乱码，解决方法如下： 在数据库连接字符串中加入编码字符集 string url=jdbc:mysql:/localho

7、st/digitgulf?user=root&password=root&useunicode=true&characterencoding=gb2312; 并在页面中使用如下代码： response.setcontenttype(text/html;charset=gb2312); request.setcharacterencoding(gb2312); 3、中文作为参数传递乱码 当我们把一段中文字符作为参数传递个另一页面时，也会出现乱码情况，解决方法如下： 在参数传递时对参数编码，比如 rearshres.jsp?keywords= + .urlencoder.encode(keywor

8、ds) 然后在接收参数页面使用如下语句接收 keywords=new string(request.getparameter(keywords).getbytes(8859_1); 4、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.prin

9、tln(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).getbyte

10、s(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 中的汉字编码问题（作者：张建芳，转自i

11、bm developerworks 中国网站2001年04月18日 15:08）网上就 jsp/servlet 中 dbcs 字符编码问题有许多优秀的文章和讨论，本文对它们作一些整理，并结合 ibm websphere application server 3.5（was）的解决方法作一些说明，希望它不是多余的。 1.问题的起源 每个国家（或区域）都规定了计算机信息交换用的字符编码集，如美国的 ascii，中国的 gb2312-80，日本的 jis 等，作为该国家/区域内信息处理的基础，有着统一编码的重要作用。字符编码集按长度分为 sbcs（单字节字符集），dbcs（双字节字符集）两大类。早期

12、的软件（尤其是操作系统），为了解决本地字符信息的计算机处理，出现了各种本地化版本（l10n），为了区分，引进了 lang，codepage 等概念。但是由于各个本地字符集代码范围重叠，相互间信息交换困难；软件各个本地化版本独立维护成本较高。因此有必要将本地化工作中的共性抽取出来，作一致处理，将特别的本地化处理内容降低到最少。这也就是所谓的国际化（i18n）。各种语言信息被进一步规范为 locale 信息。处理的底层字符集变成了几乎包含了所有字形的 unicode。 现在大部分具有国际化特征的软件核心字符处理都是以 unicode 为基础的，在软件运行时根据当时的 locale/lang/cod

13、epage 设置确定相应的本地字符编码设置，并依此处理本地字符。在处理过程中需要实现 unicode 和本地字符集的相互转换，甚或以 unicode 为中间的两个不同本地字符集的相互转换。这种方式在网络环境下被进一步延伸，任何网络两端的字符信息也需要根据字符集的设置转换成可接受的内容。 java 语言内部是用 unicode 表示字符的，遵守 unicode v2.0。java 程序无论是从/往文件系统以字符流读/写文件，还是往 url 连接写 html 信息，或从 url 连接读取参数值，都会有字符编码的转换。这样做虽然增加了编程的复杂度，容易引起混淆，但却是符合国际化的思想的。 从理论上来

14、说，这些根据字符集设置而进行的字符转换不应该产生太多问题。而事实是由于应用程序的实际运行环境不同，unicode 和各个本地字符集的补充、完善，以及系统或应用程序实现的不规范，转码时出现的问题时时困扰着程序员和用户。 2.gb2312-80，gbk，gb18030-2000 汉字字符集 其实解决 java 程序中的汉字编码问题的方法往往很简单，但理解其背后的原因，定位问题，还需要了解现有的汉字编码和编码转换。 gb2312-80 是在国内计算机汉字信息技术发展初始阶段制定的，其中包含了大部分常用的一、二级汉字，和 9 区的符号。该字符集是几乎所有的中文系统和国际化的软件都支持的中文字符集，这也

15、是最基本的中文字符集。其编码范围是高位0xa10xfe，低位也是 0xa1-0xfe；汉字从 0xb0a1 开始，结束于 0xf7fe； gbk 是 gb2312-80 的扩展，是向上兼容的。它包含了 20902 个汉字，其编码范围是 0x8140-0xfefe，剔除高位 0x80 的字位。其所有字符都可以一对一映射到 unicode 2.0，也就是说 java 实际上提供了 gbk 字符集的支持。这是现阶段 windows 和其它一些中文操作系统的缺省字符集，但并不是所有的国际化软件都支持该字符集，感觉是他们并不完全知道 gbk 是怎么回事。值得注意的是它不是国家标准，而只是规范。随着 gb

16、18030-2000国标的发布，它将在不久的将来完成它的历史使命。 gb18030-2000(gbk2k) 在 gbk 的基础上进一步扩展了汉字，增加了藏、蒙等少数民族的字形。gbk2k 从根本上解决了字位不够，字形不足的问题。它有几个特点： 它并没有确定所有的字形，只是规定了编码范围，留待以后扩充。 编码是变长的，其二字节部分与 gbk 兼容；四字节部分是扩充的字形、字位，其编码范围是首字节 0x81-0xfe、二字节0x30-0x39、三字节 0x81-0xfe、四字节0x30-0x39。 它的推广是分阶段的，首先要求实现的是能够完全映射到 unicode 3.0 标准的所有字形。 它是国

17、家标准，是强制性的。 现在还没有任何一个操作系统或软件实现了 gbk2k 的支持，这是现阶段和将来汉化的工作内容。 3.jsp/servlet 汉字编码问题及在 was 中的解决办法 3.1 常见的 encoding 问题的现象 网上常出现的 jsp/servlet encoding 问题一般都表现在 browser 或应用程序端，如: 浏览器中看到的 jsp/servlet 页面中的汉字怎么都成了 ? ? 浏览器中看到的 servlet 页面中的汉字怎么都成了乱码？ java 应用程序界面中的汉字怎么都成了方块？ jsp/servlet 页面无法显示 gbk 汉字。 jsp/servlet

18、不能接收 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.e

19、ncoding 值读取 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

20、 才能在 jvm 中执行，这个过程存在与a.同样的 file.encoding 问题。从这里开始 servlet 和 jsp 的运行就类似了，只不过 servlet 的编译不是自动进行的。 c.servlet 需要将 html 页面内容转换为 browser 可接受的 encoding 内容发送出去。依赖于各 java app server 的实现方式，有的将查询 browser 的 accept-charset 和 accept-language 参数或以其它猜的方式确定 encoding 值，有的则不管。因此 constant-encoding 也许是最好的解决方法。对于中文网页，可在 j

21、sp 或 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.getoutputs

22、tream(), printerwriter 将根据contenttype中指定的charset作转换(contenttype需在此之前指定！);也可以用outputstreamwriter封装 servletoutputstream 类并用write(string)输出汉字字符串。 对于 jsp，java application server 应当能够确保在这个阶段将嵌入的汉字正确传送出去。 d.这是 url 字符 encoding 问题。如果通过 get/post 方式从 browser 返回的值中包含汉字信息， servlet 将无法得到正确的值。sun的 j2sdk 中，httputi

23、ls.parsename 在解析参数时根本没有考虑 browser 的语言设置，而是将得到的值按 byte 方式解析。这是网上讨论得最多的 encoding 问题。因为这是设计缺陷，只能以 bin 方式重新解析得到的字符串；或者以 hack httputils 类的方式解决。参考文章 2、3 均有介绍，不过最好将其中的中文 encoding gb2312、 cp1381 都改为 gbk，否则遇到 gbk 汉字时，还是会有问题。 servlet api 2.3 提供一个新的函数 httpserveletrequest.setcharacterencoding 用于在调用 request.getp

24、arameter(“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，所以取其小。但是实

25、际的应用系统还是要求页面中出现 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，

26、那么c情况下可以不再指定charset。 3.3 数据库读写时的 encoding 问题 jsp/servlet 编程中经常出现 encoding 问题的另一个地方是读写数据库中的数据。 流行的关系数据库系统都支持数据库 encoding，也就是说在创建数据库时可以指定它自己的字符集设置，数据库的数据以指定的编码形式存储。当应用程序访问数据时，在入口和出口处都会有 encoding 转换。对于中文数据，应当保证数据的完整性。gb2312，gbk，utf-8 等都是可选的数据库 encoding；如果选择 iso8859-1(8-bit sbcs)，那么应用程序在写数据之前须将 16bit 的一

27、个汉字或 unicode 拆分成两个 8-bit 的字符，读数据之后则需将两个字节合并起来，同时还有判别其中的 sbcs 字符。没有充分利用数据库 encoding 的作用，反而增加了编程的复杂度，iso8859-1不是推荐的数据库 encoding。jsp/servlet编程时，可以先用数据库管理系统提供的功能检查其中的中文数据是否正确。 然后应当注意的是读出来的数据的 encoding，java 程序中一般得到的是 unicode。写数据时则相反。 3.4 定位问题时常用的技巧 定位中文encoding问题通常采用最笨的也是最有效的办法在你认为有嫌疑的程序处理后打印字符串的内码。通过打印字

28、符串的内码，你可以发现什么时候中文字符被转换成unicode，什么时候unicode被转回中文内码，什么时候一个中文字成了两个 unicode 字符，什么时候中文字符串被转成了一串问号，什么时候中文字符串的高位被截掉了 取用合适的样本字符串也有助于区分问题的类型。如：”aa啊aa?aa” 等中英相间、gb、gbk特征字符均有的字符串。一般来说，英文字符无论怎么转换或处理，都不会失真（如果遇到了，可以尝试着增加连续的英文字母长度）。 4.结束语 其实 jsp/servlet 的中文encoding 并没有想像的那么复杂，虽然定位和解决问题没有定规，各种运行环境也各不尽然，但后面的原理是一样的。了

29、解字符集的知识是解决字符问题的基础。不过，随着中文字符集的变化，不仅仅是 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 作者简介 张建芳，软件工程师，毕业于北京

30、理工大学计算机应用学院，有多年中文本地化经验。您可通过 jfzhang 与他联系。 / 关于jsp乱码问题的解决。1 最基本的乱码问题。这个乱码问题是最简单的乱码问题。一般新会出现。就是页面编码不一致导致的乱码。中文问题 我是个好人三个地方的编码。第一个地方的编码格式为jsp文件的存储格式。eclipse会根据这个编码格式保存文件。并编译jsp文件，包括里面的汉字。第二处编码为解码格式。因为存为utf-8的文件被解码为iso8859-1，这样 如有中文肯定出乱码。也就是必须一致。而第二处所在的这一行，可以没有。缺省也是使用iso8859-1的编码格式。所以如果没有这一行的话，“我是个好人”也会

31、出现乱码。必须一致才可以。 第三处编码为控制浏览器的解码方式。如果前面的解码都一致并且无误的话，这个编码格式没有关系。有的网页出现乱码，就是因为浏览器不能确定使用哪种编码格式。因为页面有时候会嵌入页面，导致浏览器混淆了编码格式。出现了乱码。2 表单使用post方式提交后接收到的乱码问题这个问题也是一个常见的问题。这个乱码也是tomcat的内部编码格式iso8859-1在捣乱，也就是说post提交时，如果没有设置提交的编码格式，则会以iso8859-1方式进行提交，接受的jsp却以utf-8的方式接受。导致乱码。既然这样的原因，下面有几种解决方式，并比较。a 接受参数时进行编码转换string

32、str = new string(request.getparameter(something).getbytes(iso-8859-1),utf-8) ； 这样的话，每一个参数都必须这样进行转码。很麻烦。但确实可以拿到汉字。b 在请求页面上开始处，执行请求的编码代码， request.setcharacterencoding(utf-8)，把提交内容的字符集设为utf8。这样的话，接受此参数的页面就不必在转码了。直接使用string str = request.getparameter(something)；即可得到汉字参数。但每页都需要执行这句话。这个方法也就对post提交的有效果，对于g

33、et提交和上传文件时的enctype=multipart/form-data是无效的。稍后下面单独对这个两个的乱码情况再进行说明。c 为了避免每页都要写request.setcharacterencoding(utf-8)，建议使用过滤器对所有jsp 进行编码处理。这个网上有很多例子。请大家自己查阅。3 表单get提交方式的乱码处理方式。如果使用get方式提交中文，接受参数的页面也会出现乱码，这个乱码的原因也是tomcat的内部编码格式iso8859-1导致。tomcat会以get的缺省编码方式iso8859-1对汉字进行编码，编码后追加到url，导致接受页面得到的参数为乱码/、。解决办法：a

34、 使用上例中的第一种方式，对接受到的字符进行解码，再转码。b get走的是url提交，而在进入url之前已经进行了iso8859-1的编码处理。要想影响这个编码则需要在server.xml的connector节点增加usebodyencodingforuri=true 属性配置，即可控制tomcat对get方式的汉字编码方式，上面这个属性控制get提交也是用request.setcharacterencoding(utf-8)所设置的编码格式进行编码。所以自动编码为utf-8，接受页面正常接受就可以了。但我认为真正的编码过程是，tomcat又要根据里面所设置的uriencoding=”utf-

35、8”再进行一次编码，但是由于已经编码为utf-8，再编码也不会有变化了。如果是从url获取编码，接受页面则是根据uriencoding=”utf-8”来进行解码的。4 上传文件时的乱码解决 上传文件时，form表单设置的都是enctype=multipart/form-data。这种方式以流方式提交文件。如果使用apach的上传组件，会发现有很多乱码想象。这是因为apach的先期commons-fileupload.jar有bug，取出汉字后进行解码，因为这种方式提交，编码又自动使用的是tomcat缺省编码格式iso-8859-1。但出现的乱码问题是： 句号，逗号，等特殊符号变成了乱码，汉字如

36、果数量为奇数，则会出现乱码，偶数则解析正常。 解决方式： 下载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.js

37、p里面直接使用string name）；得到的就是乱码。因为规定了必须是utf-8才可以，所以，这个转向应该这样写： response.sendderect（“/a.jsp?name=urlencode.encode(“张大维”,”utf-8”)；才可以。如果不设置这个参数uriencoding=”utf-8”， 会怎么样呢? 不设置则就使用了缺省的编码格式iso8859-1。问题又出来了，第一就是参数值的个数如果是奇数个数，则就可以正常解析，如果使偶数个数，得到最后字符就是乱码。还有就是如果最后一个字符如果是英文，则就能正常解析，但中文的标点符号仍出现乱码。权宜之计，如果您的参数中没有中文标

38、点符号，则可以在参数值最后加一个英文符号来解决乱码问题，得到参数后再去掉这个最后面的符号。也可以凑或使用。6 脚本代码关于url请求，接受到的参数乱码脚本中也会进行页面转向的控制，也会涉及到附带参数，并在接受页面解析这个参数的情况。如果这个汉字参数不进行uriencoding=”utf-8”所指定的编码处理，则接受页面接受到的汉字也是乱码。脚本处理编码比较麻烦，必须有相应的编码脚本对应文件，然后调用脚本中的方法对汉字进行编码即可。7 关于jsp在myeclipse中打开的乱码问题对于一个已经存在的项目，jsp文件的存储格式可能是utf-8。如果新安装的eclipse，则缺省打开使用的编码格式都

39、是iso8859-1。所以导致jsp里面的汉字出现乱码。这个乱码比较容易解决，直接到eclipse3.1的偏好设置里面找到general-edidor，设置为您的文件打开编码为utf-8即可。eclipse会自动重新以新的编码格式打开。汉字即可正常显示。8 关于html页面在eclipse中打开出现乱码情况由于大部分页面都是由dreamweaver制作，其存储格式跟eclipse的识别有差别导致。一般这种情况，在eclipse中新建一个jsp，直接从dreamweaver复制页面内容粘贴到jsp即可。/jsp中文乱码问题的解决办法 jsp中java中文编码问题的个人经验|终于看到一个完全解决的

40、方案四月 5th, 2006 =开发java应用出现乱码是很常见的，毕竟现在unicode的使用还不是很广泛，在使用gb2312（包含了gbk简体，big5繁体）的系统中要正确实现中文的display和数据库的存储是最基本的要求。=1，首先developer要明确自己为什么会遇到乱码，遇到什么样的乱码（无意义的符号还是一串问号或者其它什么东西）。新手遇到一堆很乱的字符时通常不知所措，最直接的反映就是打开google搜索”java中文”（这个字符串在搜索引擎上的查询频率非常高），然后一个一个的去看别人的解决方法。这样做没有错，但是很难达到目的，原因下面会提到。总之，出现乱码的原因是非常多的，解决

41、的方法也完全不一样，要解决问题必须先分析自己的”上下文环境”。=2，具体说来，需要哪些信息才能确定项目中的乱码的根源。a，开发者所用的操作系统b，j2ee容器的名称，版本c，数据库的名称，版本（精确版本）以及jdbc驱动的版本d，出现乱码的source code（比如是system out 出来的，还是jsp页面中的，如果是jsp中的，那么头部声明的情况也很重要）=3，如何初步分析乱码出现的原因。有了上述的信息，基本上就可以发帖求助了，相信放到javaworld等论坛上，很快就会有高手给你提出有效的解决方案的。当然不能总靠发帖求助，也要试试自行解决问题。如何下手呢？a，分析一下你的”乱码”到底

42、是什么编码。这个其实不难，比如system.out.println(teststring);这一段出现了乱码，那么不妨用穷举法猜测一下它的实际编码格式。system.out.println(new string(teststring.getbytes(”iso-8859-1),”gb2312);system.out.println(new string(teststring.getbytes(”utf8),”gb2312);system.out.println(new string(teststring.getbytes(”gb2312),”gb2312);system.out.println

43、(new string(teststring.getbytes(”gbk”),”gb2312);system.out.println(new string(teststring.getbytes(”big5),”gb2312);等等，上述代码的意思是用制定的编码格式去读取teststring这个”乱码”，并转换成gb2312（此处仅以中文为例）然后你看哪一个转换出来的结果是ok的，那就。b，如果用上面的步骤能得到正确的中文，说明你的数据肯定是在的，只不过是界面中没有正确显示而已。那么第二步就该纠正你的view部分了，通常需要检查的是jsp中是否选择了正确的页面编码。在此要声明被很多人误解的一点

44、，那就是指令和两者的不同。通常网上的很多文章在提到中文问题时都是说数据库中选择unicode或者gb2312存储，同时在jsp中用page指令声明编码就可以解决。但是我觉得这种说法很不负责任，害的我费了n多时间为本来并不存在的乱码而郁闷。实际上page的作用是在jsp被编译成为html的过程中提供编码方式让java来”读取”表达式当中的string（有点类似于上面的第三个语句的作用），而meta的作用是众所周知的为ie浏览器提供编码选择，是用来”显示”最后的数据的。但是没有看到有人提醒这一点，我一直把page当成meta在用，导致本来是iso-8859的数据，被page指令读成gb2312，于

45、是乱码，所以又加了编码转化的函数把所有的string数据都从iso8859转到gb2312（为什么这么转，当时也没考虑这么多，因为这么做可以正常显示了，所以就这么改了，呵呵当时实在没有时间慢慢排查问题了）。=4，数据库选择什么样的编码比较好。目前流行的db主要有sql server，mysql，oracle，db2等，其中mysql作为免费db中的老大，性能和功能是得到公认的，安装配置比较方便，相应的driver也比较完善，性价比是绝对的ok。所以就以mysql为例。我个人建议采用mysql的默认编码来存储，也就是iso-8859-1（在mysql的选项中对应于latin-1）。理由主要有这么几个，一是iso-8859-1对中文