一、背景
一直以来，很多用过ORACLE数据库的开发人员，都知道在ORACLE中，字符类型可以为varchar2，也可以为nvarchar2，但是很多人都不知道这两种类型有什么区别，同样还有char/nchar,clob/nclob这些，所以今天来谈谈我对这些数据类型的理解。
二、传言
老的oracle开发人员中，可能流传这这样一句传言，
“如果要省存储空间，建表时，字段内容里如果中文占了大多数，就用nvarchar2类型；如果内容是英文和数字为主的字符串，就用varchar2类型。”
首先说明一下，这句话在绝大多数情况下，的确是对的。
但是，这其实，是在特定的条件下，仅用例证得到的结论，后面会说明原因。
三、实验及分析
我们先做个实验，看看为什么会有上面这个传言
假设数据库字符集为AL32UTF8，建个表，两个字段，分别为varchar2和nvarchar2，插入数字、英文字母、汉字
CREATE TABLE TEST_CHARSET (A VARCHAR2(100), B NVARCHAR2(100));
INSERT INTO TEST_CHARSET VALUES (12,n'12');
INSERT INTO TEST_CHARSET VALUES ('ab',n'ab');
INSERT INTO TEST_CHARSET VALUES ('啊',n'啊');
然后使用lengthb/dump等函数查看字节长度
select dump(a,1016),dump(b,1016),t.* from TEST_CHARSET t;
看上去，的确对于汉字，nvarchar2的长度比varchar2要短，看上去不论啥字符插入到nvarchar2中都是2个字节，对于数字和字母就太占空间了。
但是，nvarchar2的字符集显示的是AL16UTF16，而非varchar2对应字段中的AL32UTF8
所以，我们得回头看看，nvarchar2这个数据类型到底是什么
官方文档说
数据类型指定国家字符集中的NVARCHAR2变长字符串。创建数据库时，将国家字符集指定为 AL16UTF16 或 UTF8。AL16UTF16 和 UTF8 是 Unicode 字符集的两种编码形式（对应的 UTF-16 和 CESU-8），因此NVARCHAR2是仅限 Unicode 的数据类型。
在21c数据库创建界面中可以看到，数据库默认字符集编码为AL32UTF8,国家字符集编码默认为AL16UTF16,可选UTF8。
文档说
一个代码点在 AL16UTF16 中始终具有 2 个字节，在 UTF8 中始终具有 1 到 3 个字节，具体取决于代码点编码的特定字符。
文档此处存在歧义，AL16UTF16也会有4个字节的情况，比如
SELECT UTL_I18N.raw_to_Nchar('D840DC43'),
DUMP(UTL_I18N.raw_to_Nchar('D840DC43'),1016) FROM DUAL;
Oracle Database 21c 支持 Unicode 版本 12.1
我特意去翻了unicode12.1版本的文档，发现补充码的部分对应不上，所以ORACLE这句话其实是有前提条件的
https://www.unicode.org/Public/12.1.0/charts/CodeCharts.pdf
oracle的UTF-8为1到3个字节，而unicode标准中的UTF-8是1~4个字节，所以oracle的UTF-8也不符合unicode标准，甚至还会把unicode中FFFF后面的字符，转换成6个字节来进行存储，比如unicode编码20043（𠁃），对应的UTF-16的D840DC43，存成UTF-8则为eda180edb183,但按照UNICODE标准，它的UTF-8编码应该为F0A08183
其实默认情况下，oracle中的UTF-8根本就不是UTF-8，而是CESU-8，这个在ORACLE官方文档中有提到
https://docs.oracle.com/en/database/oracle/oracle-database/21/sqlrf/Data-Types.html#GUID-CC15FC97-BE94-4FA4-994A-6DDF7F1A9904
AL16UTF16 和 UTF8 是 Unicode 字符集的两种编码形式（对应的 UTF-16 和 CESU-8）
而且ORACLE官方文档还这么说了
https://docs.oracle.com/en/database/oracle/oracle-database/21/nlspg/supporting-multilingual-databases-with-unicode.html#GUID-F3B0B4F7-B6D9-473D-840F-F98998F37981
CESU-8 不是核心 Unicode 标准的一部分。Unicode 联盟发布的 Unicode 技术报告 #26 对此进行了描述。CESU-8 是一种与 UTF-8 相同的兼容性编码形式，除了它的补充字符表示。在 CESU-8 中，补充字符被表示为代理对，就像在 UTF-16 中一样。要获得补充字符的 CESU-8 编码，首先将字符编码为 UTF-16，然后将每个代理代码单元视为具有相同值的代码点。然后，将 UTF-8 编码规则（位转换）应用于每个代码点。这将产生两个三字节表示，总共六个字节。
CESU-8 只有两个好处：
它具有与 UTF-16 相同的二进制排序顺序。
每个字符使用相同数量的代码（一个或两个）。这对于字符串处理中的字符长度语义很重要。
一般来说，应尽可能避免使用 CESU-8 编码形式。
关于CESU-8，可以参考下面这个对比
（此表来自https://infogalactic.com/info/CESU-8）
在unicode官方文档中也有一些介绍
https://www.unicode.org/reports/tr26/tr26-2.html
oracle文档中虽然体现出UTF-8和AL32UTF8不是同一种编码
| Character Set | Supported in RDBMS Release | Unicode Encoding Form | Unicode Version | Database Character Set | National Character Set |
|---|---|---|---|---|---|
| AL24UTFFSS | 7.2 to 8i | UTF-8 | 1.1 | Yes | No |
| UTF8 | 8.0 to 21c | CESU-8 | Oracle Database release 8.0 through Oracle8i Release 8.1.6: 2.1 | Yes | Yes |
| Oracle8i Database release 8.1.7 and later: 3.0 | (Oracle9i Database and later versions only) | ||||
| UTFE | 8.0 to 21c | UTF-EBCDIC | Oracle8i Database releases 8.0 through 8.1.6: 2.1 | YesFoot 1 | No |
| For Oracle8i Database release 8.1.7 and later: 3.0 | |||||
| AL32UTF8 | 9i to 21c | UTF-8 | Oracle9i Database release 1: 3.0 | Yes | No |
| Oracle9i Database release 2: 3.1 | |||||
| Oracle Database 10g, release 1: 3.2 | |||||
| Oracle Database 10g, release 2: 4.0 | |||||
| Oracle Database 11g: 5.0 | |||||
| Oracle Database 12c, release 1: 6.2 | |||||
| Oracle Database 12c, release 2: 7.0 | |||||
| Oracle Database 18c to Oracle Database 19c: 9.0 | |||||
| Oracle Database 21c: 12.1 | |||||
| AL16UTF16 | 9i to 21c | UTF-16 | Oracle9i Database release 1: 3.0 | No | Yes |
| Oracle9i Database release 2: 3.1 | |||||
| Oracle Database 10g, release 1: 3.2 | |||||
| Oracle Database 10g, release 2: 4.0 | |||||
| Oracle Database 11g: 5.0 | |||||
| Oracle Database 12c, release 1: 6.2 | |||||
| Oracle Database 12c, release 2: 7.0 | |||||
| Oracle Database 18c to Oracle Database 19c: 9.0 | |||||
| Oracle Database 21c: 12.1 |
但是，测试会发现，oracle中的AL32UTF8其实还是CESU-8的做法，
CREATE TABLE TEST_CHARSET (A VARCHAR2(100), B NVARCHAR2(100));
INSERT INTO TEST_CHARSET VALUES ('𠁃',n'𠁃');
select T.*,DUMP(A),dump(b) from TEST_CHARSET T;
而且可能还会导致严重的字符歧义，比如
SELECT UTL_I18N.raw_to_Nchar('D840DC43'),
TO_CHAR(UTL_I18N.raw_to_Nchar('D840DC43')) FROM DUAL;
再来看下面的例子,会发现第一列此时又符合UNICODE标准的UTF-8编码了。
也就是说，在ORACLE中，字段类型必须是国家字符集的字符数据类型才会符合UNICODE标准
(注意第四个值的二进制数据其实是对的，符合UTF8的4个字节，但是在非国家字符集的字符类型中无法正确解析)。
select
UTL_I18N.raw_to_Nchar(data => 'F0A08183', src_charset =>'AL32UTF8' ) N_UTF8,
UTL_I18N.raw_to_Nchar(data => 'D840DC43', src_charset =>'AL16UTF16' ) N_UTF16,
UTL_I18N.raw_to_char(data => 'eda180edb183', src_charset =>'AL32UTF8' ) UTF8,
UTL_I18N.raw_to_char(data => 'D840DC43', src_charset =>'AL16UTF16' ) UTF16,
DUMP( UTL_I18N.raw_to_char(data => 'D840DC43', src_charset =>'AL16UTF16' ) ,1016) UTF16_BINARY
FROM DUAL;
所以并不能说ORACLE不遵守UNICODE标准，而是它在兼容原有的CESU-8的基础上，另外提供了一种符合UNICODE标准的方式，即使用国家字符集的字符数据类型来进行数据存储。
四、回顾相关函数
- ascii 传入一个字符，varchar/char类型根据数据库字符集，nvarchar/nchar根据国家字符集，转换成对应的十进制码点
- nchr 将一个十进制数字，根据国家字符集，转换成对应的一个字符
- chr(n) 将一个十进制数字，根据数据库字符集，转换成对应的一个字符
- chr(n using NCHAR_CS) 将一个十进制数字，根据国家字符集，转换成对应的一个字符（等同于nchr）
- unistr 将包含有国家字符集十六进制码点的字符串，转换成人类可识别的字符串
- asciistr 将一个字符串中所有的非ascii字符，根据国家字符集转换成对应的十六进制码点
也就是说，以上的函数，其实都隐含了两个不确定的参数，即数据库字符集和国家字符集。而这两个字符集，在建库的时候可以指定。也就是说，如果建库的时候不是选择的默认值，那么这些函数的查询结果就可能会有不同。
五、推翻传言
经过以上实验分析及相关资料查询后，我们可以做个这样的实验：
创建一个新库，把数据库字符集设置成ZHS16GBK，把国家字符集设置成UTF-8，
那么存入一个常见汉字到varchar2中会占2个字节，存入到nvarchar2中则占3个字节；存入一个英文字母到varchar2中和nvarchar2中均占1个字节，
传言被推翻。
当然，绝大多数情况下，不会有谁把国家字符集选择成UTF-8，甚至连ORACLE官方文档都是强烈建议，国家字符集要选AL16UTF16，所以本文前面说的这个传言依旧具有一定的指导意义。
六、数据长度
关于NVARCHAR2类型的长度
- 在MAX_STRING_SIZE = STANDARD时，
VARCHAR2的最大长度为4000个字节，且建表时，既可以指定最大字节长度也可以指定最大字符个数；
而nvarchar2只能指定最大字符个数，在国家字符集为AL16UTF16时，最大字符个数为2000；在国家字符集为UTF-8时，最大字符个数为4000。但实际上，它限定的最大存储长度依然只能是4000个字节，尽管指定它的列长度时的数字，并不能指定字节数。 - 在MAX_STRING_SIZE = EXTENDED时，相应的长度上限也会扩大。但同样，它的最大存储长度只能是32767个字节，而且指定列长度时只能指定字符个数
| 国家字符集 | NCHAR 数据类型的最大列大小 | NVARCHAR2 数据类型的最大列大小（当 MAX_STRING_SIZE = STANDARD 时） | NVARCHAR2 数据类型的最大列大小（当 MAX_STRING_SIZE = EXTENDED 时） |
|---|---|---|---|
| AL16UTF16 | 1000 个字符 | 2000 个字符 | 16383 个字符 |
| UTF8 | 2000 个字符 | 4000 个字符 | 32767 个字符 |
（注：MAX_STRING_SIZE参数是在oracle12c版本中新增的
https://docs.oracle.com/en/database/oracle/oracle-database/21/refrn/MAX_STRING_SIZE.html#GUID-D424D23B-0933-425F-BC69-9C0E6724693C
）
length函数查的是什么？
一直以来，网上各种教程里都是说，lengthb查的是字节数，length查的是字符数。但ORACLE里的字符数，计算标准其实也有很多种，像下面的这个一个汉字，用length函数查它竟然是2个字符！因为length不是按照unicode标准来进行统计的,lengthc才是，另外还有针对UCS2/UCS4标准的长度计算函数
select
length('𠁃') n,
unistr('\D840\DC43') str,
dump(unistr('\D840\DC43'),1016) dp,
lengthb(unistr('\D840\DC43')) lenb,
length(unistr('\D840\DC43')) len,
lengthc(unistr('\D840\DC43'))lenc,
length2(unistr('\D840\DC43')) len2,
length4(unistr('\D840\DC43')) len4
from dual
所以，如果ORACLE 11g中的国家字符集为AL16UTF16，对于nvarchar2(2000)字段，是有可能存入1000个字就满了的（全部存UTF-16编码为4个字节的补充字符的情况下）
七、国家字符集的使用场景
-
假设数据库字符集为ZHS16GBK，某次需要插入一个在这个字符集中不存在的汉字或其他语言的字符，该如何处理？
数据库的字符集建库时就确定了，不能轻易修改，如果把字段类型设置成国家字符集的数据类型，比如nvarchar2，那么就可以把这个ZHS16GBK中不存在的字符存进去了。（如果是子集改成母集，且不用对数据进行编码转换，那么可以使用DMU进行快速字符集修改）
-
某公司正在使用的一个纯英文的软件，对应的数据库字符集为WE8MSWIN1252,该软件把所有UI菜单及选项的描述都存在了数据库中，当该软件需要扩展多国语言时，只需要把描述列改成NVARCHAR2，然后增加一个语言ID，相关查询接口增加语言ID的逻辑，客户端代码采用UTF8，即可在不用重建数据库的情况下，扩展出UI多语言支持。
总结
ORACLE以标准名称命名非标准的东西，而且时而标准时而不标准，的确很让人犯迷糊，我根据本文总结几点
- ORACLE默认国家字符集为AL16UTF16，完全对应UNICODE的UTF-16标准
- ORACLE中的国家字符集，只有在数据类型为NCHAR/NVARCHAR/NCLOB时才会被使用，也就是前面带N(national)的字符类型
- ORACLE中的UTF-8，不是标准的UTF-8，而是CESU-8
- 尽管ORACLE称AL32UTF8是符合UNICODE标准的，但在VARCHAR2类型时体现的依然是CESU-8的特征(单个字符1~3字节，补充字符6字节)
- UNICODE码点在FFFF之前的，其码点和AL16UTF16完全一致，但更大的码点（补充码）就和AL16UTF16不一致了
- ORACLE的length函数把单个补充码字符的字符长度算为2
- UNISTR和ASCIISTR是用国家字符集转换，并非完全是UNICODE编码（不要拿着长度为5的unicode码去转换了，要找到对应4个字节的UTF-16编码去转，AL16UTF16的UNISTR只认"\xxxx"或“\xxxx\xxxx”的格式）
- UNICODE补充字符，存储为UNICODE标准的UTF-8编码，且能无需函数转换，直接select显示出正确字符的，在ORACLE中不支持，需要使用UTL_I18N包来处理，比如
select UTL_I18N.raw_to_Nchar(data => 'F0A08183', src_charset =>'AL32UTF8' ) from dual;
