REF CURSOR 返回乱码本质是会话字符集与数据库字符集不一致导致解码失败，需通过SELECT value FROM nls_session_parameters WHERE parameter='NLS_CHARACTERSET'确认实际会话字符集，并在.NET连接字符串中显式设置charset=AL32UTF8强制对齐，而非依赖环境变量或错误别名UTF-8。
REF CURSOR 返回乱码，和存储过程逻辑无关，本质是字符集协商失败——OracleDataReader 读取列值时，用的是当前会话的 NLS_CHARACTERSET 解码，不是数据库字符集，也不是 JDBC 或 .NET 驱动自己猜的编码。
查清会话字符集是否被覆盖
很多问题卡在“以为连对了”，其实连接后会话字符集已偏离数据库设定。必须运行查询确认：
-
SELECT value FROM nls_session_parameters WHERE parameter = 'NLS_CHARACTERSET';—— 这才是REF CURSOR结果集里VARCHAR2列实际解码用的字符集 -
SELECT value FROM nls_database_parameters WHERE parameter = 'NLS_CHARACTERSET';—— 仅作对照，不决定结果集渲染
如果两者不一致（比如数据库是 AL32UTF8，但会话是 ZHS16GBK），哪怕数据存得再正确，OracleDataReader 也会按 ZHS16GBK 去解 UTF-8 字节流，必然出现 ???? 或错字。
.NET 中必须通过连接参数强制对齐会话字符集
Oracle.ManagedDataAccess 默认不读取系统 NLS_LANG，也不能靠环境变量或连接字符串里的 characterEncoding 参数生效。唯一可靠方式是显式传 charset 连接属性：
- 用
OracleConnectionStringBuilder设置：builder["charset"] = "AL32UTF8"; - 或在连接字符串末尾加：
;charset=AL32UTF8 - Spring Boot 用户注意：
spring.datasource.hikari.data-source-properties.charset=AL32UTF8才有效；connection-properties下写错位置会静默失效
错例：connection-string="...;Unicode=True;" 对 VARCHAR2 列无效；charset=UTF-8 是常见错写——Oracle 只认 AL32UTF8，不认 UTF-8 别名。
REF CURSOR 本身不携带字符集信息，全靠会话上下文
REF CURSOR 是服务端游标句柄，不是数据包。它不包含任何编码声明，驱动拿到句柄后，完全依赖当前会话的 NLS_CHARACTERSET 去解释后续 fetch 到的字节流。这意味着：
- 即使存储过程中用了
NCHAR或TO_CLOB，只要列类型是VARCHAR2，就走会话字符集 - 不能在 C# 侧用
Encoding.UTF8.GetString()手动解码——OracleDataReader已经按会话字符集解过了，二次解码只会雪上加霜 - 若必须混用多字符集（极少见），应改用
NVARCHAR2+NLS_NCHAR_CHARACTERSET，并确保会话的NLS_NCHAR_CONV_EXCP为FALSE
PL/SQL Developer 或 SQL*Plus 查看结果前先验证会话
图形工具常自动 fallback 或缓存旧会话，掩盖真实问题。执行 REF CURSOR 前务必确认：
- PL/SQL Developer：菜单 → Options → Oracle → Logon → “Use Oracle client character set” 必须取消勾选，并手动填入与数据库一致的字符集（如
AL32UTF8） - SQL*Plus：启动前设环境变量
NLS_LANG=AMERICAN_AMERICA.AL32UTF8（格式缺一不可），然后运行SELECT * FROM nls_session_parameters WHERE parameter = 'NLS_CHARACTERSET';确认生效 - 不要信工具右下角状态栏显示的“Charset: UTF8”——它可能是界面渲染层猜测值，不是真实会话值
真正容易被忽略的点：同一个连接串，在不同机器、不同用户环境变量下，会话字符集可能完全不同；而 REF CURSOR 乱码问题，90% 都发生在开发机连测试库、测试机连生产库这类跨环境场景里。
