UTL_ENCODE.BASE64_ENCODE和BASE64_DECODE仅接受RAW类型输入输出，必须通过UTL_RAW.CAST_TO_RAW转字符串为字节、UTL_RAW.CAST_TO_VARCHAR2转回字符串；直接传VARCHAR2报ORA-06553；编码结果含CRLF换行需手动清除；中文乱码源于字符集不匹配，应显式用CONVERT确保编码一致；大对象须分块处理。
UTL_ENCODE.BASE64_ENCODE 和 UTL_ENCODE.BASE64_DECODE 本身不直接处理字符串，必须配合 UTL_RAW.CAST_TO_RAW 和 UTL_RAW.CAST_TO_VARCHAR2 才能用于 VARCHAR2 类型的文本。这是最常被忽略的前提，跳过这一步会报错或返回乱码。
为什么直接用 UTL_ENCODE.BASE64_ENCODE('abc') 会报错
因为 utl_encode.base64_encode 只接受 raw 类型输入，而字符串字面量（如 'abc'）是 varchar2。oracle 不会自动隐式转换。错误现象通常是：ora-06553: pls-306: wrong number or types of arguments。
正确链路是：VARCHAR2 → RAW → Base64-encoded RAW → VARCHAR2。
-
UTL_RAW.CAST_TO_RAW('abc')把字符串按数据库字符集（如 AL32UTF8）转成原始字节 -
UTL_ENCODE.BASE64_ENCODE(...)对这些字节做 Base64 编码，输出仍是RAW -
UTL_RAW.CAST_TO_VARCHAR2(...)把编码后的RAW转回可读字符串
编码结果里莫名其妙多了换行符？
这是 UTL_ENCODE.BASE64_ENCODE 的默认行为：当输入原始字节数 ≥ 48 字节时，它会在每 64 个 Base64 字符后插入 CHR(13) || CHR(10)（即 CRLF）。这不是 bug，是 MIME 兼容设计，但多数业务场景不需要它。
解决方法只有在应用层手动清理：
- 用
REPLACE(..., CHR(13) || CHR(10), '')去掉换行 - 或改用 PL/SQL 封装函数，在调用后立即 strip 掉控制字符
- 注意：不能靠改
NLS_LANG或ALTER SESSION规避，该行为由函数内部硬编码决定
中文、emoji 或多字节字符解码后变成乱码？
根本原因不是 Base64，而是字符集转换环节出错。例如 UTL_RAW.CAST_TO_VARCHAR2 会按当前数据库字符集解释字节流；如果原始字符串是 UTF-8 编码，但数据库字符集是 ZHS16GBK，解码后必然错乱。
安全做法：
- 确认源数据实际编码（推荐统一用 AL32UTF8）
- 避免依赖
CAST_TO_VARCHAR2，对敏感内容改用CONVERT显式指定目标字符集：CONVERT(UTL_RAW.CAST_TO_VARCHAR2(...), 'AL32UTF8', 'AL32UTF8') - 若原始数据来自外部系统（如 Java 的
Base64.getEncoder().encodeToString(bytes)），确保双方都以相同字节序列处理 —— 即先UTL_RAW.CAST_TO_RAW，再编码，而非对已编码字符串二次 cast
大对象（CLOB/BLOB）怎么处理？
UTL_ENCODE 函数只支持 RAW 和 OID，不支持直接传 CLOB。强行 CAST(clob AS RAW) 会失败或截断。
必须分块处理：
- 用
DBMS_LOB.SUBSTR每次取最多 32767 字节（RAW最大长度） - 对每块调用
UTL_ENCODE.BASE64_ENCODE(UTL_RAW.CAST_TO_RAW(...)) - 用
DBMS_LOB.APPEND拼接结果，或用||连接字符串 - 注意：分块边界不能切在 UTF-8 多字节字符中间，否则
CAST_TO_RAW可能报ORA-06502；稳妥起见，对 CLOB 先CONVERT成单字节字符集再处理
Base64 在 Oracle 里从来不是“开箱即用”的字符串工具，它本质是面向二进制数据的底层编解码器。所有看似简单的 to_base64('hello') 调用背后，都藏着字符集、字节边界、换行策略三个容易静默失效的环节。
