Oracle数据库字符集问题解析

ruishi

还有两个相关问题：
1、前面说到，服务器：us7ascii ，客户端：us7ascii +OS（简体中文），这时会出现7位编码保存8位的编码，那么多出的一位如何处理（放到哪里）？
2、用length、substr时，这时相关函数能自动区别汉字与数字，如substr('1测试',1,2)的结果是‘1测’，那么这种情况是由字符集决定的吗，如果是的话，是由哪里的字符集设置决定的？

jeffli73

2.在服务器端字符集为iso8859，客户端字符集为：gb2312的环境下进行读取，存储测试！
insert into charset_test(server_charset,os_charset,client_charset,cn_char) values('ISO8859','GB2312','GB2312','中文');
select server_charset,os_charset,client_charset,cn_char,dump(cn_char) dump from charset_test where client_charset='GB2312' and os_charset='GB2312';

SERVER_CHARSET OS_CHARSET CLIENT_CHARSET CN_CHAR
-------------- -------------- -------------- --------------
DUMP
------------------------------
ISO8859 GB2312 GB2312 ？？
Typ=1 Len=2: 191,191
客户端字符集为：gb2312，汉字'中文'无法转换到iso8859-1字符集，存储到数据库的字符为（191），再次证明了（191）为iso8859-1字符集的替换字符。
当查询时，（191）在GB2312中没有对应字符，需要转换为替换字符，即中文问号“？”（A3 BF）。

另外，ruishi朋友，你的数据库字符集是创建时用的就是US7ASCII还是后来手工改的

ruishi

TO:jeffli73
是建库时就用US7ASCII

jeffli73

3.
SET NLS_LANG=AMERICAN_AMERICA.UTF8
client的设置本应与操作系统一致，在某些特殊情况下，为避免字符集转换，设置成与数据库字符集一致，而此时却人为设置成第三种字符集，肯定会造成混乱。
insert into charset_test(server_charset,os_charset,client_charset,cn_char) values('ISO8859','GB2312','UTF8','中文');
select server_charset,os_charset,client_charset,cn_char,dump(cn_char) dump from charset_test where client_charset='UTF8'

and os_charset='GB2312';

SERVER_CHARSET OS_CHARSET CLIENT_CHARSET
--------------------- --------------------- ---------------------
CN_CHAR DUMP
--------------------- ------------------------------
ISO8859 GB2312 UTF8
驴驴 Typ=1 Len=2: 191,191

此时'中文'实际用的GB2312的编码，而使用者却告诉Oracle这是UTF8的编码，转化为ISO8859-1，没有对应的字符，转换为替换字符（191,191）。
而在查询时，比较有意思，ISO8859-1的字符（191）可以转化为UTF8的字符，其对应字符为11000010 10111111（C2 BF），而操作系统使用的是GB2312编码，而（C2 BF）在GB码中对应的是“驴”字，所以显示为“驴”。

另外，请ruishi朋友在Oracle 9i下建库再试一下。

samechsu

感謝大大解說,
                         但我有一點不懂,書上說character set 只能在create DB時訂好,之後就不'能修改了, 請問是怎麼回事, thanks!

ygzeng

jeffli73,关于实验3，你的解释是正确的！我后来查了一下，具体过程可能是这样的：
存储的时候，由于ISO8859并不支持中文，输入的“中文”只能用替代字符“¿”（191）来替代！
读取的时候,根据UCS-2和UTF8的转换规则2,如果字符位于:0080 - 07FF则取11位,转换成为:110xxxxx 10xxxxxx,191(BF)位于这个区间,根据这个规则,其转换成C2BF),由于操作体统是GB2312,在GB2312中,驴的编码是:C2BF
samechsu，数据库安装之后，字符集只能从子集向超集转换，两个不兼容的数据库的字符集不能转换的！

jeffli73

对于ygzeng朋友上述解释有一些不同意见

本来在解释实验3时，也想用UCS-2和UTF8的转换规则，但考虑到本例的源字符集为ISO8859，是一个8位的字符集，而UCS-2是一个16位的字符集，这么解释逻辑上并不是很通。所以如下解释可能更为合理一些：ISO8859中的字符“¿”（191）在UTF8中对应的字符编码为11000010 10111111（C2 BF）。

ygzeng

Jeffli73,
Oracle中并不存在UCS（Unicode Character Set）这样的字符集，Unicode是以UTF8（UCS Transformation Format，变长字符集）或者UTF16（定长字符集）的形式存储的，你所说的“ISO8859中的字符“¿”（191）在UTF8中对应的字符编码为11000010 10111111（C2 BF）”，就是一个ucs-2到UTF8的转换过程，也就是，你的解释和我的解释好像没有什么区别！

yyy2004

学习

peterking

够深刻的，向您学习这种钻研精神