dbms_crypto不能直接在存储过程中“开箱即用”，必须显式处理raw转换、密钥长度、iv生成和base64编解码，漏掉任一环节加密数据即损坏；encrypt参数全需严格匹配类型与值，src须为raw、typ为组合常量、key长度须精确、iv在cbc模式下必随机生成且保存复用；加密后须base64编码存varchar2，解密前须base64解码还原raw，跨语言需统一pad_pkcs5填充，密钥与iv严禁硬编码，权限需显式授予。
dbms_crypto不能直接在存储过程中“开箱即用”，必须显式处理raw转换、密钥长度、iv生成和base64编解码——漏掉任一环节，加密数据存进表里就已损坏，后续解密必然失败。
DBMS_CRYPTO.ENCRYPT参数必须全传且类型严格匹配
常见错误是只传 src 和 key，结果报 ORA-28239: no encryption key specified 或 ORA-28233: invalid input to encrypt/decrypt。根本原因是：typ 和 iv 不是可选占位符，而是强制参数（即使 ECB 模式下 iv 可为 NULL，但 ECB 已不安全，不推荐）。
-
src必须是RAW，不能直接传VARCHAR2；用UTL_I18N.STRING_TO_RAW(p_input, 'AL32UTF8')显式转，避免隐式转换导致中文乱码 -
typ是算法+模式+填充的组合常量，例如DBMS_CRYPTO.ENCRYPT_AES256 + DBMS_CRYPTO.CHAIN_CBC + DBMS_CRYPTO.PAD_PKCS5；写成DBMS_CRYPTO.AES_CBC_PKCS5会报错——这不是 Oracle 的合法常量名 -
key长度必须严格匹配：AES-128 要RAW(16)，AES-256 要RAW(32)；用字符串生成时，UTL_I18N.STRING_TO_RAW('mykey', 'AL32UTF8')的字节数必须等于要求，否则触发ORA-28234: key length too short -
iv在 CBC 模式下必填且必须随机；生成方式必须是DBMS_CRYPTO.RANDOMBYTES(16)（AES-128-CBC）或DBMS_CRYPTO.RANDOMBYTES(32)（AES-256-CBC），硬编码（如全零或固定字符串）会让相同明文产生相同密文，彻底破坏 CBC 安全性
加密后必须用UTL_ENCODE.BASE64_ENCODE再存VARCHAR2
DBMS_CRYPTO.ENCRYPT 返回的是 RAW，不是字符串。直接用 UTL_RAW.CAST_TO_VARCHAR2 或隐式转成 VARCHAR2 字段，Oracle 会按数据库字符集映射二进制字节，遇到非 ASCII 字节就替换为 ? 或截断——解密时拿到的是损坏的 RAW，必然失败。
- 正确做法：加密后立刻调用
UTL_ENCODE.BASE64_ENCODE，得到可安全存储的 ASCII 字符串，再存入VARCHAR2字段 - 别用
RAWTOHEX()：虽然能存，但体积翻倍（2 字节表示 1 字节原始数据），且 Java/.NET 端默认不按 HEX 解析 - 别用
UTL_RAW.CAST_TO_VARCHAR2()：它依赖数据库字符集，对二进制数据无意义，极易出错 - 存储字段建议定义为
VARCHAR2(4000)：BASE64 后长度 ≈ceil(原长度 × 4/3)，4000 足够覆盖多数场景
解密前必须先UTL_ENCODE.BASE64_DECODE还原为RAW
从 VARCHAR2 字段读出的 BASE64 字符串，必须先用 UTL_ENCODE.BASE64_DECODE 还原为原始 RAW，才能传给 DBMS_CRYPTO.DECRYPT。否则会因类型不匹配或内容损坏直接报错或返回空值。
- 解密时
key和iv必须与加密时完全一致：同一密钥、同一 IV（CBC 模式下 IV 必须复用，不能重生成） - 解密返回的仍是
RAW，需用UTL_I18N.RAW_TO_CHAR(..., 'AL32UTF8')转回可读字符串；字符集必须与加密时STRING_TO_RAW使用的一致 - 跨语言对接时，填充分歧是高频雷区：Oracle 默认
PAD_PKCS5（等价于 PKCS7 对 8 字节块），而 Java/Python 默认用 PKCS7（16 字节块），务必统一为PAD_PKCS5，且明文长度需满足「能被块长整除」，否则可能静默失败
存储过程里别硬编码密钥和IV
把密钥和 IV 写死在 PL/SQL 代码里（比如 p_key VARCHAR2(32) := 'hj7x89H$yuBI0456'），会导致密钥泄露风险高、无法轮换、审计困难。生产环境应通过安全方式注入。
- 推荐方案：将密钥存在独立加密表（用 TDE 加密的表）或外部密钥管理服务（如 HashiCorp Vault），运行时动态查取并立即转
RAW - 若必须本地存，至少用
DBMS_OBFUSCATION_TOOLKIT（已弃用但兼容）或自定义加盐哈希逻辑混淆，而非明文字符串 - IV 不可复用，每次加密都必须调用
DBMS_CRYPTO.RANDOMBYTES新生成；但解密时必须用加密时保存的那个 IV，所以需连同密文一起存入字段（如拼接成BASE64(iv)||':'||BASE64(ciphertext)） - 权限检查不可少：执行前确认用户有
EXECUTE ON SYS.DBMS_CRYPTO，否则过程编译通过但运行时报PLS-00201: identifier 'DBMS_CRYPTO.ENCRYPT' must be declared
最易被忽略的点是：加密输出是二进制 RAW，而数据库字段是字符型 VARCHAR2——这中间没有自动适配层，所有转换都得你亲手写清楚，一步错，全链路崩。
