RAW字段是纯二进制类型，无字符集含义；.NET默认返回byte[]，直接ToString()或误用Encoding解码会导致乱码，正确方式应按用途选择Guid接收、SQL层RAWTOHEX转字符串或明确用byte[]处理。
直接结论：RAW 字段本身不是字符串，.NET 默认按字节流处理，不乱码才是反常；所谓“乱码”，其实是你把它当字符串用了。
为什么 SYS_GUID() 或普通 RAW 字段在 .NET 里显示成乱码？
Oracle 的 RAW 是纯二进制类型，没有字符集含义。当你用 OracleCommand.ExecuteReader() 读取 RAW(16)（比如 SYS_GUID() 返回值），ADO.NET 默认返回 byte[]。如果你直接调用 .ToString()、或塞进 TextBox.Text、或用 Encoding.Default.GetString() 强转，就会出现不可读字符——这不是 Oracle 传错了，是你解错了。
-
SYS_GUID()返回的是 16 字节 RAW，不是 UTF-8 也不是 GBK 编码的文本 - 数据库工具（如 PL/SQL Developer）自动调用
RAWTOHEX()展示，掩盖了底层是二进制的事实 - .NET 不会自动 hex 转换，也不会猜你想怎么展示
正确读取 RAW 字段的三种方式（按场景选）
取决于你后续要做什么：
- 要存 GUID 做业务主键 → 用
Guid类型接收：Guid g = (Guid)reader["id"]; // 要求字段确实是 16 字节且符合 GUID 格式
- 要显示为可读字符串（如调试、日志） → 在 SQL 层转 HEX：
SELECT RAWTOHEX(sys_guid()) FROM DUAL;
然后在 C# 里按string读取，安全无坑 - 要保留原始字节做加密/签名等 → 明确读为
byte[]，别 toString：byte[] rawBytes = (byte[])reader["raw_col"];
后续用Convert.ToBase64String()或BitConverter.ToString()展示
常见错误操作与后果
这些写法看似省事，实际埋雷：
- 写
reader["col"].ToString()→ 返回类似"System.Byte[]"或乱码符号，因为byte[].ToString()不做内容转换 - 用
Encoding.UTF8.GetString((byte[])reader["col"])→ 报DecoderFallbackException或输出问号，因为 RAW 内容不满足 UTF-8 编码规则 - 在连接字符串里加
&characterEncoding=UTF-8→ Oracle JDBC 才认这个参数，.NET 的 Oracle.ManagedDataAccess 完全忽略它 - 试图改
NLS_LANG环境变量来影响 RAW → 无效，NLS_LANG只管CHAR/VARCHAR2/NVARCHAR2类型的字符集协商
生僻字 + RAW 混用时的特殊注意点
如果 RAW 字段里存的是人工构造的编码字节（比如用 UTL_RAW.cast_to_raw('䶮') 存生僻字），那它本质是“被编码过的字符串”。此时不能直接当 GUID 用，也不能硬套 UTF-8 解码：
- 先确认原始编码方式：是
ZHS16GBK？还是AL32UTF8？必须和UTL_RAW.cast_to_raw()的输入字符集一致 - 在 C# 中用对应
Encoding实例解码：Encoding.GetEncoding("gbk").GetString((byte[])reader["raw_col"]) - 更稳妥的做法：源头就别存 RAW，改用
NVARCHAR2字段 + 绑定参数，让 Oracle 自动处理字符集映射
最易被忽略的一点：RAW 字段没有“字符集”属性，它的解读完全由你的代码逻辑决定。查表时看到的 hex 值（如 36C3）只是视觉表示，真正传到 .NET 的永远是字节流——你得自己决定这 2 个字节代表一个汉字、半个 GUID，还是一段加密密钥。
