dbms_crypto是oracle服务端pl/sql包，不支持sql直接调用或odp.net直连，必须通过匿名块封装并确保用户有execute权限；其加密/解密需严格匹配算法、密钥长度、字符集及base64编解码流程。
oracle 的 dbms_crypto 是服务端加密包，c# 无法直接调用它——你得通过 pl/sql 匿名块或存储过程间接使用，且必须确保 oracle 用户有执行权限和对应加密算法支持。
为什么不能像调用普通函数一样在 C# 里直接用 DBMS_CRYPTO？
DBMS_CRYPTO 是 Oracle 内置的 PL/SQL 包，只在数据库服务端运行，没有对外暴露 JDBC/ODP.NET 可直接绑定的 SQL 函数接口。试图用 SELECT DBMS_CRYPTO.ENCRYPT(...) 直接查会报 ORA-00904: invalid identifier，因为该包不支持在 SQL 表达式中直接调用（仅限 PL/SQL 上下文）。
- 必须用
EXECUTE IMMEDIATE或匿名 PL/SQL 块封装调用 - ODP.NET 不支持将
DBMS_CRYPTO当作标量函数注册为 .NET 方法 - 即使使用
OracleCommand.CommandType = CommandType.StoredProcedure，也必须先创建包装存储过程，不能直连包过程
如何用 ODP.NET 正确调用 DBMS_CRYPTO.ENCRYPT / DECRYPT？
核心是写一个带 OUT 参数的匿名 PL/SQL 块，把加密结果以 RAW 或 BASE64 字符串形式返回。注意：DBMS_CRYPTO 默认返回 RAW，而 .NET 的 OracleDbType.Raw 易出错，建议转成 VARCHAR2 再读取。
DECLARE
l_encrypted_raw RAW(2000);
BEGIN
l_encrypted_raw := DBMS_CRYPTO.ENCRYPT(
src => UTL_I18N.STRING_TO_RAW(:p_plain, 'AL32UTF8'),
typ => DBMS_CRYPTO.DES_CBC_PKCS5,
key => UTL_I18N.STRING_TO_RAW(:p_key, 'AL32UTF8')
);
:p_result := UTL_RAW.CAST_TO_VARCHAR2(UTL_ENCODE.BASE64_ENCODE(l_encrypted_raw));
END;
- 参数
:p_plain和:p_key需用OracleDbType.Varchar2传入（不是Raw） - 输出
:p_result必须声明为OracleDbType.Varchar2，长度至少 4000（BASE64 后膨胀约 33%） - 加密类型如
DBMS_CRYPTO.DES_CBC_PKCS5要匹配密钥长度（DES 要求 8 字节），否则抛ORA-28232 - 别忘了给用户授予权限：
GRANT EXECUTE ON DBMS_CRYPTO TO your_user;
解密时常见 ORA-29275（partial multibyte character）怎么破？
这是最常踩的坑：解密前没把 BASE64 字符串还原成 RAW，或字符集不一致导致 UTL_I18N.STRING_TO_RAW 解码失败。错误堆栈里出现 ORA-29275，基本就是编码链断了。
- 解密块里必须用
UTL_ENCODE.BASE64_DECODE(UTL_I18N.STRING_TO_RAW(:p_encoded, 'AL32UTF8'))还原 RAW - 不能直接对 BASE64 字符串调用
DBMS_CRYPTO.DECRYPT—— 它只吃 RAW - 如果原始明文含中文，加密前用
AL32UTF8编码，解密后用UTL_I18N.RAW_TO_CHAR(..., 'AL32UTF8')转回字符串 - 测试时先在 SQL*Plus 里跑通 PL/SQL 块，再挪到 C#，避免把问题归咎于 ODP.NET
真正麻烦的不是语法，而是密钥管理、填充模式对齐、字符集转换这三步——任意一步错，加密结果就不可逆，而且 Oracle 不报具体哪错，只甩个模糊的 ORA 错误码。
