dbms_crypto.encrypt返回raw，存varchar2前必须用base64编码，否则解密失败；aes仅支持aes_cbc_pkcs5等有限模式，密钥和iv需显式转raw并匹配长度。
dbms_crypto 加密后存进 varchar2 字段却解密失败？90% 是因为 raw 没做 base64 编码转换，不是算法配错。
DBMS_CRYPTO.ENCRYPT 返回 RAW，不能直接存 VARCHAR2
Oracle 的 DBMS_CRYPTO.ENCRYPT 从不返回字符串，只返回 RAW 类型的二进制数据。如果直接用 UTL_RAW.CAST_TO_VARCHAR2 转成字符串存进 VARCHAR2 字段，会因字符集映射出错导致乱码——解密时 DECRYPT 收到的是损坏的 RAW，必然失败。
正确做法只有一条：加密后立刻用 UTL_ENCODE.BASE64_ENCODE 编码为可安全存储的字符串；解密前必须先用 UTL_ENCODE.BASE64_DECODE 还原为原始 RAW。
- 别用
UTL_RAW.CAST_TO_VARCHAR2或UTL_RAW.CAST_TO_NVARCHAR2—— 它们不处理字符集边界，极易出错 - 十六进制编码（
RAWTOHEX）可用，但体积翻倍（2 字节/原字节），BASE64 更紧凑（约 1.33 倍） - 存储字段类型建议用
VARCHAR2(4000)（BASE64 后长度 ≈ ceil(原长度 × 4/3)）
AES 模式只认 DBMS_CRYPTO.AES_CBC_PKCS5，别试 GCM 或 ECB
Oracle 11g 及以上实际支持的 AES 模式非常有限：DBMS_CRYPTO.AES_CBC_PKCS5 和 DBMS_CRYPTO.AES_CFB_PKCS5 是稳定可用的主力；ECB 被明确禁用（无 IV、易被模式分析），GCM、CCM、AES-256-GCM 等现代认证加密模式在标准版中根本不存在。
填充分歧是跨语言互通的高频雷区：
- Oracle 默认 PKCS5 填充（等价于 PKCS7 对 8 字节块），而 Java/Python 默认用 PKCS7（16 字节块）、Node.js 很多库默认无填充
- 若与外部系统对接，必须统一为
PAD_PKCS5，且明文长度需满足「能被块长整除」——否则 Oracle 会报ORA-28234: key length too short或静默失败 - 不要手动拼接 0x00 填充模拟 NoPadding：Oracle 不识别，且
PAD_ZERO实际行为不稳定，仅限极老版本临时 workaround
密钥和 IV 必须转成 RAW，且字符集要显式指定
传给 DBMS_CRYPTO.ENCRYPT 的 key 和 iv 参数类型必须是 RAW，不能是 VARCHAR2。常见错误是直接写 'mykey123' 当密钥——这会被隐式转成数据库默认字符集的 RAW，一旦应用层或另一环境用 UTF8 解释，就对不上。
务必用 UTL_I18N.STRING_TO_RAW 显式指定字符集：
-
UTL_I18N.STRING_TO_RAW('hj7x89H$yuBI0456', 'AL32UTF8')—— 推荐，兼容性最好 - 密钥长度必须匹配算法：AES128 用 16 字节 RAW，AES192 用 24 字节，AES256 用 32 字节；不足会报
ORA-28234 - IV 长度固定为 16 字节（AES 块长），且每次加密必须用新 IV（建议用
DBMS_CRYPTO.RANDOMBYTES(16)生成）
解密失败时优先检查 BASE64 编解码链是否断裂
绝大多数“解密返回空”或“ORA-28232: invalid input length”错误，根源不在算法或密钥，而在 BASE64 编解码环节断了链：
- 加密后是否漏掉
UTL_ENCODE.BASE64_ENCODE？或用了RAWTOHEX却在解密端误用HEXTORAW+UTL_ENCODE.BASE64_DECODE？ - BASE64 字符串是否被截断？
VARCHAR2字段长度不够、SQL*Plus 默认 80 列显示截断、应用层日志自动换行都会导致末尾的=符号丢失 - 解密前是否确认
UTL_ENCODE.BASE64_DECODE返回的是非空RAW？加一句IF l_enc_raw IS NULL THEN RAISE_APPLICATION_ERROR(-20001, 'Base64 decode failed'); END IF;能快速定位
真正难调的点永远在编码层，而不是密码学层——Oracle 的 DBMS_CRYPTO 行为极其确定，只要 RAW 流完整、算法参数对得上、填充一致，它几乎不会出错。
