jsp乱码问题及其解决办法word精品文档12页

jsp乱码问题及其解决办法jsp乱码问题及其解决办法2019年04月09日星期五下午05：32
困扰已久的乱码问题终于得到解决，希望下次出现更多问题，解决问题
的过程很愉快！
关于jsp乱码问题的解决2009-01-22 21：32关于jsp乱码问题的解决。

1最基本的乱码问题。

这个乱码问题是最简单的乱码问题。

一般新会出现。

就是页面编码不一
致导致的乱码。

%@page language="java"pageEncoding="UTF-8"%
%@page contentType="text/html；charset=gb2312"%
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.getParamete("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.xml的Connector节点增加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="20000"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会自动重新以新的编码格式打开。

汉字即可正
常显示。

8关于html页面在eclipse中打开出现乱码情况由于大部分页面都是由dreamweaver制作，其存储格式跟eclipse的识别有差别导致。

一般这种情况，在eclipse中新建一个jsp，直接从dreamweaver复制页面内容粘贴到jsp即可。

///////////////////////////////////////////////////////////////
///////////////////////////jsp中文乱码问题的解决办法jsp中java中文
编码问题的个人经验|终于看到一个完全解决的方案四月5th,2019==开发java
应用出现乱码是很常见的，毕竟现在unicode的使用还不是很广泛，在使用
gb2312(包含了gbk简体，big5繁体)的系统中要正确实现中文的display和
数据库的存储是最基本的要求。

==1，首先developer要明确自己为什么会遇到乱码，遇到什么样的乱码(无意义的符号还是一串问号或者其它什么东西)。

新手遇到一堆很乱的字符时
通常不知所措，最直接的反映就是打开google搜索"java中文"(这个字符串
在搜索引擎上的查询频率非常高)，然后一个一个的去看别人的解决方法。

这
样做没有错，但是很难达到目的，原因下面会提到。

总之，出现乱码的原因是
非常多的，解决的方法也完全不一样，要解决问题必须先分析自己的"上下文
环境"。

==2，具体说来，需要哪些信息才能确定项目中的乱码的根源。

a，开发
者所用的操作系统b，j2ee容器的名称，版本c，数据库的名称，版本(精确
版本)以及jdbc驱动的版本d，出现乱码的source code(比如是system out
出来的，还是jsp页面中的，如果是jsp中的，那么头部声明的情况也很重要) ===3，如何初步分析乱码出现的原因。

有了上述的信息，基本上就可以
发帖求助了，相信放到javaworld等论坛上，很快就会有高手给你提出有效的
解决方案的。

当然不能总靠发帖求助，也要试试自行解决问题。

如何下手呢?a，分析一下你的"乱码"到底是什么编码。

这个其实不难，比如
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(new String(testString.getBytes("GBK"),"gb2312〃))；System.out.println(new
String(testString.getBytes("BIG5〃),"gb2312〃))；等等，上述代码的意
思是用制定的编码格式去读取testString这个"乱码"，并转换成gb2312(此
处仅以中文为例)然后你看哪一个转换出来的结果是ok的，那就。

b，如果用上面的步骤能得到正确的中文，说明你的数据肯定是在的，只
不过是界面中没有正确显示而已。

那么第二步就该纠正你的view部分了，通
常需要检查的是jsp中是否选择了正确的页面编码。

在此要声明被很多人误解
的一点，那就是%@page contentType="text/html；charset=GB2312〃% 指令和META http-equiv=Content-Type content="text/html；
charset=gb2312〃两者的不同。

通常网上的很多文章在提到中文问题时都是说
数据库中选择unicode或者gb2312存储，同
时在jsp中用page指令声明编码就可以解决。

但是我觉得这种说法很不
负责任，害的我费了N多时间为本来并不存在的乱码而郁闷。

实际上page的
作用是在jsp被编译成为html的过程中提供编码方式让java来"读取"表达式
当中的String(有点类似于上面的第三个语句的作用)，而meta的作用是众所
周知的为IE浏览器提供编码选择，是用来"显示"最后的数据的。

但是没有看
到有人提醒这一点，我一直把page当成meta在用，导致本来是iso-8859的
数据，被page指令读成gb2312，于是乱码，所以又加了编码转化的函数把所
有的string数据都从iso8859转到gb2312(为什么这么转，当时也没考虑这
么多，因为这么做可以正常显示了，所以就这么改了，呵呵当时实在没有时间
慢慢排查问题了)。

==，数据库选择什么样的编码比较好。

目前流行的DB主要有sql server，mysql，oracle，DB2等，其中mysql作为免费DB中的老大，性能和功能是得
到公认的，安装配置比较方便，相应的driver也比较完善，性价比是绝对的OK。

所以就以mysql为例。

我个人建议采用mysql的默认编码来存储，也就是iso-8859-1(在mysql的选项中对应于latin-1)。

理
由主要有这么几个，一是iso-8859-1对中文的支持不错；二是跟java
中的默认编码一致，至少在很多地方免除了转换编码的麻烦；三是默认的比较
稳定，兼容性也更好，因为多编码的支持是由具体的DB产品提供的，别说跟
其它的DB会不兼容，即使自身的不同版本也可能出现兼容性的问题。

例如mysql 4.0以前的产品中，很多中文的解决方案是利用connection
中的characterEncoding字段来制定编码，比如gb2312什么的，这样是ok 的，因为原数据都是ISO8859_1编码，jdbc驱动会采用url里面指定的character set来进行编码，resultSet.getString(*)取出的就是编码后的字
符串。

这样就直接拿到gb2312的数据了。

但是mysql 4.1的推出给很多dbadmin带来了不小的麻烦，因为mysql4.1支持column level的characterset，每个table,column都可以指定编码，不指定就是ISO8895_1，因此jdbc取出数据后会根据column的character set来进行编码，而不再是
用一个全局的参数来取所有的数据了。

这从另一个方面也说明了乱码问题的产
生实在是很复杂的事情，原因太多了。

我也只是针对自己遇
jsp中文问题解决之道[转载]
和Java一样，JSP是目前比较热门的一个话题。

它是一种在服务器端编
译执行的Web设计语言，因为脚本语言采用了Java，所以JSP继承了Java的
所有优点。

可是在使用JSP程序的过程中，常遇到中文乱码问题，很多人为此
头疼不已，初学的时候我就深受其害，而且使用平台不同，中文乱码问题的解
决方法也不同，无形中增加了学习JSP的难度。

其实，在彻底了解相关原因后，问题还是比较容易解决的。

，以下是我总结的解决方法，相信对读者会有一定
的借鉴意义。

(因为我使用得最多的是Tomcat环境，所以主要是以Tomcat为例，其它的环境只会提及一下，但解决办法也是差不多的！每个国家(或区域)
都规定了计算机信息交换用的字符编码集，如美国的扩展ASCII码、中国的
GB2312-80、日本的JIS等，作为该国家(区域)信息处理的基础，有着统一编
码的重要作用。

由于各本地字符集代码范围重叠，相互间信息交换困难，软件
本地化版本独立维护成本较高。

因此有必要将本地化工作中的共性抽取出来，
做一致性处理，将特殊的本地化处理内容降低到最少，这就是所谓的国际化
(I18N)。

各种语言信息被规范为本地信息，而底层字符集采用包含了所有字符
的Unicode。

相信了解JSP代码的读者ISO8859-1一定不陌生，ISO8859-1是
我们平时使用比较多的一个CodePage，它属于西欧语系。

GB2312-80是在国内
计算机汉字信息技术发展初始阶段制订的，其中包含了大部分常用的一、二级
汉字和9区的符号。

该字符集是几乎所有的中文系统和国际化的软件都支持的
中文字符集，这也是最基本的中文字符集。

GBK是GB2312-80的扩展，是向上
兼容的。

它包含了20902个汉字，其编码范围是0x8140~0xFEFE，剔除高位
0x80的字位，其所有字符都可以一对一映射到Unicode 2.0，也就是说Java
实际上提供了对GBK字符集的支持。

GB18030-2000(GBK2K)在GBK的基础上进
一步扩展了汉字，增加了藏、蒙等少数民族的文字。

GBK2K从根本上解决了字
位不够、字形不足的问题。

1.Tomcat 4开发平台这个版本应该是我们经常用
到的版本，所以讨论得会比较详细。

Windows 98/2000下的Tomcat 4以上版
本都会出现中文问题(而在Linux下和Tomcat 3.x中则没有问题)，主要表现
是页面显示乱码。

为解决这个问题，最简单的方法就是在每个JSP的页面开始
处加上%@page language="Java"
contentType="text/html；charset=gb2312"%。

不过，这还不够，虽然
这时显示了中文，但是发现从数据库读出的字段变成了乱码。

经过分析发现：
在数据库中保存的中文字符是正常的，数据库用ISO8859-1字符集存取数据，
而Java程序在处理字符时默认采用统一的ISO8859-1字符集(这也体现了
Java国际化思想)，所以在数据添加的时候Java和数据库都是以ISO8859-1
方式处理，这样不会出错。

但是在读取数据的时候就出现问题了，因为数据读
出也采用ISO8859-1字符集，而JSP的文件头中有语句
%@page language="Java"contentType="text/html；charset=gb2312"%，这说明页面采用GB2312的字符集显示，这样就和读出的数据不一样。

这时页
面显示从数据库中读出的字符是乱码，解决的方法是对这些字符转码，从
ISO8859-1转成GB2312，就可以正常显示了。

这个解决办法对很多平台具有通
用性，读者可以灵活运用。

具体的方法会在以下详细讲解。

另外，对于不同的
数据库如SQLServer，Oracle，Mysql，Sybase等，字符集的选择很重要。

如
果考虑多语言版本，数据库的字符集就应该统一采用ISO8859-1，需要输出的
时候在不同的字符集之间做转换就可以了。

以下是针对不同平台的总结：
(1)JSWDK只适合于普通开发，稳定性和其他问题可能不如商业软件。

由于JDK 1.3版性能要好于
JDK 1.2.2很多，并且对中文的支持也较好，所以应该尽量采用。

现在
jdk已经出到1.4版本了，所以如果允许最好升级到最新的版本，这样对中文
的也会较好，而且还可以得到更多的支持。

(2)Tomcat仅仅是一个对JSP 1.1、Servlet 2.2标准的实现,我们不应该要求这个免费软件在细节和性能上都面
面俱到,它主要考虑英文用户,这也是为什么不做特殊转换，汉字用URL方法传递就有问题的原因。

大部分IE浏览器缺省始终以UTF-8发送,这似乎是
Tomcat的一个不足,另外Tomcat不管当前的操作系统是什么语言,都按
ISO8859去编译JSP,似乎也欠妥。

2.JSP代码的中文处理(1)如果与数据无关
的操作，可以在页面首行加入(2)将Form中的值传送到数据库中再取出来后全变成了"?"。

Form用POST提交数据，代码中使用了语句：String
st=new(request.getParameter("name").getBytes("ISO8859_1"))，而且也声明了charset=gb2312。

要处理Form中传递的中文参数，应该在JSP中加入下
面的代码，另外定义一个专门解决这个问题的
getStr类，然后对接收到的参数进行转换：String
keyword1=request.getParameter("keyword1")；keyword1=getStr(keyword1)；这样就可以解决问题了，代码如下：%@page contentType="text/html；charset=gb2312"%%！public String getStr(String str){try{String
temp_p=str；byte temp_t=temp_p.getBytes("ISO8859-1")；String
temp=new String(temp_t)；return temp；}catch(Exception
e){}return"NULL"；}%%--测试--%%String keyword="创联网络技术中心欢迎
您的到来"；String keyword1=request.getParameter("keyword1")；
keyword1=getStr(keyword1)；out.print(keyword)；out.print(keyword1)；%另外，流行的关系数据库系统都支持数据库Encoding，也就是说在创建数据
库时可以指定它自己的字符集设置，数据库的数据以指定的编码形式存储。

当
应用程序访问数据时，在入口和出口处都会有Encoding转换。

对于中文数据，数据库字符编码的设置应当保证数据的完整性。

GB2312、GBK、UTF-8等都是
可选的数据库Encoding，也可以选择ISO8859-1(8-bit)，但会增加了编程的
复杂度，ISO8859-1不是推荐的数据库Encoding。

在JSP/Servlet编程时，可以先用数据库管理系统提供的管理功能检查其中的中文数据是否正确。

(3)JDBC Driver的字符转换目前大多数JDBC Driver采用本地编码格式
来传输中文字符，例如中文字符"0x4175"会被转成"0x41"和"0x75"进行传输。

因此需要对JDBC Driver返回的字符以及要发给JDBC Driver的字符进行转换。

当用JDBC Driver向数据库中插入数据时，需要先将Unicode转成Native code；当JDBC Driver从数据库中查询数据时，则需要将Native code转换成Unicode。

下面给出了这两种转换的实现：String native2Unicode(String
s){if(s==null||s.length()==0){return null；}byte buffer=new
byte[s.length()]；for(int i=0；i s.length()；
i++){if(s.charAt(i)=0x100){c=s.charAt(i)；byte buf=(""+c).getBytes()；buffer[j++]=(char)buf[0]；
buffer[j++]=(char)buf[1]；}else{buffer[j++]=s.charAt(i)；}}return new String(buffer,0,j)；}要注意的是，有些JDBC Driver如果通过JDBC Driver Manager设置了正确的字符集属性，以上方法就不需要了。

具体情况
可参考相关JDBC的资料。

其实理解了，中文乱码就这么一回事！反复使用就
会摸出一定的门道了！我觉得以上的三种方法，只要你真的能弄懂，在遇到中
文问题时，在这三种方法多试尝，我保证你不再会使这种中文问题所烦！以上
只是自己的一些经验所谈，如果有什么不对，希望能提出，共同学习！
我的乱码之路--JSP与MySQL交互的中文乱码解决方案及总结首先实现了一个StringConvert bean(GBtoISO()和ISOtoGB()两个方法)，解决了与MySQL数据库交互的时候的部分中文乱码问题：在JSP程序中读取MySQL的中
文内容，用这两个方法可以解决乱码问题。

但是从JSP写入到MySQL的中文内容都成了乱码，并且再读出来的时候也显示为"?"，在这里应该出现了编码转
换过程中的字符信息丢失。

郁闷的是，我在命令行窗口中登陆到MySQL后，执行如"INSERT INTO customerVALUES('字符',.)"这样的语句时，写入到数据表中的中文内容又是显示正常的！数据库使用的字符集是utf8。

碰壁多次，终
于发现一条解决问题的路径：查看MySQL手册的时候，看到一条这样的语句：Toallow multiple character sets to be sent from the
client,the"UTF-8"encoding should be used,either by
configuring"utf8"as the defaultserver character set,or by
configuring the JDBC driver to use"UTF-8"through the characterEncoding property.
此外，在查阅《MySQL权威指南》时，发现在查询语句中可以使用这样的语法将字符串转换到一个
给定的字符集：_charset str。

其中charset必须是服务器支持的某个字符集。

在本例中，shopdb数据
库使用的默认字符集是utf8
，于是开始测试：
先输入INSERT INTO publish Values('8',_gb2312'高等教育出版社')写入后中文变成"?
再试INSERT INTO publish Values('8',_gbk'高等教育出版社')结果同
上
INSERT INTO publish Values('8',_utf8'高等教育出版社')这下更干脆，什么都没有！
快疯了！没办法，用show character set；命令查看MySQL支持的字符集，心想我都试一遍总
有一个能成功吧。

浏览了一下，发现没有几个熟悉的字符集，就只剩下
一个latin1(ISO-8859-1)比较常
见了，不会是它吧，一试之下果然便是。

INSERT INTO publish Values('8',_latin1'高等教育出版社')输入中文
能够正确显示。

这下总算找到方法了，把Tomcat下配置的数据库连接池的url改为
".characterEncoding=UTF-8"，然后把写入数据库的中文内容用
String s2=new String(s1.getBytes("gb2312"),"ISO-8859-1")进行转码，其中s1为中文字符串.然后再写入到数据库一切显示正常。

为解决这个问题查看了n多资料，现作一个总结：由于字符集和字符编
码方式的不同，在OS以及程序之间传递数据(尤其是multiple character
sets中的数据)时便会产生乱码以及字符信息的丢
失.解决这个问题的关键便是了解数据输出端和接收端使用的字符集和字
符编码方式，如果这两种编码方式不同，便需要在数据出口或入口处进行转码。

一般的说，在编写代码,编译，以及运行期间都会字符数据的传递，因此需要
特别小心。

在编写代码的时候，你可能会使用某种开发工具，例如我正在使用的Eclipse.或许在写的时候一切正常，可是一旦保存后再次打开文档，所有的中
文字符都变成了乱码。

这是因为在编写的时候，这些字符数据都在内存的某个stream中，ok，这没问题，可是保存的时候这个stream中的数据会被写入到硬盘，使用的就是你的开发工具默认的编码方式，如果很不幸你的开发
工具默认编码方式是ISO-8859-1，中文字符信息就不能正确地存储。

Eclipse
中可以这样查看并修改默认字符编码方式：Project-Properties-info，这里有"default encoding for text file"。

如果设置为GBK，那么编写代码并保
存这关就过了。

对于JSP程序而言，编写完代码后就交给Container，首先它们会被转成.java文件，然后编译成.class才能提交给服务器执行.这个过程也存在字
符编码问题.java编译器(javac)使用操作系统的语言环境作为默认的字符编
码方式，JRE(Java Runtime Environment)也是这样。

只有当编译和运行环境
的字符编码方式与存储源文件的编码方式相同时，中文字符才能正确地显示。

否则就需要在运行时进行转码，使它们使用兼容的编码。

这里的设置可以分为
几个层次：操作系统层支持的语言，这是最重要的，因为它会影响JVM的默认字符编码方式，同时对字符的显示，如字体等有直接影响；J2EE服务器层，
大多数服务器都可以对字符编码进行自定义的配置，例如Tomcat就可以通过web.xml中设置javaEncoding参数设置字符编码，默认是UTF-8.
IE也可以设置成总是使用UTF-8编码来发送请求.应用程序层，每个配置在服务器下的程序都可以设置自己的编码方式，这个我目前还没有用到，以后
再学习。

运行时的转码，运行时期，应用程序很可能需要与外部系统进行交互，例如对数据库进行读写，对外部文件进行读写.在这些情况下，应用程序免不
了要和外部系统进行数据交换。

那么对于中文字符，数据出入口的编码方式就
显得特别重要了。

一般外部系统都有自己的字符编码方式，我的例子中配置的MySQL就是使用的UTF-8编码。

JSP页面通过设定"charset=gb2312",使用
gb2312编码，在它与数据库交互的时候就需要进行显式的转码才能正确处理
中文字符。

补充：
JSP写入SQL数据库乱码问题2019年09月02日星期日23：55新建个类，从页面表单中获取数据后调用此类的convert()方法进行转换，然后再写入数
据库！public class Str{public String convert(String str){byte
newstr=new byte[str.length()]；for(int i=0；i str.length()；
i++){newstr[i]=(byte)str.charAt(i)；}return new String(newstr)；}}或
者这种方法：页面上%@page pageEncoding="GBK"%Action里
request.setCharacterEncoding("GBK")；然后再去读取里边的数据2019年04月09日星期五下午05：39|
别用记事本来编辑源码，不然保存的都是GB2312用eclisp或RAD7.0来编辑并且保存，这样就可以保存成你想要的编码文件了，通过%@page language="java"pageEncoding="UTF-8"%指定页面保存类型，通过%@page contentType="text/html；charset=UTF-8"%指定页面显示类型
特别声明：
1：资料来源于互联网，版权归属原作者
2：资料内容属于网络意见，与本账号立场无关
3：如有侵权，请告知，立即删除。