关于oracle数据表编码和页面编码的三个疑问？

0 0

关于oracle数据表编码和页面编码的三个疑问？5

关于oracle数据表编码和页面编码的三个疑问？
一、
oracle中，数据表的字符编码是gbk的，那么web页面如果是utf8的，提交的数据能正常保存吗？
我试过了，能正常保存，但是搞不懂其中的原由。

二、
另外保存到oracle表中的数据，在web页面中显示的时候，页面编码无论是gbk，还是utf-8都能正常显示，难道oracle的编码是自动转换的吗？

三、
同一个数据表中，一开始用提交数据的页面编码为gbk，插入了一些数据，后来将页面编码改为utf-8的，插入数据也正常。
查询显示时，gbk和utf-8的页面编码都能使数据正常显示。虽然一切正常很好，但是搞不明白为什么？

DAO

2009年6月08日 22:22

phoenix007
16
0 0 1

3个答案按时间排序按投票排序

0 0

朋友，问题要自动关闭啦，结分哦，

2009年6月21日 21:33

lovewhzlq
13934
0 0 0

添加评论

0 0

Orancle用的确实是GBK的编码，如果你的表用的是默认的编码，那不用说，也是GBK的编码了。页面是UTF-8。这里面还有一个隐藏的编码，那就是jre的编码，jdk和jre的编码都是GBK。

讨论这个问题，可以做一个类比：
众所周知，在java中，jdk是GBK吧编码，但是，Windows系统用的却是GB2312编码，而你的代码运行的时候却不会乱码。

JVM里面的任何字符串资源都是Unicode，就是说，任何String类型的数据都是Unicode编码。没有例外。既然只有一种编码，那么，我们可以这么说，JVM里面的String是不带编码的。String相当于 char[]。
JVM里面的 byte[] 数据是带编码的。比如，Big5，GBK，GB2312，UTF-8之类的。
一个GBK编码的byte[] 转换成 String，其实就是从GBK编码向Unicode编码转换。
一个String转换成一个Big5编码的byte[]，其实就是从Unicode编码向Big5编码转换。
所以，Unicode是所有编码转换的中间介质。所有的编码都有一个转换器可以转换到Unicode，而Unicode也可以转换到其他所有的编码。这样构成了一个总线结构。
比如，如果总共有10种编码，那么只需要 10 + 10 = 20个转换器就够了。如果要是两两直接转换，那么，需要的转换器数量是一个组合数字，需要90个转换器。

一个系统的不同部分，都有自己的编码。比如，数据库，文件，JVM，浏览器这4个部分。
在这些部分之间数据交换的地方，就会出现编码问题。比如，数据库和JVM之间，文件和JVM之间，浏览器和JVM之间。这些问题的原理都是相通的。

编码问题最容易处理的地方是文件和JVM之间。文件IO API带有encoding 参数，请自行查阅。
最不容易出现编码问题的地方是数据库和JVM之间。这应该是数据库JDBC连接的基本功能。本文不专门进行讨论。
最容易出问题的地方是浏览器和服务器JVM之间（其实，代码里面的字符串更容易出问题，不过，我已经事先声明，本文不讨论代码中的字符串编码）。下面主要讨论这块浏览器和服务器JVM之间的编码问题。

我们把浏览器编码叫做 Browser_Charset，把JVM编码叫做JVM_Charset（通常等于服务器系统编码）。
当浏览器的数据过来的时候，是一个带有Browser_Charset的byte[]。
如果用户处理程序需要一个String类型的数据，那么JVM会好心好意地把这个byte[]转换成String。使用的转换器是 JVM_Charset -> Unicode。
注意，如果这个时候，Browser_Charset 和 JVM_Charset并不相等。那么，这个自动转换是错误的。
为了弥补这个错误。我们需要做两步工作。
(1) Unicode -> JVM_Charset，把这个String 转换回到原来的 byte[]。
(2) Browser_Charset -> Unicode，把这个还原的byte[]转换成 String。

这个效果，和直接从HTTP Request取得byte[]，然后执行 (2) Browser_Charset -> Unicode 的效果是一样的。

如果在Request里面设置了CharacterEncoding，那么POST Data参数就不需要自己手工转换了，web server的自动转换就是正确的。URL的参数编码还涉及到URL编码，需要考虑的问题多一些，没有这么简单。

JVM把数据发到浏览器的时候。也需要考虑编码问题。可以在Response里面设置。另外，HTML Meta Header里面也可以设置编码，提醒Browser选择正确编码。

2009年6月09日 00:11

javaclover
39
0 0 0

添加评论

0 0

ASCII 、GB2312、GBK、GB18030、unicode、UTF-8字符集编码详解
ASCII字符集编码

    ASCII码是7位编码，编码范围是0x00-0x7F。ASCII字符集包括英文字母、阿拉伯数字和标点符号等字符。其中0x00-0x20和0x7F共33个控制字符。

    只支持ASCII码的系统会忽略每个字节的最高位，只认为低7位是有效位。HZ字符编码就是早期为了在只支持7位ASCII系统中传输中文而设计的编码。早期很多邮件系统也只支持ASCII编码，为了传输中文邮件必须使用BASE64或者其他编码方式。

GB2312字符集编码

   GB2312是基于区位码设计的，区位码把编码表分为94个区，每个区对应94个位，每个字符的区号和位号组合起来就是该汉字的区位码。区位码一般用10进制数来表示，如1601就表示16区1位，对应的字符是“啊”。在区位码的区号和位号上分别加上0xA0就得到了GB2312编码。

    区位码中01-09区是符号、数字区，16-87区是汉字区，10-15和88-94是未定义的空白区。它将收录的汉字分成两级：第一级是常用汉字计 3755个，置于16-55区，按汉语拼音字母/笔形顺序排列；第二级汉字是次常用汉字计3008个，置于56-87区，按部首/笔画顺序排列。一级汉字是按照拼音排序的，这个就可以得到某个拼音在一级汉字区位中的范围，很多根据汉字可以得到拼音的程序就是根据这个原理编写的。

   GB2312字符集中除常用简体汉字字符外还包括希腊字母、日文平假名及片假名字母、俄语西里尔字母等字符，未收录繁体中文汉字和一些生僻字。可以用繁体汉字测试某些系统是不是只支持GB2312编码。

   GB2312的编码范围是0xA1A1-0x7E7E，去掉未定义的区域之后可以理解为实际编码范围是0xA1A1-0xF7FE。

   EUC-CN可以理解为GB2312的别名，和GB2312完全相同。

   区位码更应该认为是字符集的定义，定义了所收录的字符和字符位置，而GB2312及EUC-CN是实际计算机环境中支持这种字符集的编码。HZ和ISO-2022-CN是对应区位码字符集的另外两种编码，都是用7位编码空间来支持汉字。区位码和GB2312编码的关系有点像 Unicode和UTF-8。

GBK字符集编码

   GBK 编码是GB2312编码的超集，向下完全兼容GB2312，同时GBK收录了Unicode基本多文种平面中的所有CJK汉字。同 GB2312一样，GBK也支持希腊字母、日文假名字母、俄语字母等字符，但不支持韩语中的表音字符（非汉字字符）。GBK还收录了GB2312不包含的汉字部首符号、竖排标点符号等字符。

   GBK的整体编码范围是为0x8140-0xFEFE，不包括低字节是0×7F的组合。高字节范围是0×81-0xFE，低字节范围是0x40-7E和0x80-0xFE。

   低字节是0x40-0x7E的GBK字符有一定特殊性，因为这些字符占用了ASCII码的位置，这样会给一些系统带来麻烦。

   有些系统中用0x40-0x7E中的字符（如“|”）做特殊符号，在定位这些符号时又没有判断这些符号是不是属于某个 GBK字符的低字节，这样就会造成错误判断。在支持GB2312的环境下就不存在这个问题。需要注意的是支持GBK的环境中小于0x80的某个字节未必就是ASCII符号；另外就是最好选用小于0×40的ASCII符号做一些特殊符号，这样就可以快速定位，且不用担心是某个汉字的另一半。Big5编码中也存在相应问题。
   CP936和GBK的有些许差别，绝大多数情况下可以把CP936当作GBK的别名。

GB18030字符集编码

   GB18030编码向下兼容GBK和GB2312，兼容的含义是不仅字符兼容，而且相同字符的编码也相同。GB18030收录了所有Unicode3.1中的字符，包括中国少数民族字符，GBK不支持的韩文字符等等，也可以说是世界大多民族的文字符号都被收录在内。

   GBK和GB2312都是双字节等宽编码，如果算上和ASCII兼容所支持的单字节，也可以理解为是单字节和双字节混合的变长编码。GB18030编码是变长编码，有单字节、双字节和四字节三种方式。

   GB18030 的单字节编码范围是0x00-0x7F，完全等同与ASCII；双字节编码的范围和GBK相同，高字节是0x81-0xFE，低字节的编码范围是0x40 -0x7E和0x80-FE；四字节编码中第一、三字节的编码范围是0x81-0xFE，二、四字节是0x30-0x39。

   Windows 中CP936代码页使用0x80来表示欧元符号，而在GB18030编码中没有使用0x80编码位，用其他位置来表示欧元符号。这可以理解为是 GB18030向下兼容性上的一点小问题；也可以理解为0x80是CP936对GBK的扩展，而GB18030只是和GBK兼容良好。

unicode字符集编码

每一种语言的不同的编码页，增加了那些需要支持不同语言的软件的复杂度。因而人们制定了一个世界标准，叫做unicode。unicode为每个字符提供了唯一的特定数值，不论在什么平台上、不论在什么软件中，也不论什么语言。也就是说，它世界上使用的所有字符都列出来，并给每一个字符一个唯一特定数值。

   Unicode的最初目标，是用1个16位的编码来为超过65000字符提供映射。但这还不够，它不能覆盖全部历史上的文字，也不能解决传输的问题 (implantation head-ache's)，尤其在那些基于网络的应用中。已有的软件必须做大量的工作来程序16位的数据。
因此，Unicode用一些基本的保留字符制定了三套编码方式。它们分别是UTF-8,UTF-16和UTF-32。正如名字所示，在UTF－8中，字符是以8位序列来编码的，用一个或几个字节来表示一个字符。这种方式的最大好处，是UTF－8保留了ASCII字符的编码做为它的一部分，例如，在UTF－8 和ASCII中，“A”的编码都是0x41.

   UTF－16和UTF－32分别是Unicode的16位和32位编码方式。考虑到最初的目的，通常说的Unicode就是指UTF-16。在讨论Unicode时，搞清楚哪种编码方式非常重要。

UTF-8字符集编码

    Unicode Transformation Format-8bit，允许含BOM，但通常不含BOM。是用以解决国际上字符的一种多字节编码，它对英文使用8位（即一个字节），中文使用24为（三个字节）来编码。UTF-8包含全世界所有国家需要用到的字符，是国际编码，通用性强。UTF-8编码的文字可以在各国支持UTF8字符集的浏览器上显示。如，如果是UTF8编码，则在外国人的英文IE上也能显示中文，他们无需下载IE的中文语言支持包。

   GBK的文字编码是用双字节来表示的，即不论中、英文字符均使用双字节来表示，为了区分中文，将其最高位都设定成1。GBK包含全部中文字符，是国家编码，通用性比UTF8差，不过UTF8占用的数据库比GBD大。

   GBK、GB2312等与UTF8之间都必须通过Unicode编码才能相互转换：

    GBK、GB2312－－Unicode－－UTF8

    UTF8－－Unicode－－GBK、GB2312

对于一个网站、论坛来说，如果英文字符较多，则建议使用UTF－8节省空间。不过现在很多论坛的插件一般只支持GBK。