DBMS_CRYPTO仅加密运行时数据（如密码、身份证号），不能加密存储过程源码；加密VARCHAR2需先用UTL_I18N.STRING_TO_RAW转RAW并统一字符集AL32UTF8；推荐AES256+CBC+PKCS5，密钥32字节、IV每次随机生成且须与密文一同存储。
DBMS_CRYPTO 不能直接加密“存储过程本身”，它只处理数据——RAW、BLOB、CLOB。所谓“对存储过程敏感数据加密”，实际是指：在存储过程中操作敏感字段（如密码、身份证号）时，用 DBMS_CRYPTO 对这些字段值做加解密。关键不是加密代码，而是加密运行时的数据。
为什么不能直接加密存储过程体？
Oracle 存储过程源码以 TEXT 形式存于 ALL_SOURCE，本身不支持内置加密；DBMS_CRYPTO 的 ENCRYPT/DECRYPT 函数输入必须是 RAW 或 LOB 类型，而 PL/SQL 源码文本无法直接喂给它——你传进去的是字符串，不是待保护的业务数据。
- 试图对
CREATE OR REPLACE PROCEDURE ...文本调用ENCRYPT是无效操作，结果只是把一段 SQL 语法变成乱码 RAW，毫无安全价值 - 真正要保护的是运行时被该存储过程读写的数据，比如
INSERT INTO users (password) VALUES (?)中的? - 混淆“加密代码”和“加密数据”是初学者最常掉进的坑
加密 VARCHAR2 字段前必须转 RAW，且字符集要一致
Oracle 不允许直接加密 VARCHAR2。必须先用 UTL_I18N.STRING_TO_RAW 转成 RAW，否则报 ORA-06502: PL/SQL: numeric or value error。字符集不匹配会导致解密后乱码或 ORA-29275（partial multibyte character）。
在 Next.js + Supabase 应用中集成自托管加密支付结账，支持 ETH、BTC、SOL、USDC、USDT 及 9 条链的25+ 币种，无需支付处理机构。
- 统一用
'AL32UTF8'：这是 Oracle 19c 默认数据库字符集，也是最稳妥选择 - 别用
UTL_RAW.CAST_TO_RAW替代——它按字节拷贝，不处理多字节字符，中文会截断 - 示例正确写法：
UTL_I18N.STRING_TO_RAW('张三', 'AL32UTF8') - 解密后还原也必须用
UTL_I18N.RAW_TO_CHAR(..., 'AL32UTF8')，不能漏参数
AES256 + CBC + PKCS5 是生产推荐组合
Oracle 19c 中，DBMS_CRYPTO.ENCRYPT_AES256 + DBMS_CRYPTO.CHAIN_CBC + DBMS_CRYPTO.PAD_PKCS5 是兼顾安全性与兼容性的首选。ECB 模式不推荐（明文相同则密文相同），AES128 虽快但密钥强度弱于 AES256。
- 密钥长度必须为 32 字节：
DBMS_CRYPTO.RANDOMBYTES(32)最安全；硬编码密钥至少用UTL_I18N.STRING_TO_RAW('32-char-key-here...', 'AL32UTF8')确保长度 -
IV必须每次加密都随机生成（哪怕你用固定 IV，也要显式传入，不能留 NULL）；CBC 模式下 IV 为 16 字节，可用DBMS_CRYPTO.RANDOMBYTES(16) - 加密后结果仍是
RAW，若需存入VARCHAR2字段，必须 Base64 编码：UTL_ENCODE.BASE64_ENCODE(encrypted_raw)，否则二进制零字节会被截断 - 解密时顺序不能错：Base64 解码 →
UTL_ENCODE.BASE64_DECODE→DBMS_CRYPTO.DECRYPT→UTL_I18N.RAW_TO_CHAR
权限和异常处理不能省略
非 SYS 用户默认无权调用 DBMS_CRYPTO，且加解密过程极易因参数错、字符集错、密钥错抛出 ORA 错误——这些错误若未捕获，会导致存储过程意外终止，业务中断。
- 授权命令必须由 DBA 执行：
GRANT EXECUTE ON SYS.DBMS_CRYPTO TO your_user; - 必须捕获常见错误：
ORA-28239（密钥为空）、ORA-28232（密钥长度不足）、ORA-29275（字符集/编码链断裂） - 不要把密钥硬写在存储过程中；应从加密表（如用
DBMS_CRYPTO.RANDOMBYTES生成并加密存储）或外部密钥管理服务获取 - 如果字段可能为空，加密前加
NVL判断，否则STRING_TO_RAW(NULL)返回 NULL，ENCRYPT(NULL, ...)返回 NULL，后续解密会失败
最易被忽略的一点：IV 必须和密文一起持久化。很多人只存密文，下次解密时用新生成的 IV，结果必然失败。IV 不需要保密，但必须可重现——通常和密文拼接存储，或单独字段保存。
