必须手动设置clientcharacterset，因为oracle.manageddataaccess是纯托管驱动，不读取nls_lang环境变量或系统区域设置，默认按us7ascii解析字符串，若数据库字符集为zhs16gbk或al32utf8则导致中文乱码。
oracle.manageddataaccess 默认不自动识别客户端字符集，中文乱码通常是因为 clientcharacterset 未显式设置或与数据库实际字符集（如 zhs16gbk 或 al32utf8）不匹配。
为什么必须手动设置 ClientCharacterSet？
Oracle.ManagedDataAccess 是纯托管驱动，不读取本地 oraclient 的 oradata\NLS_LANG 环境变量，也不继承系统区域设置。它默认按 US7ASCII 解析字符串，一旦数据库用的是 ZHS16GBK 或 AL32UTF8，插入/查询中文就会变成问号或乱码。
- 仅靠连接字符串加
Unicode=True不解决服务端字符集映射问题 -
NLS_LANG环境变量对托管驱动完全无效 - 数据库字符集（
SELECT * FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET';）决定你该配什么值
如何在连接字符串中正确配置 ClientCharacterSet
该参数必须作为连接字符串的一部分传入，且值需与数据库字符集严格一致（大小写敏感），不能拼错。
- 查数据库字符集：
SELECT VALUE FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET'; - 若返回
ZHS16GBK，连接字符串要加：ClientCharacterSet=ZHS16GBK - 若返回
AL32UTF8，则必须写：ClientCharacterSet=AL32UTF8（不是UTF8或UTF-8） - 完整示例：
Data Source=ORCL;User Id=scott;Password=tiger;ClientCharacterSet=ZHS16GBK;
代码中动态设置 ClientCharacterSet 的替代方式
如果连接字符串由配置中心或运行时拼接，也可以通过 OracleConnectionStringBuilder 构建，避免字符串拼接出错：
Teleport tsh SSH (Identity-First SSH Access, no passwords/static keys)
下载
使用tbot机器ID身份文件配合tsh CLI，通过Teleport访问控制SSH登录托管主机或执行远程命令。
var builder = new OracleConnectionStringBuilder
{
DataSource = "ORCL",
UserID = "scott",
Password = "tiger",
ClientCharacterSet = "ZHS16GBK" // 必须显式赋值
};
using var conn = new OracleConnection(builder.ConnectionString);
conn.Open();
- 不要在
Open()后再改连接字符串——此时已无效 -
ClientCharacterSet是只读属性，只能在构造连接字符串阶段指定 - 若用
OracleConfiguration.ClientCharacterSet静态属性（.NET Framework 4.6+），它仅影响后续新建的连接，且线程不安全，不推荐
常见错误现象和排查点
即使设置了 ClientCharacterSet，仍乱码？重点检查这几个地方：
- 数据库字符集和
ClientCharacterSet值是否完全一致（包括大小写、拼写，AL32UTF8≠UTF8） - 连接字符串是否被中间件（如连接池、EF Core 连接工厂）二次解析并丢弃了自定义参数
- 是否误把
NLS_LANGUAGE或NLS_TERRITORY当成字符集参数加了进去 - 执行
INSERT时用的是参数化查询（✅）还是字符串拼接（❌）？后者绕过编码处理，必然乱码
最稳妥的验证方式：用相同连接字符串在 SQL Developer 或 Oracle SQLcl 中执行相同语句，确认服务端能正常显示；再比对 .NET 端输出——如果工具正常而代码异常，基本可锁定是 ClientCharacterSet 配置或使用姿势问题。
