我在Azure上运行ASP.NET 4。我偶然发现了微软的这个很棒的新功能，其中服务器完全忽略了URL编码。
起初我遇到了％26的问题，并且收到了＆amp;标志是不允许的。 这显然是一个错误，因为％26不在＆amp;并且％26的全部意义是能够安全地将其传递给网址。
www.example.com/this-is-me-%26-microsoft /
我可以通过将此添加到web配置来解决此问题：
<httpRuntime requestValidationMode="2.0" executionTimeout="20" requestPathInvalidCharacters="" />
<pages validateRequest="false"/>
这解决了％26问题，但现在我发现问题远未结束，因为编码＃的％23表现得好像是＃而不是％23
www.example.com/%23this-should-work /
我需要永久解决这个问题。我不需要这个完全错误的请求验证。 我发现这个link谈论了这种疯狂，但我无法理解如何在网络应用中使用此URL_ESCAPE_SEGMENT_ONLY。
修改
从2009年发现这个link：看起来这个问题已经持续了一段时间，但是注意到了，因为微软并不关心......
EDIT2 !!!：
经过一整天的工作并尝试在互联网上找到的每一个可能的解决方案/解决方法（足以写完整本书），我已经将此视为一个非常具体的错误。 我的幸运是，通过纯粹的机会，测试用例url在这个段的开头有％23。
http://www.example.com/%23eleven/
事实证明，如果％23位于片段的开头，它会自动转义为＃并以＃处理，世界上没有办法改变它。
为了说明这一点，请运行：
Response.Write(Request.Url.GetComponents(UriComponents.SerializationInfoString, UriFormat.UriEscaped));
在包含流动网址的页面中
http://www.example.com/%23elevenand%23noteleven/
响应写入将输出：
http://www.example.com/#elevenand%23noteleven/
如果你这样做：
Response.Write(Request.Url.GetComponents(UriComponents.Fragment, UriFormat.Unescaped));
结果将是：
elevenand#noteleven/
P.S。除了我在整个调试过程中学到的这个特殊错误之外，.NET中的整个URL编码和解码在所有遗留（.NET 4之前版本）中都是完全的灾难，但也是所有新的。 NET 4的修改甚至更大的灾难就像在火中加入气体一样。没有一个能够正常工作，用户报告这一点会在董事会上发布大量帖子，但微软会忽略所有内容并将报告的错误关闭并解决并重复。