jsp读取数据库中文乱码问题

这个问题是从项目中设计数据库和操作数据库的人不同而造成的。所用的数据库

是sybase，设计时把数据类型设计为nvarchar了，如果是中文，读取出来就会得

到乱码。我试了好多方法还是不行，最后无奈，只好将数据类型改为varchar了。

所以在此总结一下中文乱码问题。

一、JSP与页面参数之间的乱码
       JSP获取页面参数时一般采用系统默认的编码方式，如果页面参数的编码

类型和系统默认的编码类型不一致，很可能就会出现乱码。解决这类乱码问题的

基本方法是在页面获取参数之前，强制指定request获取参数的编码方式：

request.setCharacterEncoding("GBK")或request.setCharacterEncoding

("gb2312")。
如果在JSP将变量输出到页面时出现了乱码，可以通过设置

response.setContentType("text/html;charset=GBK")或

response.setContentType("text/html;charset=gb2312")解决。

二、Java与数据库之间的乱码
       大部分数据库都支持以unicode编码方式，所以解决Java与数据库之间的

乱码问题比较明智的方式是直接使用unicode编码与数据库交互。很多数据库驱动

自动支持unicode，如Microsoft的SQLServer驱动。其他大部分数据库驱动，可以

在驱动的url参数中指定，如如mm的mysql驱动：

jdbc:mysql://localhost/WEBCLDB?useUnicode=true&characterEncoding=GBK。

三、Java与文件/流之间的乱码
       Java读写文件最常用的类是FileInputStream/FileOutputStream和

FileReader/FileWriter。其中FileInputStream和FileOutputStream是基于字节

流的，常用于读写二进制文件。读写字符文件建议使用基于字符的FileReader和

FileWriter，省去了字节与字符之间的转换。但这两个类的构造函数默认使用系

统的编码方式，如果文件内容与系统编码方式不一致，可能会出现码。     在这

种情况下，建议使用FileReader和FileWriter的父类：

InputStreamReader/OutputStreamWriter，它们也是基于字符的，但在构造函数

中可以指定编码类型：InputStreamReader(InputStream in, Charset cs) 和

OutputStreamWriter(OutputStream out, Charset cs)。

 字符，字节和编码之间的关系

1. 编码问题的由来，相关概念的理解
1.1 字符与编码的发展
从计算机对多国语言的支持角度看，大致可以分为三个阶段：

　 系统内码 说明 系统
阶段一 ASCII 计算机刚开始只支持英语，其它语言不能够在计算机上存储和显示

。 英文 DOS
阶段二 ANSI编码
（本地化） 为使计算机支持更多语言，通常使用 0x80~0xFF 范围的 2 个字节来

表示 1 个字符。比如：汉字 '中' 在中文操作系统中，使用 [0xD6,0xD0] 这两

个字节存储。

不同的国家和地区制定了不同的标准，由此产生了 GB2312, BIG5, JIS 等各自的

编码标准。这些使用 2 个字节来代表一个字符的各种汉字延伸编码方式，称为

ANSI 编码。在简体中文系统下，ANSI 编码代表 GB2312 编码，在日文操作系统

下，ANSI 编码代表 JIS 编码。

不同 ANSI 编码之间互不兼容，当信息在国际间交流时，无法将属于两种语言的

文字，存储在同一段 ANSI 编码的文本中。 中文 DOS，中文 Windows 95/98，日

文 Windows 95/98
阶段三 UNICODE
（国际化） 为了使国际间信息交流更加方便，国际组织制定了 UNICODE 字符集

，为各种语言中的每一个字符设定了统一并且唯一的数字编号，以满足跨语言、

跨平台进行文本转换、处理的要求。 Windows NT/2000/XP，Linux，Java

字符串在内存中的存放方法：

在 ASCII 阶段，单字节字符串使用一个字节存放一个字符（SBCS）。比

如，"Bob123" 在内存中为：

42 6F 62 31 32 33 00
      
B o b 1 2 3 /0

在使用 ANSI 编码支持多种语言阶段，每个字符使用一个字节或多个字节来表示

（MBCS），因此，这种方式存放的字符也被称作多字节字符。比如，"中文123"

在中文 Windows 95 内存中为7个字节，每个汉字占2个字节，每个英文和数字字

符占1个字节：

D6 D0 CE C4 31 32 33 00
     
中 文 1 2 3 /0

在 UNICODE 被采用之后，计算机存放字符串时，改为存放每个字符在 UNICODE

字符集中的序号。目前计算机一般使用 2 个字节（16 位）来存放一个序号

（DBCS），因此，这种方式存放的字符也被称作宽字节字符。比如，字符串 "中

文123" 在 Windows 2000 下，内存中实际存放的是 5 个序号：

2D 4E 87 65 31 00 32 00 33 00 00 00      ← 在 x86 CPU 中，低字节在前
      
中 文 1 2 3 /0 　

一共占 10 个字节。

1.2 字符，字节，字符串
理解编码的关键，是要把字符的概念和字节的概念理解准确。这两个概念容易混

淆，我们在此做一下区分：

　 概念描述 举例
字符 人们使用的记号，抽象意义上的一个符号。 '1', '中', 'a', '$', '￥',

……
字节 计算机中存储数据的单元，一个8位的二进制数，是一个很具体的存储空间

。 0x01, 0x45, 0xFA, ……
ANSI
字符串 在内存中，如果“字符”是以 ANSI 编码形式存在的，一个字符可能使用

一个字节或多个字节来表示，那么我们称这种字符串为 ANSI 字符串或者多字节

字符串。 "中文123"
（占7字节）
UNICODE
字符串 在内存中，如果“字符”是以在 UNICODE 中的序号存在的，那么我们称

这种字符串为 UNICODE 字符串或者宽字节字符串。 L"中文123"
（占10字节）

由于不同 ANSI 编码所规定的标准是不相同的，因此，对于一个给定的多字节字

符串，我们必须知道它采用的是哪一种编码规则，才能够知道它包含了哪些“字

符”。而对于 UNICODE 字符串来说，不管在什么环境下，它所代表的“字符”内

容总是不变的。

1.3 字符集与编码
各个国家和地区所制定的不同 ANSI 编码标准中，都只规定了各自语言所需的“

字符”。比如：汉字标准（GB2312）中没有规定韩国语字符怎样存储。这些 ANSI

编码标准所规定的内容包含两层含义：

使用哪些字符。也就是说哪些汉字，字母和符号会被收入标准中。所包含“字符

”的集合就叫做“字符集”。
规定每个“字符”分别用一个字节还是多个字节存储，用哪些字节来存储，这个

规定就叫做“编码”。
各个国家和地区在制定编码标准的时候，“字符的集合”和“编码”一般都是同

时制定的。因此，平常我们所说的“字符集”，比如：GB2312, GBK, JIS 等，除

了有“字符的集合”这层含义外，同时也包含了“编码”的含义。

“UNICODE 字符集”包含了各种语言中使用到的所有“字符”。用来给 UNICODE

字符集编码的标准有很多种，比如：UTF-8, UTF-7, UTF-16, UnicodeLittle,

UnicodeBig 等。

1.4 常用的编码简介
简单介绍一下常用的编码规则，为后边的章节做一个准备。在这里，我们根据编

码规则的特点，把所有的编码分成三类：

分类 编码标准 说明
单字节字符编码 ISO-8859-1 最简单的编码规则，每一个字节直接作为一个

UNICODE 字符。比如，[0xD6, 0xD0] 这两个字节，通过 iso-8859-1 转化为字符

串时，将直接得到 [0x00D6, 0x00D0] 两个 UNICODE 字符，即 "?D"。

反之，将 UNICODE 字符串通过 iso-8859-1 转化为字节串时，只能正常转化

0~255 范围的字符。
ANSI 编码 GB2312,
BIG5,
Shift_JIS,
ISO-8859-2 …… 把 UNICODE 字符串通过 ANSI 编码转化为“字节串”时，根据

各自编码的规定，一个 UNICODE 字符可能转化成一个字节或多个字节。

反之，将字节串转化成字符串时，也可能多个字节转化成一个字符。比如，

[0xD6, 0xD0] 这两个字节，通过 GB2312 转化为字符串时，将得到 [0x4E2D] 一

个字符，即 '中' 字。

“ANSI 编码”的特点：
1. 这些“ANSI 编码标准”都只能处理各自语言范围之内的 UNICODE 字符。
2. “UNICODE 字符”与“转换出来的字节”之间的关系是人为规定的。
UNICODE 编码 UTF-8,
UTF-16, UnicodeBig …… 与“ANSI 编码”类似的，把字符串通过 UNICODE 编

码转化成“字节串”时，一个 UNICODE 字符可能转化成一个字节或多个字节。

与“ANSI 编码”不同的是：
1. 这些“UNICODE 编码”能够处理所有的 UNICODE 字符。
2. “UNICODE 字符”与“转换出来的字节”之间是可以通过计算得到的。

我们实际上没有必要去深究每一种编码具体把某一个字符编码成了哪几个字节，

我们只需要知道“编码”的概念就是把“字符”转化成“字节”就可以了。对于

“UNICODE 编码”，由于它们是可以通过计算得到的，因此，在特殊的场合，我

们可以去了解某一种“UNICODE 编码”是怎样的规则。

 
 

2. 字符与编码在程序中的实现
2.1 程序中的字符与字节
在 C++ 和 Java 中，用来代表“字符”和“字节”的数据类型，以及进行编码的

方法：

类型或操作 C++ Java
字符 wchar_t char
字节 char byte
ANSI 字符串 char[] byte[]
UNICODE 字符串 wchar_t[] String
字节串→字符串 mbstowcs(), MultiByteToWideChar() string = new String

(bytes, "encoding")
字符串→字节串 wcstombs(), WideCharToMultiByte() bytes =

string.getBytes("encoding")

以上需要注意几点：

Java 中的 char 代表一个“UNICODE 字符（宽字节字符）”，而 C++ 中的 char

代表一个字节。
MultiByteToWideChar() 和 WideCharToMultiByte() 是 Windows API 函数。
2.2 C++ 中相关实现方法
声明一段字符串常量：

// ANSI 字符串，内容长度 7 字节
char     sz[20] = "中文123";

// UNICODE 字符串，内容长度 5 个 wchar_t（10 字节）
wchar_t wsz[20] = L"/x4E2D/x6587/x0031/x0032/x0033";

UNICODE 字符串的 I/O 操作，字符与字节的转换操作：

// 运行时设定当前 ANSI 编码，VC 格式
setlocale(LC_ALL, ".936");

// GCC 中格式
setlocale(LC_ALL, "zh_CN.GBK");

// Visual C++ 中使用小写 %s，按照 setlocale 指定编码输出到文件
// GCC 中使用大写 %S
fwprintf(fp, L"%s/n", wsz);

// 把 UNICODE 字符串按照 setlocale 指定的编码转换成字节
wcstombs(sz, wsz, 20);
// 把字节串按照 setlocale 指定的编码转换成 UNICODE 字符串
mbstowcs(wsz, sz, 20);

在 Visual C++ 中，UNICODE 字符串常量有更简单的表示方法。如果源程序的编

码与当前默认 ANSI 编码不符，则需要使用 #pragma setlocale，告诉编译器源

程序使用的编码：

// 如果源程序的编码与当前默认 ANSI 编码不一致，
// 则需要此行，编译时用来指明当前源程序使用的编码
#pragma setlocale(".936")

// UNICODE 字符串常量，内容长度 10 字节
wchar_t wsz[20] = L"中文123";

以上需要注意 #pragma setlocale 与 setlocale(LC_ALL, "") 的作用是不同的

，#pragma setlocale 在编译时起作用，setlocale() 在运行时起作用。

3. 几种误解，以及乱码产生的原因和解决办法
3.1 容易产生的误解
　 对编码的误解
误解一 在将“字节串”转化成“UNICODE 字符串”时，比如在读取文本文件时，

或者通过网络传输文本时，容易将“字节串”简单地作为单字节字符串，采用每

“一个字节”就是“一个字符”的方法进行转化。

而实际上，在非英文的环境中，应该将“字节串”作为 ANSI 字符串，采用适当

的编码来得到 UNICODE 字符串，有可能“多个字节”才能得到“一个字符”。

通常，一直在英文环境下做开发的程序员们，容易有这种误解。
误解二 在 DOS，Windows 98 等非 UNICODE 环境下，字符串都是以 ANSI 编码的

字节形式存在的。这种以字节形式存在的字符串，必须知道是哪种编码才能被正

确地使用。这使我们形成了一个惯性思维：“字符串的编码”。

当 UNICODE 被支持后，Java 中的 String 是以字符的“序号”来存储的，不是

以“某种编码的字节”来存储的，因此已经不存在“字符串的编码”这个概念了

。只有在“字符串”与“字节串”转化时，或者，将一个“字节串”当成一个

ANSI 字符串时，才有编码的概念。

不少的人都有这个误解。

第一种误解，往往是导致乱码产生的原因。第二种误解，往往导致本来容易纠正

的乱码问题变得更复杂。

在这里，我们可以看到，其中所讲的“误解一”，即采用每“一个字节”就是“

一个字符”的转化方法，实际上也就等同于采用 iso-8859-1 进行转化。因此，

我们常常使用 bytes = string.getBytes("iso-8859-1") 来进行逆向操作，得到

原始的“字节串”。然后再使用正确的 ANSI 编码，比如 string = new String

(bytes, "GB2312")，来得到正确的“UNICODE 字符串”。

3.2 非 UNICODE 程序在不同语言环境间移植时的乱码

非 UNICODE 程序中的字符串，都是以某种 ANSI 编码形式存在的。如果程序运行

时的语言环境与开发时的语言环境不同，将会导致 ANSI 字符串的显示失败。

比如，在日文环境下开发的非 UNICODE 的日文程序界面，拿到中文环境下运行时

，界面上将显示乱码。如果这个日文程序界面改为采用 UNICODE 来记录字符串，

那么当在中文环境下运行时，界面上将可以显示正常的日文。

由于客观原因，有时候我们必须在中文操作系统下运行非 UNICODE 的日文软件，

这时我们可以采用一些工具，比如，南极星，AppLocale 等，暂时的模拟不同的

语言环境。

3.3 网页提交字符串
当页面中的表单提交字符串时，首先把字符串按照当前页面的编码，转化成字节

串。然后再将每个字节转化成 "%XX" 的格式提交到 Web 服务器。比如，一个编

码为 GB2312 的页面，提交 "中" 这个字符串时，提交给服务器的内容为 "%D6%

D0"。

在服务器端，Web 服务器把收到的 "%D6%D0" 转化成 [0xD6, 0xD0] 两个字节，

然后再根据 GB2312 编码规则得到 "中" 字。

在 Tomcat 服务器中，request.getParameter() 得到乱码时，常常是因为前面提

到的“误解一”造成的。默认情况下，当提交 "%D6%D0" 给 Tomcat 服务器时，

request.getParameter() 将返回 [0x00D6, 0x00D0] 两个 UNICODE 字符，而不

是返回一个 "中" 字符。因此，我们需要使用 bytes = string.getBytes("iso-

8859-1") 得到原始的字节串，再用 string = new String(bytes, "GB2312") 重

新得到正确的字符串 "中"。

3.4 从数据库读取字符串

通过数据库客户端（比如 ODBC 或 JDBC）从数据库服务器中读取字符串时，客户

端需要从服务器获知所使用的 ANSI 编码。当数据库服务器发送字节流给客户端

时，客户端负责将字节流按照正确的编码转化成 UNICODE 字符串。

如果从数据库读取字符串时得到乱码，而数据库中存放的数据又是正确的，那么

往往还是因为前面提到的“误解一”造成的。解决的办法还是通过 string = new

String( string.getBytes("iso-8859-1"), "GB2312") 的方法，重新得到原始的

字节串，再重新使用正确的编码转化成字符串。