HttpServerUtility.UrlPathEncode 与 HttpServerUtility.UrlEncode

Posted 2023-02-22

【中文标题】HttpServerUtility.UrlPathEncode 与 HttpServerUtility.UrlEncode

【英文标题】：HttpServerUtility.UrlPathEncode vs HttpServerUtility.UrlEncode

【发布时间】：2011-05-07 22:41:45

【问题描述】：

HttpServerUtility.UrlPathEncode 和 HttpServerUtility.UrlEncode 有什么区别？我什么时候应该选择一个而不是另一个？

【问题讨论】：

Server.UrlEncode vs. HttpUtility.UrlEncode 的可能重复项（答案包括对UrlPathEncode 的引用）

不同意。尽管另一个问题的答案是指 UrlPathEncode，但问题显然不一样。

请不要使用 HttpServerUtility.UrlPathEncode。你应该使用 HttpServerUtility.UrlEncode

【参考方案1】：

更新：从 4.5 开始，根据 MSDN 参考，Microsoft 建议仅使用 UrlEncode。此外，之前在 MSDN 中列出的信息并未完全描述这两种方法的行为 - 请参阅 cmets。

区别在于空格转义 - UrlEncode 将它们转义为 + 号，UrlPathEncode 转义为 %20。 + 和 %20 仅当它们是 QueryString 部分 per W3C 的一部分时才等效。因此，您不能使用 + 号转义整个 URL，只能转义查询字符串部分。底线是 UrlPathEncode 总是更好恕我直言

您可以使用 UrlEncode() 方法或 UrlPathEncode() 方法对 URL 进行编码。但是，这些方法返回不同的结果。 UrlEncode() 方法将每个空格字符转换为加号 (+)。 UrlPathEncode() 方法将每个空格字符转换为字符串“%20”，它以十六进制表示法表示一个空格。在对 URL 的路径部分进行编码时使用 UrlPathEncode() 方法，以保证解码后的 URL 一致，无论哪个平台或浏览器执行解码。

http://msdn.microsoft.com/en-us/library/4fkewx0t.aspx

【讨论】：

实际上除了对空格的处理之外，还有更多的区别，尽管文档并没有真正说明这一点。 UrlEncode 将对诸如“？”之类的字符进行编码。和被 UrlPathEncode 忽略的“&”。见这里：connect.microsoft.com/VisualStudio/feedback/details/551839/…

UrlPathEncode 在第一次出现 "?" 之后也不会编码任何内容。它假设其余部分是查询字符串，并假设查询字符串已经编码。

HttpUtility.UrlPathEncode("your.URI.here") + "?" + HttpUtility.UrlEncode("name1") + "=" + HttpUtility.UrlEncode("value1") + "&" + HttpUtility. UrlEncode("name2") + "=" + HttpUtility.UrlEncode("value2") + "#" + HttpUtility.UrlPathEncode("anchor")

值得注意的是，.NET 4.5 版本的 UrlPathEncode 文档声明：“不要使用；仅用于浏览器兼容性。使用 UrlEncode。” msdn.microsoft.com/en-us/library/… HttpUtility.UrlPathEncode 和 HttpServerUtility.UrlPathEncode 都是如此

UrlPathEncode 似乎与 javascript 的 encodeURIComponent 编码一致。当我需要渲染其输出可以在浏览器中使用decodeURIComponent 解码的 URL 时，我使用UrlPathEncode（反之亦然）。

【参考方案2】：

UrlEncode 对查询字符串值很有用（所以在每个 = 的左边或特别是右边）。

在此 url 中，foo、fooval、bar 和 barval 应分别进行 UrlEncode ：

http://www.example.com/whatever?foo=fooval&bar=barval

UrlEncode 将所有内容（例如 ?、&、= 和 /、重音字符或其他非 ASCII 字符等）编码为 % 样式编码，但它编码为 + 的空格除外。这是表单样式的编码，最适合您打算放入查询字符串（或者可能在 url 中的两个斜杠之间）作为参数的内容，而不会因为 url 的控制字符（如 &）而变得混乱。否则，不幸地在用户表单输入或 db 值中放置 & 或 = 可能会破坏事情。

编辑：Uri.EscapeDataString 与 UrlEncode 非常接近，并且可能更可取，尽管我不知道确切的区别。

UrlPathEncode 对查询字符串的其余部分很有用，它会影响 ? 左侧的所有内容。

在这个url中，整个url（从http到barval）都要经过UrlPathEncode。

http://www.example.com/whatever?foo=fooval&bar=barval

UrlPathEncode 不编码 ?、&、= 或 /。但是，它确实像 UrlEncode 一样，使用 % 表示法对重音/非 ASCII 字符进行编码，并且空格也变为 %20。这有助于确保 url 有效，因为空格和重音字符不是。它不会触及您的查询字符串（？右侧的所有内容），因此您必须使用上面的 UrlEncode 对其进行编码。

【讨论】：

UrlPathEncode 本质上是错误的；它不可能正常工作。考虑 url http://example.com/really?-unexpected-truths?id=3&user=eamon & co 的意图是第一个问号是 url 的一部分，第二个是 uri 查询组件的分隔符，但没有办法知道。再次的意图是让第一个 & 成为分隔符，第二个成为内容......但同样，没有办法知道。编码的重点在于数据可能包含底层格式使用的特殊控制字符，因此您不能以这种方式编码。

UrlEncode 只是 EscapeDataString 的轻度非标准旧版本。改用它；如果您希望生成的 uri 具有可靠的可移植性，请不要使用 UrlEncode。

@EamonNerbonne：我认为您的 TL;DR 具有危险的误导性。断章取义，它说，“根本不用编码。”我知道您指出要改用 EscapeDataString，并且应该在您不打算包含控制字符的 URL 的任何部分上以分段方式使用它，但 TL;DR 甚至没有提示在任何一个。

评论长度有限；我在另一条评论中写道。

嗯，读完这一切后，我更加困惑了。

【参考方案3】：

尽可能简单地解释一下：

HttpUtility.UrlPathEncode("http://www.foo.com/a b/?eggs=ham&bacon=1") 

变成

http://www.foo.com/a%20b/?eggs=ham&bacon=1

和

HttpUtility.UrlEncode("http://www.foo.com/a b/?eggs=ham&bacon=1") 

变成

http%3a%2f%2fwww.foo.com%2fa+b%2f%3feggs%3dham%26bacon%3d1