dbms_crypto.encrypt返回raw，必须用utl_encode.base64_encode转为字符串存储，解密前用base64_decode还原为raw；密钥和iv需为raw类型且长度严格匹配，字符集统一为al32utf8。
DBMS_CRYPTO.ENCRYPT 返回 RAW，直接存 VARCHAR2 或传给应用层必然出错——必须做 BASE64 编码转换，否则解密永远失败。
加密后为什么解密得到乱码或 ORA-28834？
根本原因不是算法配错，而是把 DBMS_CRYPTO.ENCRYPT 返回的 RAW 当字符串用了。Oracle 从不返回可读字符串，只返回二进制字节流；若直接插入 VARCHAR2 字段、用 UTL_RAW.CAST_TO_VARCHAR2 转换，或在 PL/SQL 中隐式拼接，都会因字符集转换导致截断或乱码。
常见错误现象：
-
ORA-28834: buffer too small—— 实际是 RAW 被截断后长度不符 - 解密后得到空值、问号、或不可见控制字符
- 同一明文每次加密结果不同，但解密仍失败（说明 IV 生成正常，但编码环节已损坏）
正确做法：
- 加密后立刻调用
UTL_ENCODE.BASE64_ENCODE，得到可安全存储的字符串 - 解密前先用
UTL_ENCODE.BASE64_DECODE还原为原始RAW - 绝对不要用
UTL_RAW.CAST_TO_VARCHAR2或RAWTOHEX（除非你明确需要 hex 字符串且下游能对齐）
cipher_type 怎么组合才真正可用？
Oracle 的 AES 支持有硬限制：11g+ 只认带 PKCS5 填充的 CBC 或 CFB 模式，DBMS_CRYPTO.AES_ENCRYPT 是常量别名，不能直接当参数传。
必须手动拼接，例如：
- AES-128-CBC-PKCS5：
DBMS_CRYPTO.ENCRYPT_AES128 + DBMS_CRYPTO.CHAIN_CBC + DBMS_CRYPTO.PAD_PKCS5 - AES-256-CBC-PKCS5：
DBMS_CRYPTO.ENCRYPT_AES256 + DBMS_CRYPTO.CHAIN_CBC + DBMS_CRYPTO.PAD_PKCS5
禁用组合：
-
DBMS_CRYPTO.ENCRYPT_AES256 + DBMS_CRYPTO.CHAIN_ECB（ECB 不安全，Oracle 会报错） -
DBMS_CRYPTO.AES_GCM（不存在，Oracle 不支持 GCM） -
DBMS_CRYPTO.PAD_PKCS7（Oracle 只认PAD_PKCS5，虽等价但名字不对就报 ORA-28233）
密钥和 IV 必须是 RAW，且长度严格匹配
密钥不是字符串，IV 不是盐值——它们都是密码学意义的二进制块，类型和长度错一点就解密失败。
密钥处理要点：
- 用
UTL_I18N.STRING_TO_RAW('your-key', 'AL32UTF8')转换，不能直接写'your-key' - AES-128 → 密钥必须是
RAW(16)，AES-256 → 必须是RAW(32)；传RAW(31)会报ORA-28234: key length too short - 别从表里查
VARCHAR2字段再转，应始终用RAW类型字段存密钥（如KEYCODE RAW(32)）
IV 处理要点：
- 每次加密必须调用
DBMS_CRYPTO.RANDOMBYTES(16)生成新 IV（AES-CBC 固定 16 字节） - IV 可明文存储，但必须和密文一起保存（如拼在 BASE64 字符串前，或单独字段）
- 解密时必须原样传入，漏传或传错类型（比如传了
VARCHAR2）会触发ORA-28233
跨语言解密总失败？先盯死这三处
Java、Python 解密 Oracle 加密数据失败，90% 卡在这三个点上：
-
编码不一致：Oracle 用
BASE64_ENCODE，Java 就不能用Hex.encodeHexString()；Python 用base64.b64encode()，不能用binascii.hexlify() -
填充不一致：Oracle 默认
PAD_PKCS5（等价于 PKCS7 对 8 字节块），Java 需显式指定"PKCS5Padding"，Python 的cryptography库要配padding.PKCS7(128) -
IV 处理错：Oracle 的 IV 是 raw 字节，Java 里必须用
new IvParameterSpec(ivBytes)构造，不能用字符串构造；Python 要确保 IV 是 bytes 类型且长度为 16
最易被忽略的是：Oracle 加密前对明文做了 UTL_I18N.STRING_TO_RAW(..., 'AL32UTF8')，所有下游语言也必须用 UTF-8 编码明文——用 GBK 或 Latin-1 就必然解密失败。
