在我的网站中呈现 URL 时如何避免双重 URL 编码？

Question

用户在文本输入中向我的网站提供正确转义的 URL 和原始 URL；例如，我认为这两个 URL 是等价的：

https://www.cool.com/cool%20beans
https://www.cool.com/cool beans

现在我想在以后查看这些数据时将它们呈现为

<a>

标签。我被困在编码给定文本和获取这些链接之间：

<a href="https://www.cool.com/cool%2520beans">   <!-- This one is broken! -->
<a href="https://www.cool.com/cool%20beans">

或者不编码并得到这个：

<a href="https://www.cool.com/cool%20beans">
<a href="https://www.cool.com/cool beans">       <!-- This one is broken! -->

从用户体验的角度来看，现代浏览器的最佳出路是什么？我在对他们的输入进行解码传递，或者我上面列出的第二个选项之间左右为难，我们不对

href

属性进行编码。

Answer 1

如果你想避免对链接进行双重编码，你可以在两个链接上使用

urldecode()

，然后在之后使用

urlencode()

，解码 URL，例如“https://www.cool.com/cool beans”将返回相同的值，而解码“https://www.cool.com/cool%20beans”将返回空格。这使得两个链接都可以自由地正确编码。

或者，可以使用

strpos()

功能扫描编码字符，例如

if ($pos = strpos($url, "%20") {
    //Encoded character found
}

理想情况下，将扫描一组常见的编码字符，代替“%20”

Answer 2

你不应该接受这样的请求，因为它们是无效的。

https://datatracker.ietf.org/doc/html/rfc9112#section-3.2-3

请求目标中不允许有空格。不幸的是，一些 用户代理无法正确编码或排除在 超文本引用，导致那些不允许的字符被 在格式错误的请求行中作为请求目标发送。

无效请求行的接收者应该用 400（错误请求）错误或 301（永久移动）重定向 正确编码的请求目标。收件人不应该尝试 自动更正，然后在没有重定向的情况下处理请求，因为 无效的请求行可能是故意设计来绕过安全 沿着请求链过滤。

告诉您的客户发送格式正确的 HTTP 请求。

尝试接受此类请求可能会导致错误。正如其他人所建议的那样，如果您在请求目标中看到无效字符，则可以有条件地进行预编码。您也可以对所有请求进行解码+编码。但是，如果请求包含具有编码和解码含义的字符（例如

$

和

%24

，它们具有不同的含义），那么两者都是有问题的。

您唯一能安全做的就是拒绝此类无效请求。