UTL_SMTP发带附件邮件需手动处理MIME封装、Base64编码、边界分隔符及中文编码（RFC 5987格式），网络连通性、权限配置与客户端兼容性是常见故障点。
直接用 UTL_SMTP 发带附件的邮件，不是“加个参数”就能搞定的事——它不提供现成的附件封装逻辑，所有 MIME 头、边界分隔符、Base64 编码、文件读取和拼接都得你手动写。错一个换行、少一个空行、编码没对齐，收件人就看到乱码附件名或空白邮件。
ORA-29260 连不上 SMTP 服务器？先别动 PL/SQL 代码
这是最常卡住的第一步。错误里写的“网络错误”，和你的密码、用户名、SQL 写法完全无关。
- 在数据库服务器上直接跑：
telnet smtp.example.com 587（或openssl s_client -connect smtp.example.com:465 -crlf），看是否能连通 - 连不通？找运维确认三件事：出向防火墙策略是否放行该端口、SELinux 是否限制
oracle用户发起网络连接、是否需配置 HTTP/SOCKS 代理（UTL_SMTP不支持代理，得改架构） -
UTL_SMTP.OPEN_CONNECTION的第二个参数必须匹配实际端口：25（明文，基本被拒）、465（SSL）、587（STARTTLS），硬写 25 是常见坑
附件名中文显示为问号或乱码？MIME filename\*=UTF-8'' 是硬性要求
只写 filename="报告.xlsx" 在 Outlook、Apple Mail、Gmail Web 全部失效；filename="=?UTF-8?B?5byg5LiJ.xlsx?=" 也靠不住——现代客户端只认 RFC 5987 格式。
- 附件头必须用：
Content-Disposition: attachment; filename*=UTF-8''%E6%8A%A5%E5%91%8A.xlsx（注意两个单引号） - 中文名要先 URL 编码（不是 Base64），再拼进
filename*=UTF-8''后面；可用UTL_URL.ESCAPE或手写转换函数 - 整个 MIME 段之间必须用唯一 boundary 分隔，且每个段开头要写
--BOUNDARY_STRING，结尾写--BOUNDARY_STRING--，结尾多一个-都会解析失败
正文或主题含中文，不能只靠 WRITE_DATA
UTL_SMTP.WRITE_DATA 只处理 VARCHAR2，走数据库字符集（如 AL32UTF8），但 SMTP 协议本身是 7-bit ASCII。中文直接传进去，中间设备可能截断或转义。
- 必须用
UTL_SMTP.WRITE_RAW_DATA+UTL_RAW.CAST_TO_RAW绕过字符集转换 - 主题编码推荐用
MIME_HEADER_ENCODE（Oracle 12c+ 自带）：MIME_HEADER_ENCODE(p_subject, 'UTF-8', 'B')，生成形如=?UTF-8?B?5byg5LiJ?=的标准格式 - 如果版本低于 12c，得自己 Base64 编码再拼头，且确保换行符是
UTL_TCP.CRLF（CHR(13)||CHR(10)），不能用CHR(10)单换行
附件内容读取失败？BFILE 和 BLOB 路径权限是隐形门槛
你写了 UTL_RAW.CAST_TO_RAW，也调了 DBMS_LOB.READ，但附件体始终为空——大概率是目录或文件权限问题。
- 用
BFILE读文件时，CREATE DIRECTORY的路径必须是数据库服务器本地真实路径，且 Oracle OS 用户（如 oracle）对该路径有读权限 - 用
BLOB存附件时，确保DBMS_LOB.LOADBLOBFROMFILE调用前已DBMS_LOB.CREATETEMPORARY，否则大文件直接 ORA-06502 - 附件二进制内容每 57 字节就要插入一个换行（Base64 规范），别一次性
WRITE_RAW_DATA整个 BLOB，容易超缓存——分块读、分块写，每次 ≤ 2000 字节较稳
真正难的不是写完代码，而是每封邮件都要在至少三种客户端（Outlook Desktop、Gmail Web、Apple Mail）里点开附件、查看中文主题、检查 HTML 渲染——这些细节没有统一标准，只能靠实测。别信“本地测试通过”，生产环境的邮件网关可能悄悄重写 MIME 头或剥离 Content-Transfer-Encoding。
