Server.UrlEncode与HttpUtility.UrlEncode
Server.UrlEncode和HttpUtility.UrlEncode是否有区别？
HttpServerUtility.UrlEncode将HttpUtility.UrlEncode内部使用HttpUtility.UrlEncode 。 没有具体的区别。 Server.UrlEncode存在的Server.UrlEncode是与经典的ASP兼容。
我曾经对这些方法感到头痛， 我build议您避免使用UrlEncode任何变体，而使用Uri.EscapeDataString – 至less应该有一个易于理解的行为。
让我们来看看…
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％true”==>“100 %% 20true”（好吧，你的url现在被破坏了）
- “test A.aspx＃anchor B”==>“test％20A.aspx ＃anchor％20B ”
- “test A.aspx？hmm＃anchor B”==>“test％20A.aspx？hmm #anchor B ”（ 注意与前面的转义序列的区别！ ）
它还具有特定的MSDN文档“编码URLstring的path部分，以实现从Web服务器到客户端的可靠HTTP传输”。 – 没有真正解释它做什么。 你不太可能在乌兹山脚下自杀
总之，坚持到Uri.EscapeDataString 。
请记住，你可能不应该使用任何一种方法。 微软的反跨站点脚本库包含了对HttpUtility.UrlEncode和HttpUtility.HtmlEncode替代，它们更符合标准，更安全。 作为奖励，您也可以获得JavaScriptEncode方法。
Server.UrlEncode（）是为了向经典ASP提供向后兼容性，
Server.UrlEncode(str);
相当于：
HttpUtility.UrlEncode(str, Response.ContentEncoding);
同样， Server.UrlEncode()调用HttpUtility.UrlEncode()
