邮件客户端（如 Gmail）会自动折行过长的 HTML 行，将换行符转换为 %20，从而破坏原始 URL；解决方案是控制 HTML 行长度或启用 Base64 编码。
邮件客户端（如 gmail）会自动折行过长的 html 行，将换行符转换为 `%20`，从而破坏原始 url；解决方案是控制 html 行长度或启用 base64 编码。
在 PHP 中通过 mail() 发送 HTML 邮件时，若 标签中的 URL 被意外插入 %20（即空格的 URL 编码），并非代码中存在真实空格，而是邮件传输过程中 MIME 行长度限制引发的自动折行问题。
RFC 2822 规定，纯文本邮件行不应超过 78 字符（部分客户端放宽至 ~1000 字符），超出后客户端（尤其是 Gmail、Outlook Web）会强制在任意空白处插入软换行（soft line break）。而某些客户端在解析 HTML 时，会将此类换行错误地转义为 %20 —— 这正是 http://rfp.wabtec.com/production/apps/documen%20tControl 中 documen%20tControl 的成因：documentControl 被断开在 documen 和 tControl 之间，中间插入了 %20。
✅ 推荐解决方案：控制 HTML 行长 + 合理换行
最简单有效的方式是避免超长单行 HTML 字符串，显式插入换行符 \n，确保每行不超过 78–1000 字符：
$email_body = "<style type="text/css">\n" .
"BODY {FONT-FAMILY: arial,helvetica,sans-serif,verdana; FONT-SIZE: 14px;}\n" .
".heading {FONT-FAMILY: arial,helvetica,sans-serif,verdana; FONT-SIZE: 16px; FONT-WEIGHT: bold;}\n" .
"th {text-align: left; padding-right: 10px; padding-bottom:5px}\n" .
"td {padding-bottom:5px}\n" .
"</style>\n" .
"<div>Hello</div><br>\n" .
"<div>$body_one</div><br>\n" .
"
| File: | $name |
|---|---|
| Type: | $type |
| Description: | $description |
\n" . "
\n" . "
";
✅ 关键点：使用 \n 显式换行，而非拼接无换行的超长字符串；PHP 字符串连接中的 \n 会被保留在最终 HTML 中，帮助邮件客户端正确解析，避免自动插入 %20。
⚠️ 进阶方案：启用 Base64 编码（更健壮）
若邮件内容复杂或需更高兼容性，建议升级 MIME 头并启用 base64 编码：
// 替换原有 $email_headers
$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 \r\n";
// 对 $email_body 进行 Base64 编码
$encoded_body = chunk_split(base64_encode($email_body), 76, "\r\n");
$email_send = @mail($email_to, $email_subject, $encoded_body, $email_headers);
Base64 编码将整个 HTML 主体转为 ASCII 安全字符串，并严格按 76 字符/行分隔（符合 RFC 2045），彻底规避客户端折行污染 URL 的风险。
? 验证与调试建议
- 使用 Mail Tester 或本地 SMTP 日志检查原始邮件源码，确认 是否被截断；
- 在浏览器开发者工具中检查邮件渲染后的 DOM，确认链接 href 属性是否含 %20；
- 避免在 URL 中使用中文、空格或特殊字符 —— 即使修复了折行问题，也应始终对动态参数（如 $file）调用 rawurlencode()：
"<a href="http://rfp.wabtec.com/docs/documentSystem/docs/%22%20.%20rawurlencode(%24file)%20.%20%22">$name</a>"
综上，%20 并非代码缺陷，而是邮件传输链路中的标准化副作用。通过规范 HTML 行结构或启用 Base64 编码，即可稳定交付可点击、无损的 URL。
