ODP.NET托管驱动（Oracle.ManagedDataAccess）不读NLS_LANG，乱码主因是默认依赖系统区域设置推导字符集且不可靠；应弃用NLS_LANG，连接字符串中设Unicode=True强制UTF-16编码。
ODP.NET 连接 Oracle 时中文乱码，NLS_LANG 不生效？
根本原因不是环境变量没配，而是 odp.net（尤其是 12c+ 的托管驱动 oracle.manageddataaccess）压根不读 nls_lang。它默认用 windows 系统区域设置推导客户端字符集，且这个推导不可靠——比如系统是中文但控制台代码页是 936，而数据库是 al32utf8，中间就容易错位。
实操建议：
- 彻底放弃在 Windows 上设
NLS_LANG环境变量，对托管驱动无效，还可能干扰其他 Oracle 工具（如 SQL*Plus） - 改用连接字符串显式指定字符集：
Data Source=...;User Id=...;Password=...;Unicode=True;——Unicode=True是关键，它强制驱动走 UTF-16 编码路径，绕过 NLS 推导 - 如果必须兼容非 Unicode 场景（极少见），才考虑用原生驱动
Oracle.DataAccess（需安装 Oracle Client），它才真正读NLS_LANG
Oracle.ManagedDataAccess 下 Unicode=True 和 Unicode=False 的实际区别
这不是“是否支持 Unicode”的开关，而是底层字符编码策略切换：
-
Unicode=True：所有string参数、返回值按 UTF-16 处理，与 .NET 字符串天然一致；数据库侧需确保字符集支持 UTF-8（如 AL32UTF8）或能正确转换 -
Unicode=False：驱动尝试按系统代码页（如 936）解释字节，再转成 .NET string——这步极易出错，尤其当数据库字符集与系统代码页不匹配时，SELECT出来就是乱码，INSERT还可能报ORA-01401: inserted value too large for column - 性能上无明显差异，但
Unicode=True更稳定，推荐作为默认值
Windows 系统区域设置影响 Oracle.ManagedDataAccess 吗？
只在 Unicode=False 时起作用，且仅用于猜测“客户端该用什么字符集”，非常脆弱。
常见错误现象：
- 开发机系统设为“中文（简体，中国）”，测试机设为“英语（美国）”，同一段代码连同一库，一个正常一个乱码
- Windows Server 默认区域可能是英文，但数据库是中文字符集，结果插入中文报
ORA-12704: character set mismatch
所以别依赖它。真实做法：
- 统一在连接字符串加
Unicode=True - 确保数据库字符集是
AL32UTF8（推荐）或至少与应用层可映射（如 ZHS16GBK） - 检查应用部署目标机的 .NET 版本：.NET Core 3.1+ 和 .NET 5+ 对 Unicode 处理更一致，旧版 Framework 有少量边界 case
为什么改了 NLS_LANG 环境变量，sqlplus 好使但 C# 程序还是乱码？
因为 sqlplus 用的是 Oracle Client（原生驱动），它真读 NLS_LANG；而你的 C# 项目大概率引用的是 Oracle.ManagedDataAccess，它是纯托管实现，不调用任何 Oracle Client DLL，也不查环境变量。
验证方法：
- 查项目引用：如果是
Oracle.ManagedDataAccess.dll，那NLS_LANG就是摆设 - 看连接字符串里有没有
Unicode=，没有就补上 - 临时加一行日志：
Console.WriteLine($"CurrentCulture: {CultureInfo.CurrentCulture}, CurrentUICulture: {CultureInfo.CurrentUICulture}");—— 这些只是参考，不影响 ODP.NET 行为
最省事的解法：删掉所有 NLS_LANG 相关环境变量，专注把连接字符串写对。复杂点在于，很多人混用托管/非托管驱动，或者以为装了 Oracle Client 就自动生效，其实完全两套机制。
