Oracle.ManagedDataAccess 默认不识别中文因不读取NLS_LANG环境变量或注册表，也不自动探测服务端字符集，客户端按US7ASCII解码导致乱码；需通过程序内SetEnvironmentVariable、_putenv或注册表设置NLS_LANG，或改用OleDb驱动绕过。
用 Oracle.ManagedDataAccess 默认会乱码，尤其对接老医院或政府系统时；必须配合 NLS_LANG 环境变量或连接字符串参数才能读对中文。
为什么 ODP.NET（Oracle.ManagedDataAccess）默认不认中文
它不读系统注册表或环境变量里的 NLS_LANG，也不自动探测服务端字符集。数据库是 ZHS16GBK 或 AL32UTF8，而客户端按 US7ASCII 解码，结果就是“”或问号。
- 服务端字符集查法：
SELECT * FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET'; -
Oracle.ManagedDataAccess的连接字符串里不能加编码参数，靠外部环境驱动行为 - 如果服务端是
US7ASCII，哪怕你本地设成ZHS16GBK，写入也会被截断或转成问号——这是 Oracle 底层限制，不是 .NET 的锅
设置 NLS_LANG 的三种实操方式（按推荐顺序）
优先选程序内设置，避免污染全局环境或依赖安装路径。
- 启动时用
System.Environment.SetEnvironmentVariable("NLS_LANG", "SIMPLIFIED CHINESE_CHINA.ZHS16GBK")——注意必须在new OracleConnection()之前调用，且只对当前进程有效 - 用
putenv更底层（兼容性更好）：[DllImport("msvcrt.dll")] private static extern int _putenv(string envString); _putenv("NLS_LANG=SIMPLIFIED CHINESE_CHINA.ZHS16GBK"); - 注册表方式（仅限 Windows 客户端）：修改
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraClient<version>_home1</version>下的NLS_LANG字符串值，需重启应用进程才生效
OleDb + OraOLEDB.Oracle 是绕过乱码的“备胎方案”
当没法改服务端、又不敢动生产环境变量时，OleDb 驱动反而更稳定——它直接走 Oracle 原生 OCI 层，受 NLS_LANG 影响小，且对 US7ASCII 服务端有隐式兼容逻辑。
- 连接字符串必须用
Provider=OraOLEDB.Oracle，别用已废弃的MSDAORA.1（64 位系统大概率失败） - 需要提前安装 ODAC（Oracle Data Access Components），否则报错
未注册数据提供程序 - 插入中文前仍建议手动编码转换：
Encoding.GetEncoding("gb2312").GetBytes(str)→ 绑定为byte[]参数，避免 SQL 拼接触发二次乱码
读取 US7ASCII 数据库时的字段级补救
如果连 NLS_LANG 都不能统一（比如只读权限、多租户混用），只能在读取后修复：
- 用
UTL_RAW.CAST_TO_RAW(column_name)把字段转成byte[]返回 - C# 侧用
Encoding.GetEncoding("ZHS16GBK").GetString((byte[])dr["col"])还原（注意判断是否为DBNull） - 不要用
Encoding.Default——它随系统区域变化，CI/CD 环境容易翻车
真正麻烦的不是连不上，而是你以为连上了、数据也“读出来”了，但每个中文都悄悄变成了错字——这种问题在线上跑几天才暴露，调试成本最高。
