Oracle端必须使用DBMS_CRYPTO.HASH而非已弃用的DBMS_OBFUSCATION_TOOLKIT.MD5，因其支持UTF-8、正确处理NULL、输出固定16字节RAW并可通过RAWTOHEX转为32位小写十六进制字符串，与Java的MessageDigest.getInstance("MD5")行为一致。
Oracle端必须用 DBMS_CRYPTO.HASH，不是 DBMS_OBFUSCATION_TOOLKIT.MD5
oracle 10g 之后官方明确弃用 dbms_obfuscation_toolkit，它不支持 utf-8 字符、无法处理 null 输入、且返回 raw 类型时长度不固定（有时带前导零有时不），直接导致 java 端校验失败。真实场景中，你看到的“md5 值对不上”，八成是两边用了不同包。
正确做法是统一走 DBMS_CRYPTO.HASH，它接受 RAW 或 VARCHAR2 输入，输出严格 16 字节 RAW，再用 RAWTOHEX 转成 32 位小写十六进制字符串——这和 Java 的 MessageDigest.getInstance("MD5") 默认行为一致。
-
DBMS_CRYPTO.HASH第二个参数必须是DBMS_CRYPTO.HASH_MD5（值为 1），别手误写成 2（SHA1） - 输入字符串建议显式转
UTL_I18N.STRING_TO_RAW(str, 'AL32UTF8')，避免数据库字符集（如 ZHS16GBK）导致乱码哈希 - 如果 Java 传的是中文用户名，而 Oracle 端没做 RAW 转换，哈希结果必然错
JDBC 中调用要避开 CallableStatement 的 OUT 参数陷阱
很多人写 { ? = call DBMS_CRYPTO.HASH(...) }，然后用 registerOutParameter(1, Types.VARBINARY) 拿结果，但会抛 ORA-06553: PLS-306: wrong number or types of arguments——因为 DBMS_CRYPTO.HASH 是函数，不是过程，不能当过程调用；而且它返回 RAW，JDBC 对 Types.VARBINARY 映射不稳定，尤其在 Oracle 19c+ 驱动里容易截断。
安全做法是把它塞进 SQL 查询里，走 PreparedStatement：
SELECT RAWTOHEX(DBMS_CRYPTO.HASH(UTL_I18N.STRING_TO_RAW(?, 'AL32UTF8'), 1)) FROM DUAL
- 参数用
setString(1, "password123")即可，不用碰 RAW 类型 - 结果用
rs.getString(1)直接拿到 32 位小写 hex 字符串，和 Java 自己算的md5Hex完全可比 - 别用
setBytes传原始字节数组——Oracle 会按数据库字符集再解释一遍，等同于二次编码
Java 端 MD5 计算必须和 Oracle 保持字节级一致
看似简单，但最容易翻车：Java 默认用平台默认编码（Windows 是 GBK，Linux 是 UTF-8），而 Oracle 函数内部始终按 AL32UTF8 解释字符串。如果你在 Java 里直接 md5.digest("张三".getBytes())，字节数组来源取决于当前系统，和 Oracle 不一致。
立即学习“Java免费学习笔记（深入）”；
- Java 必须显式指定编码：
"张三".getBytes(StandardCharsets.UTF_8) - 不要用
DigestUtils.md5Hex(String)（它隐式用平台编码），改用DigestUtils.md5Hex(byte[])+ 显式 UTF-8 字节数组 - 如果 Oracle 端用了
STRING_TO_RAW(str, 'ZHS16GBK')，那 Java 也得用GBK编码——但强烈不建议，统一 UTF-8 是唯一可持续方案 - 空字符串、null 值在两端行为要对齐：Oracle
DBMS_CRYPTO.HASH(NULL, 1)返回 NULL；Java 里得判断str == null并跳过 digest
鉴权时别在 SQL 里拼接明文密码做比较
常见错误是写 WHERE password_hash = (SELECT RAWTOHEX(...)) 把密码哈希逻辑放在 WHERE 子句里。这会导致每次查询都执行一次哈希，无法利用索引，还暴露哈希逻辑到 SQL 层，审计难、调试难。
正确姿势是：Java 先算好哈希值，作为参数传入预编译语句：
SELECT COUNT(1) FROM users WHERE username = ? AND password_hash = ?
- 第二个 ? 填的是 Java 算出的 32 位小写 hex 字符串，比如
"a94a8fe5ccb19ba61c4c0873d391e987" - 确保
password_hash字段是VARCHAR2(32)或CHAR(32)，且建了索引 - 如果业务允许，优先用 Oracle Wallet 或透明数据加密（TDE）保护该字段，而不是依赖应用层哈希
真正麻烦的从来不是调用那个函数，而是两端对“字符串→字节→哈希”这个链条的理解是否完全同步。少一个 UTF-8 强制，或多一次隐式编码，结果就差一位——而你得花半天才意识到问题不在 JDBC 驱动版本上。
