上一篇讲到普通字符串的转换，本篇将讲到国家字符集字符串的转换：
客户端的NLS_LANG为默认值，即ZHS16GBK：
SQL> create table t1 ( id number ,aa varchar2(20),bb nvarchar2(20));
表已创建。
SQL> insert into t1 values (1,'中','中');
已创建 1 行。
捕获的网络包如下：
00000090 00 00 00 00 00 00 EA 4E DB 00 AC 0D DC 00 00 00 .......N........
000000A0 00 00 23 69 6E 73 65 72 74 20 69 6E 74 6F 20 74 ..#insert.into.t
000000B0 31 20 76 61 6C 75 65 73 20 28 31 2C 27D6 D027 1.values.(1,'..'
000000C0 2C 27D6 D027 29 01 00 00 00 01 00 00 00 00 00 ,'..')..........
SQL> select dump(aa) aa,dump(bb) bb from t1;
AA BB
------------------------------ ------------------------------
Typ=1 Len=2: 214,208 Typ=1 Len=2: 78,45
客户端发送给数据库的SQL语句，两个“中”字均为D6 D0，但服务器对NVARCHAR2类似的列作了转换，将其从ZHS16GBK编码转换为AL16UTF16，转换后的结果为10进制78，45,即16进制的4E 2D
因此对于国家字符集，客户端在提交SQL时实际并不区分是否国家字符集，统一将SQL中的字符转换为数据库字符集，服务器端再将国家字符集的列，从数据集字符集转换为国家字符集。因此，我们可以设想，如果数据库字符集与国家字符集不兼容，会发生什么？或者说是从数据库字符集转换为国家字符集是不是也会出现问题？我们用另一个数据库测试一下：
SQL> select * from nls_database_parameters where parameter like '%CHARACTERSET%'
;
PARAMETER VALUE
------------------------------ ------------------------------
NLS_CHARACTERSET US7ASCII
NLS_NCHAR_CHARACTERSET AL16UTF16
将客户端的NLS_LANG设置为AMERICAN_AMERICA.US7ASCII
SQL> create table t1 (id number,aa varchar2(20),bb nvarchar2(20));
SQL> insert into t1 values (1,'中','中');
1 row created.
SQL> select dump(aa) aa,dump(bb) bb from t1;
AA BB
------------------------------ ------------------------------
Typ=1 Len=2: 214,208 Typ=1 Len=4: 0,86,0,80
注意看这里dump出的结果，与前一个库dump出的结果，aa列是一样的，而bb列dump出来变成了10进制的0,86,0,80。我们看看这个值是怎么来的：
1.客户端NLS_LANG与数据库字符集相同，因此在客户端并没对SQL中的字符进行转换。
2.服务器在执行SQL时，将bb列的值从数据库字符集编码（10进制214，208）转换为AL16UTF16编码（这种编码每个字符为固定的两字节）。由于数据库字符集为单字节字符集，在转换时认为是两个字符，同时US7ASCII字符的高位应该为0，而214-128=86，208-128=80.因此转换后其结果就为字符串“VP"了：
SQL> select * from t1;
ID AA BB
---------- -------------------- --------------------
1 中 VP
因此，如果选择了错误的数据库字符集，虽然可以通过设置NLS_LANG将客户端字符集设置为与服务器字符集一致，但国家字符集却有可能不能正常地从数据库字符集转换为国家字符集。
下篇要讨论的是数据查询时和数据导出时的字符集转换。
no comment untill now