ODP.NET读取RAW(16)时Guid解析失败，因Oracle用大端序存储而.NET Guid构造器默认按小端序解析前8字节；需手动反转第0-3、4-5、6-7字节或启用连接字符串GuidMapping=True。
ODP.NET读取RAW(16)字段时，为什么Guid解析失败？
因为 oracle 的 raw(16) 默认按大端序（big-endian）存储，而 .net 的 system.guid 构造器和字节数组构造逻辑默认按小端序（little-endian）解释前4/2/2个字节——这会导致直接用 new guid((byte[])reader["id"]) 得到错误的 guid 值，看起来像随机乱码或抛 argumentexception。
- 典型错误现象：
Guid值与数据库中用RAWTOHEX查出的十六进制字符串明显不对应 - 只在 Windows 上“偶尔正常”：因为部分 ODP.NET 版本（尤其旧版）会隐式做端序转换，但行为不一致、不可靠
- 使用场景：从
SELECT id FROM users读取RAW(16)主键，或调用返回RAW的存储过程
用OracleDbType.Raw + 手动字节重排，安全读取为Guid
必须显式处理字节序。核心是把从 RAW(16) 读出的 16 字节按 Oracle 约定顺序重排成 .NET 能正确识别的格式。
- Oracle 存储顺序：[time_low(4)] [time_mid(2)] [time_hi_and_version(2)] [clock_seq_hi_and_reserved + clock_seq_low(2)] [node(6)]
- .NET
Guid(byte[])期望顺序：[time_low(4)←需反转] [time_mid(2)←需反转] [time_hi_and_version(2)←需反转] [clock_seq_hi_and_reserved + clock_seq_low(2)] [node(6)] - 实操建议：封装一个静态方法，避免每次手写重排逻辑
public static Guid ToGuidFromRaw16(byte[] rawBytes)
{
if (rawBytes == null || rawBytes.Length != 16) throw new ArgumentException();
// 反转前4字节（time_low）
Array.Reverse(rawBytes, 0, 4);
// 反转第4-5字节（time_mid）
Array.Reverse(rawBytes, 4, 2);
// 反转第6-7字节（time_hi_and_version）
Array.Reverse(rawBytes, 6, 2);
return new Guid(rawBytes);
}
向RAW(16)写入Guid时，别忘了反向字节重排
写入方向不能直接 guid.ToByteArray()，否则 Oracle 会把它当小端序解析，存进去的值和你预期的不一致——下次读出来还是错的。
- 必须对
Guid的字节数组做与读取时相反的操作：只反转前8个字节中的指定段 - 更稳妥的做法：先转成标准字节数组，再按 Oracle 要求重排，而非依赖
ToByteArray()输出顺序 - 性能影响极小：16 字节操作，无 GC 压力；但漏掉这步会导致数据写歪，且难以事后排查
public static byte[] ToRaw16Bytes(this Guid guid)
{
var bytes = guid.ToByteArray();
Array.Reverse(bytes, 0, 4); // time_low
Array.Reverse(bytes, 4, 2); // time_mid
Array.Reverse(bytes, 6, 2); // time_hi_and_version
return bytes;
}
ODP.NET 21c+ 是否能自动处理？要看连接字符串和参数设置
新版 ODP.NET（21c 及以后）引入了 GuidMapping 连接属性，但默认仍是 Off，不会自动转换。
- 启用方式：在连接字符串加
GuidMapping=True，或通过OracleConnection.ConnectionStringBuilder设置 - 注意兼容性：开启后，所有
RAW(16)列都会被映射为Guid，但仅限于列类型严格为RAW(16)；RAW无长度或长度≠16 不生效 - 容易踩的坑：混合使用自动映射和手动字节重排——结果会翻转两次，彻底错乱；要么全用自动，要么全手动
- 推荐策略：新项目开
GuidMapping=True，老项目保持手动控制更可控
