Oracle与Java AES加解密必须严格对齐参数：ECB/CBC模式不可混用，密钥需UTF-8转字节且长度为16/24/32字节，IV须显式生成并统一编码格式，密文HEX大小写需一致，所有字符串操作必须显式指定UTF-8编码。
Oracle端用DBMS_CRYPTO加密，Java端必须严格对齐参数
oracle的dbms_crypto默认不暴露iv、填充方式、密钥派生细节，java解密失败十有八九是参数不一致。最常见的是oracle用了dbms_crypto.encrypt_aes128 + dbms_crypto.chain_ecb + dbms_crypto.pad_pkcs5，而java代码用了aes/cbc/pkcs5padding——ecb和cbc根本不能互通。
实操建议：
- 先在Oracle里查清实际使用的加密类型：
SELECT typ FROM user_source WHERE name = 'FUN_AES' AND text LIKE '%DBMS_CRYPTO.ENCRYPT%'; - 确认是否用了ECB（无IV）还是CBC（需IV），若为CBC，Oracle函数里必须显式生成并拼接IV，否则Java无法还原
- 密钥处理要一致：Oracle用
UTL_I18N.STRING_TO_RAW(key, 'UTF8')转RAW，Java必须用key.getBytes(StandardCharsets.UTF_8)，不能用key.toString().getBytes() - 密文输出格式：Oracle常用
RAWTOHEX()，Java解密前必须先Hex.decodeHex(hexStr.toCharArray())，别直接Base64解码
Java解密时“InvalidKeyException: Invalid AES key length”怎么破
Oracle的DBMS_CRYPTO.ENCRYPT_AES128要求密钥长度恰好16字节（128位），但Java的SecretKeySpec对字符串密钥长度极其敏感——传入"mykey123"（8字节）会直接报错，不是自动补零或截断。
实操建议：
- 密钥必须是16/24/32字节长度，推荐统一用16字节：生成方式为
SecureRandom.getInstanceStrong().nextBytes(new byte[16])，再hex编码存配置 - 如果Oracle侧密钥是字符串（如'oracle123'），Java不能直接用它构造
SecretKeySpec；得先MessageDigest.getInstance("SHA-256").digest(keyStr.getBytes(UTF_8))取前16字节 - 绝对不要用
keyStr.getBytes()后直接newSecretKeySpec——中文字符会导致字节数超标，且不同JVM默认编码可能不一致
模糊查询加密字段：别在SQL里调DBMS_CRYPTO.DECRYPT
想对加密字段做LIKE '%张%'？直接在WHERE里写UTL_I18N.RAW_TO_CHAR(DBMS_CRYPTO.DECRYPT(...), 'UTF8') LIKE '%张%'看似可行，实际会触发全表扫描+逐行解密，性能雪崩，且无法走索引。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 真正可用的方案只有两种：① 应用层解密后内存过滤（适合小结果集）；② 建立带盐的确定性加密列（如AES-SIV）+ 前缀哈希索引，但Oracle原生不支持SIV，需Java预计算
- 如果坚持数据库内解密，至少加函数索引：
CREATE INDEX idx_decrypted_name ON dept (sven_decrypt(testname, 'svensven'));，但仅对等值查询有效 - 注意Oracle 12c+的
DBMS_CRYPTO函数默认不可用于函数索引，需先GRANT EXECUTE ON DBMS_CRYPTO TO your_user并确认用户有CREATE INDEX权限
Java和Oracle AES加密结果不一致的隐藏坑
即使算法、模式、密钥、IV都一样，Java和Oracle加密结果仍可能不同，核心在于原始数据的字节表示是否一致。Oracle用UTL_I18N.STRING_TO_RAW(str, 'UTF8')，而Java若用str.getBytes()没指定Charset，会依赖系统默认编码（如Windows是GBK）。
实操建议：
- Java端所有字符串转字节操作必须显式指定
StandardCharsets.UTF_8，包括密钥、明文、IV - Oracle加密后密文是大写HEX（如
'A1B2C3...'），Java解密前若用Hex.decodeHex()，输入必须全小写或全大写，混合大小写会抛DecoderException - Oracle的
PAD_PKCS5实际行为等同于PKCS#7，Java用PKCS5Padding或PKCS7Padding均可，但JDK 8+默认只认PKCS5Padding - 测试时务必用固定字节序列验证：比如明文
"hello"（5字节UTF-8），在两边分别打印raw_input和input.getBytes(UTF_8)的十六进制，必须完全一致
UTL_I18N.STRING_TO_RAW和String.getBytes()的理解偏差，往往要花半天才能定位。 
