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（为
什么这么转，当时也没考虑这么多，因为这么做可以正常显示了，所以就这么改了，呵呵当时实在没有
时间慢慢排查问题了）。
===========================
===
4，数据库选择什么样的编码比较好。
目前流行的DB主要有sqlserver，mysql，oracle，DB2等，其中mysql作为免费DB中的老大，性能和功
能是得到公认的，安装配置比较方便，相
应的driver也比较完善，性价比是绝对的OK。
所以就以mysql为例。
我个人建议采用mysql的默认编码来存储，也就是iso-8859-1（在mysql的选项中对应于latin-1）。
理
由主要有这么几个，一是iso-8859-1对中
文的支持不错；二是跟java中的默认编码一致，至少在很多地方免除了转换编码的麻烦；三是默认的比
较稳定，兼容性也更好，因为多编码的
支持是由具体的DB产品提供的，别说跟其它的DB会不兼容，即使自身的不同版本也可能出现兼容性的问
题。
例如mysql4.0以前的产品中，很多中文的解决方案是利用connection中的characterEncoding字段来制
定编码，比如gb2312什么的，这样是ok
的，因为原数据都是ISO8859_1编码，jdbc驱动会采用url里面指定的characterset来进行编码，
resultSet.getString（*）取出的就是编码后的
字符串。
这样就直接拿到gb2312的数据了。
但是mysql4.1的推出给很多dbadmin带来了不小的麻烦，因为mysql4.1支持columnlevel的character
set，每个table,column都可以指定编码
，不指定就是ISO8895_1，因此jdbc取出数据后会根据column的characterset来进行编码，而不再是用
一个全局的参数来取所有的数据了。
这从另一个方面也说明了乱码问题的产生实在是很复杂的事情，原因太多了。
我也只是针对自己遇
////////////////////////////////////////////////////////////////////////////////////////
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的字位，其所有字符都可以一对一映射到Unicode2.0，也就是说Java
实际上提供了对GBK字符集的支持。
>GB18030-2000（GBK2K）在GBK的基础上进一步扩展了汉字，增加了藏、蒙等少数民族的文字。
GBK2K从根本上解决了字位不够、字形不足的问题。
1．Tomcat4开发平台
这个版本应该是我们经常用到的版本，所以讨论得会比较详细。
Windows98／2000下的Tomcat4以上版本都会出现中文问题（而在Linux下和Tomcat3.x中则没有问
题），主要表现是页面显示乱码。
为解决这个问题，最简单的方法就是在每个JSP的页面开始处加上<%@pagelanguage=“Java”
contentType=“text/html;charset=gb2312”%>。
不过，这还不够，虽然这时显示了中文，但是发现
从数据库读出的字段变成了乱码。
经过分析发现:
在数据库中保存的中文字符是正常的，数据库用
ISO8859-1字符集存取数据，而Java程序在处理字符时默认采用统一的ISO8859-1字符集（这也体现了
Java国际化思想），所以在数据添加的时候Java和数据库都是以ISO8859-1方式处理，这样不会出错。
但
是在读取数据的时候就出现问题了，因为数据读出也采用ISO8859-1字符集，而JSP的文件头中有语句
<%@pagelanguage=“Java”contentType=“text/html;charset=gb2312”%>，这说明页面采用
GB2312的字符集显示，这样就和读出的数据不一样。
这时页面显示从数据库中读出的字符是乱码，解决
的方法是对这些字符转码，从ISO8859-1转成GB2312，就可以正常显示了。
这个解决办法对很多平台具
有通用性，读者可以灵活运用。
具体的方法会在以下详细讲解。
另外，对于不同的数据库如SQL
Server，Oracle，Mysql，Sybase等，字符集的选择很重要。
如果考虑多语言版本，数据库的字符集就
应该统一采用ISO8859-1，需要输出的时候在不同的字符集之间做转换就可以了。
以下是针对不同平台的总结：
（1）JSWDK只适合于普通开发，稳定性和其他问题可能不如商业软件。
由于JDK1.3版性能要好于
JDK1.2.2很多，并且对中文的支持也较好，所以应该尽量采用。
现在jdk已经出到1.4版本了，所以
如果允许最好升级到最新的版本，这样对中文的也会较好，而且还可以得到更多的支持。
（2）Tomcat仅仅是一个对JSP1.1、Servlet2.2标准的实现,我们不应该要求这个免费软件在细节
和性能上都面面俱到,它主要考虑英文用户,这也是为什么不做特殊转换，汉字用URL方法传递就有
问题的原因。
大部分IE浏览器缺省始终以UTF-8发送,这似乎是Tomcat的一个不足,另外Tomcat不管
当前的操作系统是什么语言,都按ISO8859去编译JSP,似乎也欠妥。
2.JSP代码的中文处理
（1）如果与数据无关的操作，可以在页面首行加入
（2）将Form中的值传送到数据库中再取出来后全变成了“？
”。
Form用POST提交数据，代码中使用了语
句：
Stringst=new（request.getParameter（“name”）.getBytes（“ISO8859_1”）），而且也声明了
charset=gb2312。
要处理Form中传递的中文参数，应该在JSP中加入下面的代码，另外定义一个专门解决这个问题的
getStr类，然后对接收到的参数进行转换：
Stringkeyword1=request.getParameter（“keyword1”）;
keyword1=getStr（keyword1）;
这样就可以解决问题了，代码如下：
<%@pagecontentType=“text/html;charset=gb2312”%>
<%!
publicStringgetStr（Stringstr）{
try{Stringtemp_p=str;
byte[]temp_t=temp_p.getBytes（“ISO8859-1”）;
Stringtemp=newString（temp_t）;
returntemp;
}
catch（Exceptione）{}
return“NULL”;
}
%>
<%--测试--%>
<%Stringkeyword=“创联网络技术中心欢迎您的到来”;
Stringkeyword1=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）JDBCDriver的字符转换
目前大多数JDBCDriver采用本地编码格式来传输中文字符，例如中文字符“0x4175”会被转成“0x41
”和“0x75”进行传输。
因此需要对JDBCDriver返回的字符以及要发给JDBCDriver的字符进行转换
。
当用JDBCDriver向数据库中插入数据时，需要先将Unicode转成Nativecode;当JDBCDriver
从数据库中查询数据时，则需要将Nativecode转换成Unicode。
下面给出了这两种转换的实现:
Stringnative2Unicode（Strings）{
if（s==null||s.length（）==0）{
returnnull;
}
byte[]buffer=newbyte[s.length（）];
for（inti=0;is.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];
升级会员 