oracle的utl_encode.base64_encode/decode仅支持raw类型，必须经utl_raw.cast_to_raw转字符串为字节、utl_raw.cast_to_varchar2转回，否则报ora-06553或乱码；编码结果含crlf需手动清除；中文乱码源于字符集不匹配，应显式用utl_i18n或convert确保一致；大对象须分块处理。
oracle 的 utl_encode.base64_encode 和 utl_encode.base64_decode 不能直接处理字符串，跳过类型转换会报 ora-06553 或返回乱码——这是绝大多数人踩坑的起点。
为什么 UTL_ENCODE.BASE64_ENCODE('abc') 一定报错
因为函数签名明确要求输入是 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转回可读字符串
编码结果里怎么冒出 CHR(13)||CHR(10) 换行？
UTL_ENCODE.BASE64_ENCODE 在输入原始字节数 ≥ 48 时，会自动每 64 个 Base64 字符插入一次 CRLF（CHR(13)||CHR(10)），这是 MIME 兼容行为，无法通过 NLS_LANG 或 ALTER SESSION 关闭。
解决方式只有应用层清理：
- 简单文本：用
REPLACE(encoded_str, CHR(13) || CHR(10), '') - 写封装函数时，在
UTL_RAW.CAST_TO_VARCHAR2后立即TRIM或TRANSLATE掉控制字符 - 别试图“绕过”——该行为由函数内部硬编码决定，无配置项
中文/emoji 解码后变乱码，不是 Base64 的问题
根本原因是字符集不匹配。例如原始字符串是 UTF-8 编码，但数据库字符集是 ZHS16GBK，UTL_RAW.CAST_TO_VARCHAR2 会按 ZHS16GBK 解释字节流，必然错乱。
安全做法是显式控制字符集转换：
- 编码前：用
UTL_I18N.STRING_TO_RAW(p_str, 'AL32UTF8')替代UTL_RAW.CAST_TO_RAW - 解码后：用
UTL_I18N.RAW_TO_CHAR(decoded_raw, 'AL32UTF8')替代UTL_RAW.CAST_TO_VARCHAR2 - 或用
CONVERT补救：比如数据库是ZHS16GBK，但数据源是 UTF-8，则CONVERT(utl_raw.cast_to_varchar2(...), 'ZHS16GBK', 'AL32UTF8')
处理大文本（CLOB）或二进制（BLOB）时必须分块
VARCHAR2 最大 32767 字节，Base64 编码后体积膨胀约 33%，超长内容直接传入会触发 ORA-06502。
分块逻辑要点：
- 每次取 ≤ 12000 字节原始内容（留出 Base64 膨胀余量）
- 对每块分别执行
CAST_TO_RAW → BASE64_ENCODE → CAST_TO_VARCHAR2 - 用
DBMS_LOB.APPEND拼接结果到临时CLOB - 对
BLOB，先用DBMS_LOB.READ分段读为RAW，再编码；解码则反向操作
ROWID 的 Base64 字符串（如 AABRFrAAEAADnz2AAB）是特例：它本质是 Oracle 内部二进制结构的紧凑编码，不能当普通字符串处理——要解析物理位置，得先 UTL_ENCODE.BASE64_DECODE(UTL_RAW.CAST_TO_RAW(ROWID))，再按官方定义的偏移拆解字段。
