DBMS_CRYPTO.ENCRYPT返回RAW类型，解密失败主因是未正确编码转换；必须用UTL_ENCODE.BASE64_ENCODE转为字符串存储，解密前用BASE64_DECODE还原，且密钥、IV需为RAW并统一字符集。
DBMS_CRYPTO.ENCRYPT 返回 RAW 为什么解密失败
根本原因：加密输出是 raw，但很多人直接当字符串用，没做正确编码转换。oracle 的 dbms_crypto.encrypt 从不返回字符串，只返回二进制 raw；若存入 varchar2 字段或传给应用层，必须先转成 base64 或十六进制（utl_raw.cast_to_varchar2 会乱码，别用）。
- 常见错误现象：
ORA-28834: buffer too small或解密后得到乱码/空值，本质是 RAW 被隐式转换截断或损坏 - 正确做法：加密后立刻用
UTL_ENCODE.BASE64_ENCODE编码为可存储字符串；解密前先用UTL_ENCODE.BASE64_DECODE还原为 RAW - 注意密钥和 IV 也必须是
RAW类型，不能传字符串字面量——要用UTL_I18N.STRING_TO_RAW('key', 'AL32UTF8')
AES 加密时选择什么 cipher_type 参数
DBMS_CRYPTO 的 AES 支持有限，不是所有 AES 变种都可用。Oracle 11g+ 实际只支持 DBMS_CRYPTO.AES_CBC_PKCS5 和 DBMS_CRYPTO.AES_CFB_PKCS5 等带 PKCS5 填充的 CBC/CFB 模式，不支持 GCM、ECB（禁用）、AES-256-GCM 等现代常用模式。
- 推荐用
DBMS_CRYPTO.AES_CBC_PKCS5：兼容性最好，Java/.NET 都能对齐（需统一 IV 和填充） - 别用
DBMS_CRYPTO.AES_ENCRYPT——这不是函数名，是常量别名，实际要传完整 cipher_type 常量 - 密钥长度必须严格匹配：128 位密钥 →
RAW(16)，192 →RAW(24)，256 →RAW(32)；传错长度会报ORA-28234: key length too short
IV 怎么生成和复用才安全
IV 不是密码，但必须随机且每次加密唯一。硬编码 IV（比如全零）等于放弃 CBC 安全性；重复使用同一 IV + 同一密钥会导致密文可被差分分析。
- 生成方式：用
DBMS_CRYPTO.RANDOMBYTES(16)（AES-128-CBC 要 16 字节 IV） - 存储方式：IV 无需保密，但必须和密文一起保存（如拼在密文前，或单独字段），解密时原样传入
DBMS_CRYPTO.DECRYPT - 常见坑：把 IV 当作盐值反复用、用
SYS_GUID()（不是密码学安全随机数）、或漏传 IV 导致解密报ORA-28233: invalid input to encrypt/decrypt
Java 或 Python 解密 Oracle 加密的数据总失败
跨语言解密失败，90% 出在三处：编码不一致、填充不一致、IV 处理错。Oracle 默认用 PKCS5 填充（等价于 PKCS7 对 8 字节块），而很多语言库默认用 PKCS7 或无填充。
- 确认 Java 侧用
Cipher.getInstance("AES/CBC/PKCS5Padding")，不是PKCS7Padding（部分 JDK 版本不认） - Python 的
cryptography库需显式加padding.PKCS7(128).padder()，且 IV 必须是 bytes 类型，不能是 hex 字符串 - Base64 编码两端必须一致：Oracle 用
UTL_ENCODE.BASE64_ENCODE，对方必须用标准 Base64 解码（注意换行符、末尾 = 符号）
最易被忽略的是字符集：Oracle 默认用数据库字符集处理原始字符串，若数据库是 AL32UTF8，而应用传入 GBK 字符串再加密，解密后必然乱码——加密前务必统一用 UTL_I18N.STRING_TO_RAW(str, 'AL32UTF8')。
