GBK编码

GBK编码

GBK编码是中国制订的、等同于UCS的新的中文编码扩展国家标准。GBK工作小组于1995年10月,同年12月完成GBK规范。该编码标准兼容GB2312,共收录汉字21003个、符号883个,并提供1894个造字码位,简、繁体字融于一库。

UTF-8编码

UTF-8编码可以通过屏蔽位和移位操作快速读写。字符串比较时strcmp()和wcscmp()的返回结果相同,因此使排序变得更加容易。字节FF和FE在UTF-8编码中永远不会出现,因此他们可以用来表明UTF-16或UTF-32文本(见BOM) UTF-8 是字节顺序无关的。它的字节顺序在所有系统中都是一样的,因此它实际上并不需要BOM。

GB2312

GB2312支持的汉字太少。1995年的汉字扩展规范GBK1.0收录了21886个符号,它分为汉字区和图形符号区。汉字区包括21003个字符。2000年的GB18030是取代GBK1.0的正式国家标准。该标准收录了27484个汉字,同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。现在的PC平台必须支持GB18030,对嵌入式产品暂不作要求。所以手机、MP3一般只支持GB2312。

从ASCII、GB2312、GBK到GB18030,这些编码方法是向下兼容的,即同一个字符在这些方案中总是有相同的编码,后面的标准支持更多的字符。在这些编码中,英文和中文可以统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼,GB2312、GBK到GB18030都属于双字节字符集 (DBCS)。

一、JSP页面显示乱码

二、表单提交中文时出现乱码

三、数据库连接

大家在JSP的开发过程中,经常出现中文乱码的问题,可能一至困扰着您,我现在把我在JSP开发中遇到

的中文乱码的问题及解决办法写出来供大家参考。

一、JSP页面显示乱码

下面的显示页面(display.jsp)就出现乱码:

对不同的WEB服务器和不同的JDK版本,处理结果就不一样。原因:服务器使用的编码方式不同和浏览器

JSP的中文处理

<%

out.print("JSP的中文处理");

%>

对不同的字符显示结果不同而导致的。解决办法:在JSP页面中指定编码方式(gb2312),即在页面的第一

行加上:

<%@ page contentType="text/html; charset=gb2312"%>

就可以消除乱码了。完整页面如下:

<%@ page contentType="text/html; charset=gb2312"%>

JSP的中文处理

<%

out.print("JSP的中文处理");

%>

二、表单提交中文时出现乱码

下面是一个提交页面(submit.jsp),代码如下:

JSP的中文处理

下面是处理页面(process.jsp)代码:

<%@ page contentType="text/html; charset=gb2312"%>

JSP的中文处理

<%=request.getParameter("name")%>

如果submit.jsp提交英文字符能正确显示,如果提交中文时就会出现乱码。原因:浏览器默认使用UTF

-8编码方式来发送请求,而UTF- 8和GB2312编码方式表示字符时不一样,这样就出现了不能识别字符。

解决办法:通过request.seCharacterEncoding ("gb2312")对请求进行统一编码,就实现了中文的正常

显示。修改后的process.jsp代码如下:

<%@ page contentType="text/html; charset=gb2312"%>

<%

request.setCharacterEncoding("gb2312");

%>

JSP的中文处理

<%=request.getParameter("name")%>

三、数据库连接出现乱码

只要涉及中文的地方全部是乱码,解决办法:在数据库的数据库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()来转换编码。

总结:

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正確转化

为编码A的String,然后输出。

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=" +

https://www.360docs.net/doc/f812973690.html,.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 的request 默认为ISO8859_1,所以在处理中文的时候,要显示中文的话,必须转成GBK的,如下

String str=new

String(request.getParameter("name").getBytes("ISO8859-1"),"GB K");

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 中 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-2000 汉字字符集

其实解决 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-2000国标的发布,它将在不久的将来完成它的历史使命。

GB18030-2000(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,则根据需要

相关文档
最新文档