必须用 NVARCHAR2 声明参数和变量，因其强制使用国家字符集（如 AL16UTF16），原生支持 Unicode；VARCHAR2 依赖数据库字符集（如 ZHS16GBK），无法正确存储 UTF-8 来源的多语言字符。
必须用 NVARCHAR2 声明参数和变量，否则中文、日文等会变成问号或乱码。
为什么 VARCHAR2 不行而 NVARCHAR2 可以？
Oracle 默认的 VARCHAR2 依赖数据库字符集（如 ZHS16GBK），只能存本地化编码；一旦客户端或数据源用 UTF-8 发来越南文、emoji 或繁体字，VARCHAR2 就会截断或转成 。而 NVARCHAR2 强制走国家字符集（NLS_NCHAR_CHARACTERSET），通常是 AL16UTF16，原生支持所有 Unicode 字符。
检查当前国家字符集：SELECT * FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_NCHAR_CHARACTERSET';
常见错误现象：
– 存入 '日本語' 后查出来是 '???'
– LENGTH('中文') 返回 2，但 LENGTHB('中文') 返回 4 → 说明用了 UTF-16，但字段类型不匹配导致隐式转换失败
CONVERT 和 TO_NCHAR 到底该用哪个？
两者用途完全不同，混用会丢数据：
-
CONVERT是跨字符集转换函数，比如把ZHS16GBK编码的VARCHAR2转成AL32UTF8，但要求源数据本身编码正确，否则输入就是乱码，再转也没用 -
TO_NCHAR是类型强制转换：把VARCHAR2值按当前数据库字符集解释后，转成NCHAR/NVARCHAR2存储 —— 它不改变字节内容，只改类型标签，适合已知源数据编码可信时使用 - 如果输入来自外部系统（如 HTTP API 的 UTF-8 JSON），优先用
UTL_I18N.STRING_TO_RAW(str, 'AL32UTF8')+UTL_I18N.RAW_TO_CHAR(..., 'AL16UTF16')显式转码，比CONVERT更可控
存储过程里拼接多语言字符串的坑
直接用 || 拼接不同来源的字符串，极易触发隐式转换：
- 不要写：
v_result := v_name || ' - ' || v_desc;（若v_name是VARCHAR2，v_desc是NVARCHAR2，Oracle 会把后者转成数据库字符集，可能丢字） - 统一声明为
NVARCHAR2：v_name NVARCHAR2(100),v_desc NVARCHAR2(500),v_result NVARCHAR2(600) - 拼接前确认长度单位：
NVL(NLENGTH(v_name), 0) + NVL(NLENGTH(v_desc), 0) + 3 <= 600（NLENGTH按字符数，不是字节数） - 避免在 SQL 语句中混用：
INSERT INTO t VALUES (v_name || v_desc)→ 改成INSERT INTO t VALUES (TO_NCHAR(v_name) || TO_NCHAR(v_desc))，防止执行计划缓存时因绑定变量类型不一致出错
调用时没加 N 前缀就全白忙
即使存储过程内部全用 NVARCHAR2，调用时字面量不加 N 前缀，Oracle 仍按 VARCHAR2 解析：
- 错：
EXEC my_proc('张伟', '한국어');→ 这两个字符串被当VARCHAR2处理，进参前就可能已损坏 - 对：
EXEC my_proc(N'张伟', N'한국어'); - 如果是从应用层 JDBC 调用，确保设置
NLS_LANG=AMERICAN_AMERICA.AL32UTF8，且 PreparedStatement 绑定时用setNString()而非setString() - PL/SQL Developer 等工具里执行测试语句时，
N前缀不可省 —— 这点最容易忽略，因为看起来只是多敲两个字母
最常被跳过的环节是验证国家字符集是否真启用，以及调用方是否真正走 N 路径。只要其中一环是 VARCHAR2 或缺 N，前面所有 NVARCHAR2 声明都等于没做。
