邮件客户端（如 Gmail）会自动折行过长的 HTML 行，导致原始 URL 中间被插入换行符和空格，进而被 URL 编码为 %20；解决方案是控制 HTML 行长度或启用 Base64 编码传输。
邮件客户端（如 gmail）会自动折行过长的 html 行，导致原始 url 中间被插入换行符和空格，进而被 url 编码为 `%20`；解决方案是控制 html 行长度或启用 base64 编码传输。
在 PHP 发送 HTML 邮件时，看似规范的链接（如 http://rfp.wabtec.com/production/apps/documentControl）点击后却跳转到含 %20 的错误地址（如 documen%20tControl），根本原因并非代码中存在空格，而是邮件传输过程中的 MIME 行长度限制所致。
根据 RFC 2822 规范，纯文本邮件行长度不应超过 998 字符（实践中多数邮件服务如 Gmail 会在约 1000 字符处强制折行）。当你的 $email_body 字符串拼接为单行长 HTML（尤其含内联样式、多层嵌套标签），PHP 的 mail() 函数在构造 MIME 包时可能未正确处理软折行（soft line break），导致换行符（\n 或 \r\n）被错误地转换为空格并参与 URL 编码——这就是 %20 的真实来源。
✅ 推荐解决方案：拆分 HTML 行 + 合理换行
最直接有效的方式是显式控制 HTML 源码的换行位置，避免超长单行。将原本用 . 连接的长字符串改为多行字符串字面量，并确保每行不超过 76–998 字符（推荐 ≤ 76 字符以兼容所有 MTA）：
$email_body = "<style type="text/css">
BODY {FONT-FAMILY: arial,helvetica,sans-serif,verdana; FONT-SIZE: 14px;}
.heading {FONT-FAMILY: arial,helvetica,sans-serif,verdana; FONT-SIZE: 16px; FONT-WEIGHT: bold;}
th {text-align: left; padding-right: 10px; padding-bottom: 5px;}
td {padding-bottom: 5px;}
</style><div>Hello</div><br><div>$body_one</div><br>
| File: | $name |
|---|---|
| Type: | $type |
| Description: | $description |
";
⚠️ 注意：此处换行符 \n 是 PHP 字符串中的合法空白，不会影响 HTML 渲染，但能防止邮件服务器误折行。
? 进阶方案：启用 Base64 编码（更可靠）
若项目对邮件兼容性要求极高（尤其含非 ASCII 字符或复杂结构），建议升级 MIME 头并 Base64 编码整个 HTML 正文：
// 生成 Base64 编码的 HTML 内容
$encoded_body = base64_encode($email_body);
$email_headers = "MIME-Version: 1.0\r\n" .
"Content-Type: text/html; charset=utf-8\r\n" .
"Content-Transfer-Encoding: base64\r\n" .
"From: RFPC Document System \r\n" .
"Reply-To: RFPC Document System ";
$email_send = @mail($email_to, $email_subject, $encoded_body, $email_headers);
Base64 编码可彻底规避行长度问题，且 UTF-8 支持更完善（需同步将 charset=iso-8859-1 改为 utf-8）。
✅ 最佳实践总结
- 永远不要依赖超长单行 HTML：将
- 验证实际发送内容：使用 Mailtrap 或本地 SMTP 日志捕获原始 MIME 源码，确认是否含异常空格；
- 优先使用现代邮件库：如 PHPMailer 或 Symfony Mailer，它们内置 MIME 分段、编码与行折叠逻辑，大幅降低此类风险；
- URL 健壮性兜底：服务端接收链接时，可对路径做 urldecode() 处理（但不应替代前端修复）。
通过控制 HTML 行结构或启用 Base64 编码，即可 100% 规避 %20 插入问题，确保审批链接精准直达目标页面。
