这个字“嫕"读yi（女医心）, 它在数据库中存储正确，但在jsp页面显示乱码，在线等待！！！ <%@ page contentType="text/html;charset=GBK" %>用gbk编码 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 数据库字符集包含的字符多叶面上字符集包含得少一般来说gbk包涵的比较多如果楼上说得不成你看看你的数据库什么字符集 charset用GB18030试试这个编码集和GBK兼容并且支持更多的汉字 英文和欧洲其他语言的单字节字符集(SingleByte Charsets)：首先对于ISO-8859系列的字符集都想象成一个：2^8 = 16 * 16 = 256个格子的棋盘，这样所有的西文字符（英文）用这样一个16×16的坐标系就基本可以覆盖全了。而英文实际上只用其中小于128(\x80)的部分就够了。利用大于128部分的空间的不同定义规则形成了真对其他欧洲语言的扩展字符集：ISO-8859-2 ISO-8859-4等……GB2312 BIG5 SJIS等多字节字符集（MultiByte Charsets）： 对于亚洲语言来说：汉字这么多，用这么一个256格的小棋盘肯定放不下，所以要区别成千上万的汉字解决办法就是用2个字节（坐标）来定位一个“字”在棋盘上的位置，将以上规则做一个扩展：· 如果第1个字符是小于128(\x80)的仍和英文字符集编码方式保持兼容； · 如果第1个字符是大于128(\x80)的，就当成是汉字的第1个字节，这个自己和后面紧跟的1个字节组成一个汉字； 其结果相当于在位于128以上的小棋格里每个小棋格又划分出了一个16×16的小棋盘。这样一个棋盘中的格子数（可能容纳的字符数）就变成了128 + 128 * 256。按照类似的方式有了简体中文的GB2312标准，繁体中文的BIG5字符集和日文的SJIS字符集等，GB2312字符集包含大约有六仟多个常用简体汉字。由此可以看出，所有这些从ASCII扩展式的编码方式中：英文部分都是兼容的，但扩展部分的编码方式是不兼容的，虽然很多字在3种体系中写法一致（比如“中文”这2个字）但在相应字符集中的坐标不一致，所以GB2312编写的页面用BIG5看就变得面目全非了。而且有时候经常在浏览其他非英语国家的页面时（比如包含有德语的人名时）经常出现奇怪的汉字，其实就是扩展位的编码冲突造成的。我把GBK和GB18030理解成一个小UNICODE：GBK字符集是GB2312的扩展(K)，GBK里大约有贰万玖仟多个字符，除了保持和GB2312兼容外，繁体中文字，甚至连日文的假名字符也能显示。而GB18030-2000则是一个更复杂的字符集，采用变长字节的编码方式，能够支持更多的字符。关于汉字的编码方式比较详细的定义规范可以参考： 由前电子部科技质量司和国家技术监督局标准化司于1995年12月颁布的指导性规范。（GBK的 K是“扩展”的汉语拼音第一个字母) GBK作为非 UCS ( ISO/IEC 10646 ) 体系的代码页，适用于中文信息的处理、交换、存储、传输、显现、输入和输出。 GBK与国家标准 GB 2312-80 信息处理交换码所对应的、事实上的内码标准兼容；同时，在字汇一级支持 ISO/IEC 10646-1 和GB 13000-1 的全部中日韩 (CJK) 汉字(20902字)。GBK除了包含GB2312-80 和GB12345-90中包括的全部非汉字符号外，还涵盖我国台湾地区中文标准交换码TCA-CNS 11643 -92 ( 与其对应的内码为Big5；以下用Big5泛指二者。) 中的绝大多数符号。 从Windows95中文版起，Windows NT 3.51, 4.0, Windows2000, Windows CE, Linux已经全面支持GBK，起到了从GB 2312向Unicode过渡的承上启下的重要作用。 GBK尽管在字汇一级支持CJK，是目前最大的Code Page ；它在体系结构、代码空间上，仍然是完全不同于ISO/IEC 10646 和Unicode的。 GBK的代码空间如下： ASCII（英文） ==> 西欧文字 ==> 东欧字符集（俄文，希腊语等） ==> 东亚字符集（GB2312 BIG5 SJIS等）==> 扩展字符集GBK GB18030这个发展过程基本上也反映了字符集标准的发展过程，但这么随着时间的推移，尤其是互联网让跨语言的信息的交互变得越来越多的时候，太多多针对本地语言的编码标准的出现导致一个应用程序的国际化变得成本非常高。尤其是你要编写一个同时包含法文和简体中文的文档，这时候一般都会想到要是用一个通用的字符集能够显示所有语言的所有文字就好了，而且这样做应用也能够比较方便的国际化，为了达到这个目标，即使应用牺牲一些空间和程序效率也是非常值得的。UNICODE就是这样一个通用的解决方案。UNICODE双字节字符集所以你可以把UNICODE想象成这样：让所有的字符（包括英文）都用2个字节（2个8位）表示，这样就有了一个2^(8*2) = 256 * 256 = 65536个格子的大棋盘。在这个棋盘中，这样中（简繁）日韩（还包括越南）文字作为CJK字符集都放在一定的区位内，为了减少重复，各种语言中写法一样的字共享一个“棋格”。详细的区位见附录AUnicode：(DoubleByte Charsets)西 C中 其欧 J日 它英 K韩 语文 言 什么还要有UTF-8？毕竟互联网70％以上的信息仍然是英文。如果连英文都用2个字节存取(UCS-2)，空间浪费不就太多了？所谓UTF-8就是这样一个为了提高英文存取效率的字符集转换格式：Unicode Transformation Form 8-bit form。用UTF-8，UNICODE的2字节字符用变长个（1－3个字节）表示：1. 对英文，仍然和ASCII一样用1个字节表示，这个字节的值小于128(\x80)； 2. 对其他语言的用一个值位于128-256之间的字节开始，再加后面紧跟的2个字节表示，一个字符一共是3个字节； 因此，在应用中程序处理过程中所有字符都是16位（双字节），但在存取转换成字节流时使用UTF-8格式转换，对于英文字符来说和原来用ASCII方式存取时相比大小仍然是一样的，而对中文来说和原来的GB2312编码方式相比，大小为：(3字节/2字节)=1.5倍小节：假设英文字符集是一个16×16的棋盘，么其他语言的字符集就是把高位区重新分割的(> 128)的中等棋盘，多种字符集之间互不兼容而UNICODE本身就相当于一个256×256的大棋盘，通过一定规则将英文和其他所有语言的字符都包含在内。 去重新下个最新版本的jdbc驱动,并改用gbk,就可以了 求一个正则表达式写法：如何将方括号总的空格替换为\t 请问有什么好的Java开发平台？ 麻烦各位大虾给具体解释下Void的用法？ 关于web.xml问题 怎样才可以关闭线程啊?? 进度条怎么用？ Java中如何将一个byte[]转换成相应的文件。 关与换行符的问题，请高手帮帮忙，急救！！ 这样的证书，如何实现打印？ 纠集一群无聊的人（>=50）用一个月时间一起来翻译jbuilder5的帮助文件，大家有没有兴趣啊~~~~~ 请问如何用JAVA读取C++写的二进制文件 类的构造方法是否不能在子类中覆盖？
叶面上字符集包含得少
一般来说gbk包涵的比较多如果楼上说得不成
你看看你的数据库什么字符集
首先对于ISO-8859系列的字符集都想象成一个：2^8 = 16 * 16 = 256个格子的棋盘，这样所有的西文字符（英文）用这样一个16×16的坐标系就基本可以覆盖全了。而英文实际上只用其中小于128(\x80)的部分就够了。利用大于128部分的空间的不同定义规则形成了真对其他欧洲语言的扩展字符集：ISO-8859-2 ISO-8859-4等……
GB2312 BIG5 SJIS等多字节字符集（MultiByte Charsets）：
对于亚洲语言来说：汉字这么多，用这么一个256格的小棋盘肯定放不下，所以要区别成千上万的汉字解决办法就是用2个字节（坐标）来定位一个“字”在棋盘上的位置，将以上规则做一个扩展：
· 如果第1个字符是小于128(\x80)的仍和英文字符集编码方式保持兼容；
· 如果第1个字符是大于128(\x80)的，就当成是汉字的第1个字节，这个自己和后面紧跟的1个字节组成一个汉字；
其结果相当于在位于128以上的小棋格里每个小棋格又划分出了一个16×16的小棋盘。这样一个棋盘中的格子数（可能容纳的字符数）就变成了128 + 128 * 256。按照类似的方式有了简体中文的GB2312标准，繁体中文的BIG5字符集和日文的SJIS字符集等，GB2312字符集包含大约有六仟多个常用简体汉字。由此可以看出，所有这些从ASCII扩展式的编码方式中：英文部分都是兼容的，但扩展部分的编码方式是不兼容的，虽然很多字在3种体系中写法一致（比如“中文”这2个字）但在相应字符集中的坐标不一致，所以GB2312编写的页面用BIG5看就变得面目全非了。而且有时候经常在浏览其他非英语国家的页面时（比如包含有德语的人名时）经常出现奇怪的汉字，其实就是扩展位的编码冲突造成的。
我把GBK和GB18030理解成一个小UNICODE：GBK字符集是GB2312的扩展(K)，GBK里大约有贰万玖仟多个字符，除了保持和GB2312兼容外，繁体中文字，甚至连日文的假名字符也能显示。而GB18030-2000则是一个更复杂的字符集，采用变长字节的编码方式，能够支持更多的字符。关于汉字的编码方式比较详细的定义规范可以参考： 由前电子部科技质量司和国家技术监督局标准化司于1995年12月颁布的指导性规范。（GBK的 K是“扩展”的汉语拼音第一个字母) GBK作为非 UCS ( ISO/IEC 10646 ) 体系的代码页，适用于中文信息的处理、交换、存储、传输、显现、输入和输出。 GBK与国家标准 GB 2312-80 信息处理交换码所对应的、事实上的内码标准兼容；同时，在字汇一级支持 ISO/IEC 10646-1 和GB 13000-1 的全部中日韩 (CJK) 汉字(20902字)。GBK除了包含GB2312-80 和GB12345-90中包括的全部非汉字符号外，还涵盖我国台湾地区中文标准交换码TCA-CNS 11643 -92 ( 与其对应的内码为Big5；以下用Big5泛指二者。) 中的绝大多数符号。 从Windows95中文版起，Windows NT 3.51, 4.0, Windows2000, Windows CE, Linux已经全面支持GBK，起到了从GB 2312向Unicode过渡的承上启下的重要作用。 GBK尽管在字汇一级支持CJK，是目前最大的Code Page ；它在体系结构、代码空间上，仍然是完全不同于ISO/IEC 10646 和Unicode的。 GBK的代码空间如下：
ASCII（英文） ==> 西欧文字 ==> 东欧字符集（俄文，希腊语等） ==> 东亚字符集（GB2312 BIG5 SJIS等）==> 扩展字符集GBK GB18030这个发展过程基本上也反映了字符集标准的发展过程，但这么随着时间的推移，尤其是互联网让跨语言的信息的交互变得越来越多的时候，太多多针对本地语言的编码标准的出现导致一个应用程序的国际化变得成本非常高。尤其是你要编写一个同时包含法文和简体中文的文档，这时候一般都会想到要是用一个通用的字符集能够显示所有语言的所有文字就好了，而且这样做应用也能够比较方便的国际化，为了达到这个目标，即使应用牺牲一些空间和程序效率也是非常值得的。UNICODE就是这样一个通用的解决方案。
UNICODE双字节字符集
所以你可以把UNICODE想象成这样：让所有的字符（包括英文）都用2个字节（2个8位）表示，这样就有了一个2^(8*2) = 256 * 256 = 65536个格子的大棋盘。在这个棋盘中，这样中（简繁）日韩（还包括越南）文字作为CJK字符集都放在一定的区位内，为了减少重复，各种语言中写法一样的字共享一个“棋格”。详细的区位见附录A
Unicode：(DoubleByte Charsets)
西 C中 其
欧 J日 它
英 K韩 语
文 言
什么还要有UTF-8？毕竟互联网70％以上的信息仍然是英文。如果连英文都用2个字节存取(UCS-2)，空间浪费不就太多了？所谓UTF-8就是这样一个为了提高英文存取效率的字符集转换格式：Unicode Transformation Form 8-bit form。用UTF-8，UNICODE的2字节字符用变长个（1－3个字节）表示：
1. 对英文，仍然和ASCII一样用1个字节表示，这个字节的值小于128(\x80)；
2. 对其他语言的用一个值位于128-256之间的字节开始，再加后面紧跟的2个字节表示，一个字符一共是3个字节；
因此，在应用中程序处理过程中所有字符都是16位（双字节），但在存取转换成字节流时使用UTF-8格式转换，对于英文字符来说和原来用ASCII方式存取时相比大小仍然是一样的，而对中文来说和原来的GB2312编码方式相比，大小为：(3字节/2字节)=1.5倍
小节：
假设英文字符集是一个16×16的棋盘，么其他语言的字符集就是把高位区重新分割的(> 128)的中等棋盘，多种字符集之间互不兼容而UNICODE本身就相当于一个256×256的大棋盘，通过一定规则将英文和其他所有语言的字符都包含在内。