Server.UrlEncode 与 HttpUtility.UrlEncode

Question

Server.UrlEncode 和 HttpUtility.UrlEncode 之间有区别吗？

Answer 1

我之前对这些方法感到非常头疼，我建议您避免任何UrlEncode的变体，而是使用Uri.EscapeDataString - 至少具有可理解的行为。

让我们看看...

HttpUtility.UrlEncode(" ") == "+" //breaks ASP.NET when used in paths, non-
                                  //standard, undocumented.
Uri.EscapeUriString("a?b=e") == "a?b=e" // makes sense, but rarely what you
                                        // want, since you still need to
                                        // escape special characters yourself

但我个人最喜欢的是HttpUtility.UrlPathEncode - 这东西真的难以理解。 它编码：

• “”==> “%20”
• “100%正确”==> “100%%20true”（好吧，您的网址现在已损坏）
• “test A.aspx#anchor B”==> "test%20A.aspx#anchor%20B"
• "test A.aspx?hmm#anchor B" ==> “test%20A.aspx?hmm#anchor B”（注意与之前的转义序列的区别！）

它还有可爱的特定 MSDN 文档“对路径部分进行编码”用于从 Web 服务器到客户端进行可靠 HTTP 传输的 URL 字符串。” - 没有实际解释它的作用。 你不太可能用乌兹冲锋枪搬起石头砸自己的脚……

简而言之，坚持Uri.EscapeDataString。

Answer 2

HttpServerUtility.UrlEncode 将在内部使用 HttpUtility.UrlEncode。 没有具体的区别。 Server.UrlEncode 存在的原因是与经典 ASP 的兼容性。

Answer 3

自第一次提出这个问题以来已经快进近 9 年了，在 .NET Core 和 .NET Standard 的世界中，我们最常见的 URL 编码选项似乎是 WebUtility.UrlEncode （在System.Net）和Uri.EscapeDataString。 从这里和其他地方最流行的答案来看，Uri.EscapeDataString似乎更可取。 但真的是这样吗？ 我做了一些分析来理解这些差异，这就是我得出的结论：

• WebUtility.UrlEncode 将空格编码为 +； Uri.EscapeDataString 将其编码为 %20。
• Uri.EscapeDataString 百分号编码 !、(, ) 和 *； WebUtility.UrlEncode 没有。
• WebUtility.UrlEncode 百分比编码 ~; Uri.EscapeDataString 没有。
• Uri.EscapeDataString 对长度超过 65,520 个字符的字符串抛出 UriFormatException； WebUtility.UrlEncode 没有。 （一个比您想象的更常见的问题，特别是在处理 URL 编码的表单数据时 .)
• Uri.EscapeDataString 在 UriFormatException ="noreferrer">高代理字符； WebUtility.UrlEncode 没有。 （这是 UTF-16 的事情，可能不太常见。）

出于 URL 编码的目的，字符属于 3 类之一：未保留的（URL 中合法的）； 保留（合法但具有特殊含义，因此您可能想要对其进行编码）； 以及其他所有内容（必须始终进行编码）。

根据 RFC，保留字符为： :/ ?#[]@!$&'()*+,;=

未保留的字符是字母数字和 -._~

结论

Uri.EscapeDataString 明确定义了它的使命：%-对所有保留字符和非法字符进行编码。 WebUtility.UrlEncode 在定义和实现方面都更加模糊。 奇怪的是，它编码了一些保留字符，但没有编码其他字符（为什么是括号而不是方括号？？），更奇怪的是，它编码了无辜的未保留的 ~ 字符。

因此，我同意流行的建议 - 尽可能使用 Uri.EscapeDataString ，并理解像 / 和 ? 这样的保留字符将被编码。 如果您需要处理潜在的大字符串，特别是 URL 编码的表单内容，则需要依靠 WebUtility.UrlEncode 并接受其怪癖，或者以其他方式解决该问题。

---

编辑：我已经尝试纠正所有怪癖上面在 Flurl 中通过 Url.Encode、Url.EncodeIllegalCharacters 提到和 Url.Decode 静态方法。 这些位于 核心包 中（它很小，不包含所有 HTTP 内容），或者随意从源头删除它们。 我欢迎您对这些内容提出任何意见/反馈。

---

这是我用来发现哪些字符编码不同的代码：

var diffs =
    from i in Enumerable.Range(0, char.MaxValue + 1)
    let c = (char)i
    where !char.IsHighSurrogate(c)
    let diff = new {
        Original = c,
        UrlEncode = WebUtility.UrlEncode(c.ToString()),
        EscapeDataString = Uri.EscapeDataString(c.ToString()),
    }
    where diff.UrlEncode != diff.EscapeDataString
    select diff;

foreach (var diff in diffs)
    Console.WriteLine($"{diff.Original}\t{diff.UrlEncode}\t{diff.EscapeDataString}");

Answer 4

请记住，您可能不应该使用其中任何一种方法。 Microsoft 的 反跨站脚本库 包括 < code>HttpUtility.UrlEncode 和 HttpUtility.HtmlEncode 都更符合标准，也更安全。 作为奖励，您还可以获得一个 JavaScriptEncode 方法。

Answer 5

Server.UrlEncode() 是为了提供与经典 ASP 的向后兼容性，

Server.UrlEncode(str);

相当于：

HttpUtility.UrlEncode(str, Response.ContentEncoding);

Answer 6

同样，Server.UrlEncode()调用HttpUtility.UrlEncode()