可以，但必须用 BEFORE INSERT OR UPDATE 行级触发器 + DBMS_CRYPTO 函数组合，且加密逻辑不能放在 AFTER 触发器里——否则字段值已落盘，改了也白改。
直接说结论：可以，但必须用 BEFORE INSERT OR UPDATE 行级触发器 + DBMS_CRYPTO 函数组合，且加密逻辑不能放在 AFTER 触发器里——否则字段值已落盘，改了也白改。
为什么必须用 BEFORE 触发器
触发器的执行时机决定数据能否被真正“拦截并替换”。AFTER 触发器只能做日志、通知或关联表操作，无法修改 :new. 字段值；只有 BEFORE 触发器允许在 DML 语句真正写入前，对 :new.column_name 赋新值。常见错误是写了 AFTER 还试图 :new.pwd := encrypt(...)，Oracle 会直接报错 ORA-04084: cannot change NEW values for this trigger type。
-
BEFORE INSERT：适合首次插入明文时加密 -
BEFORE UPDATE：适合密码/手机号等字段被修改时重新加密 - 别漏掉
FOR EACH ROW，否则触发器不作用于单行数据
DBMS_CRYPTO 加密函数调用要点
DBMS_CRYPTO 不是黑盒，它对输入类型、密钥长度、填充方式都敏感。最常踩的坑是 RAW 类型转换遗漏或密钥长度不对，导致 ORA-28234: key length too short 或乱码解密失败。
- 密钥必须是 RAW，常用写法：
UTL_I18N.STRING_TO_RAW('your-16-byte-key', 'AL32UTF8')，AES128 要求密钥正好 16 字节（不是字符） - 明文也要转 RAW：
UTL_I18N.STRING_TO_RAW(:new.mobile, 'AL32UTF8')，否则DBMS_CRYPTO.ENCRYPT报ORA-28235: invalid input to obfuscation toolkit - 推荐加密类型组合：
DBMS_CRYPTO.ENCRYPT_AES128 + DBMS_CRYPTO.CHAIN_CBC + DBMS_CRYPTO.PAD_PKCS5，避免用 ECB（不安全） - 加密后结果是 RAW，存进 VARCHAR2 字段前需 base64 编码：
UTL_ENCODE.BASE64_ENCODE(encrypted_raw)，再转UTL_RAW.CAST_TO_VARCHAR2
触发器中调用加密函数的实际结构
不要把加密逻辑全塞进触发器体里——可读性差、难复用、调试困难。正确做法是封装成独立函数，触发器只负责调用。
- 先建加密函数，比如
FUNC_ENCRYPT_AES，参数为V_STR IN VARCHAR2，返回VARCHAR2 - 触发器里只写：
:new.mobile := FUNC_ENCRYPT_AES(:new.mobile); - 函数内统一处理 NULL、空字符串、异常捕获（
EXCEPTION WHEN OTHERS THEN RETURN NULL;） - 注意：函数必须用
DETERMINISTIC标识才能在某些场景下被优化，但加密函数本身非确定性，别加
CREATE OR REPLACE FUNCTION FUNC_ENCRYPT_AES(V_STR IN VARCHAR2) RETURN VARCHAR2 AS
V_KEY_RAW RAW(16) := UTL_I18N.STRING_TO_RAW('1234567890123456', 'AL32UTF8');
V_STR_RAW RAW(2000) := UTL_I18N.STRING_TO_RAW(NVL(V_STR, ''), 'AL32UTF8');
V_ENCRYPTED_RAW RAW(2000);
BEGIN
IF V_STR_RAW IS NULL THEN RETURN NULL; END IF;
V_ENCRYPTED_RAW := DBMS_CRYPTO.ENCRYPT(
src => V_STR_RAW,
typ => DBMS_CRYPTO.ENCRYPT_AES128 + DBMS_CRYPTO.CHAIN_CBC + DBMS_CRYPTO.PAD_PKCS5,
key => V_KEY_RAW
);
RETURN UTL_RAW.CAST_TO_VARCHAR2(UTL_ENCODE.BASE64_ENCODE(V_ENCRYPTED_RAW));
END;
权限与兼容性容易被忽略的点
即使代码写对了，没授对应权限或版本不匹配，照样跑不起来。特别是生产库往往禁用部分包或限制网络访问。
- 用户必须显式授权：
GRANT EXECUTE ON DBMS_CRYPTO TO your_user;，仅CREATE PROCEDURE权限不够 - Oracle 11g 及以上才默认启用
DBMS_CRYPTO；10g 需手动安装组件，且不支持 AES-GCM 等新算法 - 如果字段要支持解密查询（比如后台管理查原始手机号），解密函数也得同样封装，并确保密钥一致——密钥硬编码在函数里等于裸奔，应考虑从加密表或外部配置加载
- 触发器内禁止 COMMIT/ROLLBACK，也不建议调用 UTL_HTTP（网络不稳定会导致 insert 卡死），所以 HTTP 加密方案和 DBMS_CRYPTO 方案必须分开评估
最麻烦的其实是密钥轮换：一旦业务要求定期更换加密密钥，所有存量密文都要重新解密再加密，而触发器本身不参与这个过程——它只管新数据。老数据迁移、密钥管理、加解密一致性验证，这些才是真实落地时卡住进度的地方。
