UTL_RAW包仅在RAW类型上下文中有效，所有函数均要求输入为合法RAW值，非RAW参数会触发ORA-6502错误；CAST_TO_RAW按数据库字符集将字符串转字节序列，CAST_FROM_VARCHAR2则按相同字符集反向解码，二者非简单逆操作，字符集不一致将导致乱码。
UTL_RAW 包不是万能的二进制“转换器”，它只在 RAW 类型上下文中起作用，且所有函数都要求输入是合法 RAW 值——不是字符串、不是 CLOB、更不是数字。直接传入非 RAW 参数会报 ORA-6502。
UTL_RAW.CAST_TO_RAW 和 CAST_FROM_VARCHAR2 的区别在哪
这两个函数常被误认为“互为逆操作”，实际行为完全不同：
-
UTL_RAW.CAST_TO_RAW('abc')按当前数据库字符集（如 AL32UTF8）把每个字符转成对应字节序列，结果是'616263'（ASCII）或'E4B889'（UTF-8 下“三”） -
UTL_RAW.CAST_FROM_VARCHAR2(r)是把 RAW 当作已编码字节流，按相同字符集反向解码；若原始 RAW 来自不同字符集（比如 GBK 存的），这里就会乱码 - 真正安全的往返必须保证：编码源和解码目标字符集一致；否则用
CONVERT()显式转码，而不是依赖 CAST
HEX_TO_RAW 为什么总报 ORA-6502
错误通常不是因为内容非法，而是格式不合规：
- 输入必须是偶数长度的十六进制字符串，
'FF'合法，'F'或'FF1'直接触发VALUE_ERROR - 只允许 0–9、A–F、a–f，含空格、下划线、中文字符都会失败
- 不能带
'0x'前缀，UTL_RAW.HEX_TO_RAW('0xFF')错，得写成UTL_RAW.HEX_TO_RAW('FF') - 最大长度受 RAW 变量限制：PL/SQL 中一般不超过 32767 字节，即 65534 个十六进制字符
BIT_AND / BIT_OR / BIT_XOR 的对齐规则很关键
这些位运算函数不自动截断或填充，而是按 Oracle 定义的“低位补零”规则对齐：
-
BIT_AND('01', 'FF00')→ 先把'01'补成'0100'（低位补00），再与'FF00'运算，结果为'0100' -
BIT_OR('01', 'FF00')同样补零，结果是'FF00' -
BIT_XOR同理，但注意：BIT_XOR('AB', 'CD')≠BIT_XOR('AB00', '00CD')，补零位置影响结果 - 如果想高位对齐（如网络字节序处理），得手动用
UTL_RAW.CONCAT或UTL_RAW.SUBSTR调整长度
CLOB 转 RAW 不能直接用 UTL_RAW.CAST_TO_RAW
UTL_RAW.CAST_TO_RAW 只接受 VARCHAR2，CLOB 超过 32767 字节时会截断或报错。正确做法分两步：
- 小 CLOB（≤ 32767 字符）：先用
DBMS_LOB.SUBSTR(clob, 32767, 1)提取，再传给UTL_RAW.CAST_TO_RAW - 大 CLOB：必须分块处理，每块转
RAW后用UTL_RAW.CONCAT拼接，且要注意字符集边界——UTF-8 下一个汉字占 3 字节，截断在中间会导致后续CAST_FROM_VARCHAR2失败 - 更稳妥的方式是用
DBMS_LOB.CONVERTTOBLOB转成 BLOB，再用UTL_RAW.CAST_TO_RAW不适用，BLOB 需用DBMS_LOB.SUBSTR+UTL_RAW.CAST_TO_RAW分段读
UTL_RAW 函数也不做隐式转码。同一串 RAW 值，用不同字符集解释，结果可能完全不一样——这是最容易被忽略、也最难调试的点。 
