是否有任何函数可以将转义的 Url 字符串转换为其非转义形式？ System.Web.HttpUtility.UrlDecode() 可以完成这项工作，但我不想添加对 System.Web.dll 的引用。由于我的应用程序不是 Web 应用程序，因此我不想添加仅在程序集中使用函数的依赖项。
更新：检查Rick Strahl's blog post关于同样的问题。
【问题讨论】：
稍微了解一下为什么会有所不同。一个转换为大写，一个转换为小写。所以解码是特定于编码类型的。
System.Net.WebUtility（内部）+ 65：
private static char IntToHex(int n)
{
if (n <= 9)
return (char) (n + 48);
else
return (char) (n - 10 + 65);
}
System.Web.Util.HttpEncoderUtility（内部）- + 97
public static char IntToHex(int n)
{
if (n <= 9)
return (char) (n + 48);
else
return (char) (n - 10 + 97);
}
示例：
var test1 = WebUtility.UrlEncode("http://www.test.com/?param1=22¶m2=there@is<a space");
var test2 = HttpUtility.UrlEncode("http://www.test.com/?param1=22¶m2=there@is<a space");
回应：
test1 -> http%3A%2F%2Fwww.test.com%2F%3Fparam1%3D22%26param2%3Dthere%40is%3Ca+space
test2 -> http%3a%2f%2fwww.test.com%2f%3fparam1%3d22%26param2%3dthere%40is%3ca+space
【讨论】：
如果您使用的是 .NET 4.0 或更高版本，则可以使用WebUtility.UrlDecode，它适用于客户端配置文件，并且还可以正确处理加号（请参阅this 讨论）。
【讨论】：
System.Net.WebUtility.HtmlDecode 也在开发 .NET 4.0 客户端配置文件。
【讨论】：
@史密斯
我遇到了保存问题。没有变化或只是进一步混乱。
在测试了很多东西后，我注意到一个测试字符串确实解码了。最终我不得不创建一个新的空字符串，将其值设置为编码字符串，然后在新字符串上运行 WebUtility.HtmlDecode 和 Uri.UnescapeDataString。出于某种原因，我不得不按照我提到的顺序运行解码和取消转义。奇怪。
我用这样的方法解决了。
Dim strEncoded as string="http%3a%2f%2fwww.google.com%2fsearch%3fhl%3den%26q%3dsomething%20%2323%26btnG%3dGoogle%2bSearch%26aq%3df%26oq%3d"
Dim strDecoded as string = ""
strDecoded = strEncoded
strDecoded = WebUtility.HtmlDecode(strDecoded)
strDecoded = Uri.UnescapeDataString(strDecoded)
【讨论】：
编辑：使用静态方法Uri.UnescapeDataString()解码您的网址：
编码： http%3a%2f%2fwww.google.com%2fsearch%3fhl%3den%26q%3dsomething%20%2323%26btnG%3dGoogle%2bSearch%26aq%3df%26oq%3d
解码： http://www.google.com/search?hl=en&q=something #23&btnG=Google+Search&aq=f&oq=
【讨论】：
Uri.UnescapeDataString(myurl)
Uri.UnescapeDataString() 构建了一个实用程序类，可以正确处理+ 标志。请参阅his blog post 了解更多详情。
UnescapeDataString 现在处理加号。 repl.it/repls/MildGlossyPorts
不再加载 System.Web.dll - 正如其他人所指出的，除非您知道您需要处理可能没有它的客户端（“客户端配置文件”、“紧凑框架”、 “微框架”、“silverlight”）。
重新空间；真的不会很多；请注意，.NET 程序集是按方法进行 JIT 处理的，因此仅使用几种方法不会产生任何重大开销。
真正的问题 (IMO) 是您对客户端拥有 System.Web.dll 的信心程度；如果您对他们使用完整的框架感到满意，那就去吧。
【讨论】：
您已经非常依赖 .NET 框架、CLR 等。所以，事实上，您已经间接依赖 System.Web.DLL；如果没有本地计算机上的存在，您的应用程序将无法运行。
你担心记忆？你有记忆问题吗？如果您的内存问题非常严重，以至于无法将几 KB 的 DLL 加载到应用程序的内存中，那么您为什么要编写 .NET 代码？或者你只是过早地优化？
所以不用担心。
【讨论】：
Microsoft ACE 团队在Anti-XSS library 中有一个扩展（和更好）的解码版本。但是我不确定它是否只是通过。
（说实话，我不明白你为什么那么担心对 System.web.dll 的依赖）
【讨论】：