dbca建库必须在“character sets”页显式选al32utf8；该页仅在advanced install中可见，typical install会隐藏；选“use unicode (al32utf8)”而非已弃用的utf8；建库后无法安全修改字符集，alter database character set al32utf8会报ora-12712，internal_use方式会导致乱码且失去官方支持；验证需查nls_database_parameters、nls_instance_parameters及客户端nls_lang；静默安装response file中必须精确指定characterset=al32utf8和nationalcharacterset=al16utf16。
DBCA建库必须在“Character Sets”页显式选AL32UTF8
AL32UTF8不是默认值，哪怕你用的是Oracle 12.2+，DBCA在Typical install模式下仍会隐藏该配置页——它只在Advanced install中暴露。跳过这一步，数据库底层就固化为操作系统locale字符集（比如WE8MSWIN1252或ZHS16GBK），后续无法安全变更。
关键操作位置在DBCA流程中：完成模板选择后、“Storage”配置前，会出现一个叫“Character Sets”的独立页面。这里有两个易混淆选项：
-
Use Unicode (AL32UTF8)—— 必须选这个，它是Oracle官方推荐的完整UTF-8实现，支持emoji、越南语、代理对等全部Unicode字符 -
Use national character set (UTF8)—— 这是已弃用的旧版兼容模式，不支持代理对，不要选
勾选前者后，NATIONAL CHARACTER SET会自动设为AL16UTF16，这是标准搭配，手动改反而可能触发ORA-01092。
为什么不能建完再ALTER DATABASE CHARACTER SET AL32UTF8
执行ALTER DATABASE CHARACTER SET AL32UTF8几乎必然报ORA-12712: new character set must be a superset of old character set。这不是提示，是Oracle内核级硬校验：它只允许从严格子集升到超集（如ZHS16GBK → AL32UTF8理论上成立），但只要库非空，就会因已有索引、LOB、数据字典内容而拒绝执行。
网上流传的ALTER DATABASE CHARACTER SET INTERNAL_USE AL32UTF8属于未公开内部命令，绕过校验但后果严重：
- 不校验现有数据能否无损映射，中文字段可能直接变成乱码字节
- Oracle Support合同失效，出问题官方不认
- 后续升级（如19c→21c）大概率失败
验证AL32UTF8是否生效的三个必要检查点
建库完成后别急着连应用，先确认三处是否一致：
- 查数据库级字符集：
SELECT VALUE FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET';—— 必须返回AL32UTF8 - 查实例级设置：
SELECT * FROM NLS_INSTANCE_PARAMETERS WHERE PARAMETER = 'NLS_LANGUAGE';—— 确保没被init.ora或spfile里残留的NLS_LANG覆盖 - 查客户端环境变量（如SQL*Plus连接前）：
echo $NLS_LANG（Linux）或echo %NLS_LANG%（Windows）—— 建议设为SIMPLIFIED CHINESE_CHINA.AL32UTF8，否则即使库是AL32UTF8，客户端解码仍可能错
这三个地方只要有一处不匹配，中文插入或查询就可能出现？、、乱码字节，且问题难以定位。
静默安装（response file）中必须显式指定CHARACTERSET
用dbca -silent建库时，response file里不能依赖默认值。必须包含这两行：
gdbName=orcl characterSet=AL32UTF8 nationalCharacterSet=AL16UTF16
漏掉characterSet=AL32UTF8，DBCA会退回到操作系统locale字符集；漏掉nationalCharacterSet，则可能因隐式推导失败导致建库中断或ORA-01092。
特别注意：response file中的characterSet值必须全大写、无空格、拼写精确——al32utf8、AL32UTF-8、AL32UTF8 （末尾空格）都会让DBCA静默忽略该配置，回退到默认。
