改nls_lang能解决乱码是因为它控制客户端字节流的编解码方式，但非万能：若服务端为us7ascii等不支持中文的字符集，nls_lang无法修复底层存储缺陷，此时需升级数据库字符集或在应用层手动转换。
为什么改 nls_lang 能解决乱码，但不是万能的
因为 oracle 客户端（比如 odp.net core）在建立连接时，会读取 nls_lang 环境变量来决定如何解释传输的字节流。它不参与 sql 解析，只影响字符编码转换环节：客户端把 .net 字符串编码成字节发给服务端、再把服务端返回的字节解码成字符串时，都依赖这个设置。
但它只生效于「客户端字符集」那一层，无法绕过数据库本身的 NLS_CHARACTERSET。如果服务端是 US7ASCII，而你硬设 NLS_LANG=AMERICAN_AMERICA.AL32UTF8，Oracle 仍会按单字节规则存/取数据，结果就是中文被截断或错位——此时改环境变量反而让问题更隐蔽。
- 必须先查清服务端字符集：
SELECT VALUE FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET'; -
NLS_LANG的第三段（字符集部分）应与服务端一致，或为它的超集（如服务端是ZHS16GBK，可设为AL32UTF8；但反过来不行） - Windows 下设环境变量后，需重启应用进程（不是 IIS 或 Kestrel 重载，是彻底杀掉 dotnet.exe 进程）才生效
.NET Core 中设置 NLS_LANG 的实际方式
不能只靠 Windows 系统级环境变量，尤其在容器化或跨平台部署时。ODP.NET Core 会按以下顺序查找 NLS_LANG：
- 进程启动时已存在的环境变量（最高优先级）
- 连接字符串里显式指定的
Unicode=True或Charset=AL32UTF8（仅限部分驱动支持） - 配置文件（如
appsettings.json）中未被 ODP.NET 读取，无效
推荐做法是在程序启动前注入：
// Program.cs 开头，早于任何 Oracle 连接初始化
Environment.SetEnvironmentVariable("NLS_LANG", "AMERICAN_AMERICA.AL32UTF8");
注意：AMERICAN_AMERICA 是语言+地区组合，只要不涉及日期/货币格式定制，用这个最稳；字符集部分必须匹配服务端或兼容（如服务端是 ZHS16GBK，这里填 ZHS16GBK 更安全）。
连接字符串里加 Unicode=True 为什么有时没用
这是 ODP.NET Core 的一个常见误解点。Unicode=True 并不等价于设置字符集，它只强制驱动使用 Unicode 编码路径（即内部走 UTF-16 ↔ UTF-8 转换），但底层仍依赖 NLS_LANG 告诉 Oracle 服务端“你该用什么字符集跟我对话”。
- 若服务端是
AL32UTF8，Unicode=True+ 正确NLS_LANG可以工作 - 若服务端是
ZHS16GBK，Unicode=True反而可能触发额外转换，导致双编码（如中文变问号再变乱码） - 在 .NET 6+ 使用
Oracle.ManagedDataAccess.Core时，Unicode=True已被标记为 legacy，官方建议直接靠NLS_LANG控制
遇到 US7ASCII 数据库时，NLS_LANG 不是解药
这是最棘手的情况：服务端字符集根本不支持中文，所有中文都是靠“错位存储”蒙混过关（比如用两个 ASCII 字节假装一个 GBK 字）。此时无论怎么调 NLS_LANG，.NET Core 拿到的始终是错误字节序列。
可行路径只有两条：
- 升级数据库字符集（停机风险高，需 DBA 配合，且历史数据可能损坏）
- 在 ORM 层做透传转换：用
RAWTOHEX()查字段，再用Encoding.GetEncoding("GB2312").GetString(Convert.FromHexString(...))在 C# 侧还原（注意：必须知道原始录入时用的是哪种编码，常见是GB2312或GBK）
别指望连接层自动修复——NLS_LANG 在这种场景下只是让乱码变得更“稳定”，而不是变正确。
