为什么你的URL坏了（以及如何修复）

你把URL粘贴到邮件里。有人点击它。他们得到404。

URL看起来没问题。但在从你的浏览器到他们的浏览器之间的某个地方，一个空格变成了%20，一个&符号消失了，或者一个加号变成了完全不同的东西。

URL编码存在是因为URL只能包含某些字符。其他所有东西都需要被翻译。

特殊字符的问题

URL是在早期互联网时代用有限的字符集设计的。这些是安全的：

A-Z a-z 0-9 - _ . ~

其他所有东西？可能有问题。

空格变成%20或+，取决于上下文。带字面空格的URL会崩溃。

&符号（&）分隔查询参数。如果你的数据包含&符号，URL解析器认为它在开始一个新参数。

问号（?）标志查询字符串的开始。数据中的一个会混淆一切。

编码何时自动发生

浏览器在你输入URL时编码它们。这就是为什么你可以把"new york restaurants"粘贴到Google并且它有效。

但自动化系统通常不会。API、脚本、邮件客户端——它们可能完全按照写的传递你的URL。如果它包含不安全的字符，它就坏了。

双重编码陷阱

这里变得烦人了。

你编码一个URL。然后你把它作为参数放在另一个URL中。系统再次编码它。现在%20变成%2520。

解码时，你得到%20而不是空格。

这在重定向URL、追踪参数和OAuth回调中经常发生。如果你的URL看起来有额外的百分号被破坏，检查双重编码。

常见编码错误

编码整个URL。 不要。只编码值，不编码结构。https://不应该变成https%3A%2F%2F。

忘记加号。 在查询字符串中，+表示空格。如果你的数据有字面加号，它需要编码否则会消失。

假设编码是幂等的。 编码已编码的字符串产生不同的输出。在编码之前检查是否已编码。

实际示例

带空格的搜索查询：

之前：https://example.com/search?q=new york pizza
之后：https://example.com/search?q=new%20york%20pizza

回调URL作为参数：

callback = https://mysite.com/auth?token=abc
编码：   https%3A%2F%2Fmysite.com%2Fauth%3Ftoken%3Dabc

URL中的邮箱地址：

之前：user+tag@example.com
之后：user%2Btag%40example.com

调试URL问题

检查实际请求。 浏览器开发工具显示正在发送的内容。与你期望的比较。

解码并检查。 如果URL不工作，解码它以查看服务器实际接收的内容。

用特殊字符测试。 在测试数据中包括空格、&符号和加号。如果它在"test"下工作但在"test & verify"下失败，你有编码问题。

---

URL编码是那些无形工作直到它不工作的东西之一。理解规则有助于你在URL神秘崩溃时更快调试。