oracle 中文靠字,oracle“靠”字的困惑

--

请参考：

--

3.8 “靠”字的困惑 ( P109 )

......

--

*(1) 客户端应用字符集(Client Application Character Set)。测试客户端应用使用命令行工具(cmd.exe)，

--

这个工具的字符集决定查询结果在终端上的输出显示，当前命令行工具的字符代码页为936，对应的是GBK字符集，如图3-11所示。

D:\

>

cmdD:\

>

chcp

--

*(2) 客户端NLS_LANG参数设置。为了测试异常情况，设置NLS_LANG为AMERICAN_AMERICA.WE8ISO8859P1：

D:\

>

set

NLS_LANG

=

AMERICAN_AMERICA.WE8ISO8859P1

--

*(3) 服务器端，数据库字符集(Character Set)设置。其数据库的字符集为ZHS16GBK。

--

首先在数据库上创建一个测试表，存储一点中文数据：

SQL

>

create

table

tcharset (name

varchar2

(

40

));SQL

>

insert

into

tcharset

values

(

'

循序渐进深入浅出

'

);

--

然后在客户端WE8ISO8859P1字符集下执行查询：

D:\

>

set

NLS_LANG

=

AMERICAN_AMERICA.WE8ISO8859P1D:\

>

sqlplus eygle

/

eygle

@eygle

......scott

@SZTYORA

>

select

*

from

tcharset;NAME

--

--------------------------------------

靠靠靠靠

--

现在我们看到8个汉字被转换成4个“靠”字输出显示？这是怎么回事呢？

--

我们知道，Oracle 数据库服务器是传输代码给客户端的，数据本身不存在问题，编码会原样传输到客户段：

SQL

>

select

name,

dump

(name)

from

tcharset;NAME

DUMP

(NAME)

--

---------- -------------------------------------------------------------------------------------------------------------

靠靠靠靠 Typ

=

1

Len

=

24

:

229

,

190

,

170

,

229

,

186

,

143

,

230

,

184

,

144

,

232

,

191

,

155

,

230

,

183

,

177

,

229

,

133

,

165

,

230

,

181

,

133

,

229

,

135

,

186

--

那么可以确认存在问题的只是中间发生的转换环节。由于WE8ISO8859P1是8位的单Byte编码方案，所以中文汉字编码在其中不存在对应关系，

--

也就是无法转换，此时WE8ISO8859P1字符集会使用一个替换字符来代替中文，这个替换字符是“ ”，也就是一个倒过来的“?”，不同字符集的替换字符，

--

我们可以通过Locale Builder工具打开字符文件查看，如图3-12所示。

......

--

注意这个特殊字符的编码为BF，那么也就是说，如果无法转换ZHS16GBK的8个中文字，WE8ISO8859P1将使用8个“ ”来替换，也就是说经过替换之后，

--

我们有了8个BF的编码，那么我们再来看看8个BF在客户端的GBK字符集里代表了什么：

--

通过微软网站上的936代码页我们可以找到如图3-13所示的图表。

......

--

提示

--

936代码页的网址链接为 http://www.microsoft.com/globaldev/reference/dbcs/936.htm 。

--

从图3-13中可以看到，其中BFBF正好代表汉字“靠”，于是8个BF最后展现出来就变成了4个“靠”字。

--

也就可以通过ZHS16GBK字符集文件来找到这个编码，再者是一致的，如图3-14所示。

......

--

这也就是不同字符集、应用之间转换导致的字符集问题。