Oracle数据库字符集问题解析

wangkxxe

支持LZ，谢谢

wangkxxe

字符集总是首先去了解

hhphaipeng

学习了

king821123

好帖，顶了再看

ai2ming

我在Oracle 10.2的测试中，发现实验结果分析五所说情况下的存储结果为????。我猜测是Oracle 10g在将汉字转为US7ASCII的时候，对超过127的内容都编码为?了。

Yong Huang

原帖由 ai2ming 于 2009-12-8 05:01 发表
我在Oracle 10.2的测试中，发现实验结果分析五所说情况下的存储结果为????。我猜测是Oracle 10g在将汉字转为US7ASCII的时候，对超过127的内容都编码为?了。

Sounds like an interesting test. Please start a new thread and use a more meaningful subject. Show your test details excluding the lines that are completely irrelevant.

Yong Huang

oraclewlm

好帖，顶一下

scott_0620

先收藏了。谢谢LZ

liyuangong

有空好好看谢谢

tanwen321

实验结果分析四里的时候，当oracle将ZHS16GBK中的“东北”转化为US7ASCII，是这样的
当客户端字符集设置为ZHS16GBK后向数据库插入“东北”，Oracle检查发现数据库设置的字符集为US7ASCII与客户端不一致，需要进行转换，但字符集ZHS16GBK中的“东北”两字在US7ASCII中没有对应的字符，所以Oracle用统一的“替换字符”插入数据库，在这里为“？”，编码为63（00111111），这时，输入的信息实际上已经丢失，不管字符集设置如何改变（如下面引用的实验结果），第二行SELECT出来的结果也都是两个“？”号（注意是2个，而不是4个）。

实验结果分析五里，当向字符集为ZHS16GBK的数据库中插入“东北”，客户端设置US7ASCII，这个转化
在客户端字符集设置为US7ASCII时，向字符集为ZHS16GBK的数据库中插入“东北”，需要进行字符转换，“东北”的ZHS16GBK编码为 182（10110110）、171（10101011）与177（10110001）、177（10110001），由于US7ASCII为7bit编码，Oracle将这两个汉字当作四个字符，并忽略各字节的最高位，从而存入数据库的编码就变成了54（00110110）、43（00101011）与 49（00110001）、49（00110001），也就是“6+11”，原始信息被改变了。


这2个个转化都是ZHS16GBK编码的“东北”向US7ASCII转化，为什么却是不同的结果。oracle自动转化和客户端的转化是不同的？？