URL 中 + 与 %20 空格差异指南

这个页面解决什么问题

空格在 URL 中常见表示是 %20，但在 application/x-www-form-urlencoded 表单编码中，+ 也常表示空格。问题在于加号本身也可能是合法数据，例如邮箱别名、搜索关键词、Base64 字符或签名串。如果把所有 + 都当空格，参数就会被改写。

这个问题常见于搜索词、广告关键词、邮箱地址、Base64 参数、支付签名和老式表单提交。

快速判断

• query 表单语义中 + 可能表示空格，但 path 中通常就是加号。
• 真实加号作为参数值时应编码为 %2B。
• 标准 Base64 放进 query 前必须处理 +。
• 签名参数中的空格规则必须与平台文档一致。

可复制示例：错误输入与修复后输入

坏样例没有保护真实加号；修复样例把真实加号编码为 %2B。

[email protected]

email=dev%2Balerts%40example.com

坏样例在某些表单解码规则下会变成 dev [email protected]。如果加号是邮箱别名的一部分，应编码为 %2B。

诊断步骤

1. 确认参数来自普通 URL query 还是表单编码。
2. 把真实空格和真实加号分别标记出来。
3. 真实加号作为值时编码为 %2B，空格按目标规则使用 %20 或 +。
4. 服务端打印解析后的原始参数，确认没有把加号变空格。
5. 对 Base64 参数优先使用 Base64URL 或再进行 URL 编码。

空格问题的关键是语境。同样一个 +，在表单 query 中可能是空格，在邮箱地址中是别名，在 Base64 中是字母表字符，在签名中是必须逐字节保留的输入。

常见错误表

常见误判

• 看到加号就统一替换成空格。
• 把 path、query 和表单编码规则混用。
• 复制浏览器地址栏显示值作为签名前原文。
• 忽视真实加号在邮箱和 Base64 中的含义。

如果目标平台生成签名或校验回调，空格的表示方式属于协议的一部分。排查时记录“编码前值、编码后 URL、服务端解析值”三项。

隐私、安全和适用边界

用于排查时请使用脱敏样本。不要粘贴访问令牌、Cookie、客户资料、内部域名、未公开商业规则、支付记录或完整生产日志。页面适合处理公开示例、教学片段、复现样本和已经替换真实值的配置。

本页只解释编码语义，不决定平台签名规则。涉及支付、广告、OAuth 或邮件服务时，以平台文档为最终规则。

复制或发布前复核清单

1. 是否区分真实空格和真实加号。
2. 参数值中的真实加号是否编码为 %2B。
3. Base64 参数是否避免标准 + 直接入 query。
4. 服务端解析结果是否与预期一致。
5. 签名前字符串是否保存。
6. 是否使用脱敏邮箱和示例参数测试。

相关工具和延伸阅读

参考依据

• HTML 表单 URL 编码规则。
• WHATWG URL Standard：query 与 path 解析。
• MDN URLSearchParams：查询参数处理。

编辑记录：Ymir Tool editorial review，2026-06-01。本页作为 Sprint 3 新增案例/排错内容发布，目标是把单一工具入口扩展为可复核的任务说明、错误示例和操作边界。