问题描述
我有一个给我地狱临时服务器运行IIS的MVC路线。我在本地运行的Visual Studio 2010的开发服务器。
I have an MVC route that is giving me hell on a staging server running IIS. I am running Visual Studio 2010's development server locally.
下面是实际工作对我开发框的样本网址：
Here is a sample URL that actually works on my dev box:
Root/CPUBoards/Full+Size
Results
Server Error404 - File or directory not found.
The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.
下面是完整的行为，我看到了。
Here is the complete behaviour I am seeing.
本地主机：
Root/CPUBoards/Full Size - Resolves
Root/CPUBoards/Full%20Size - Resolves
Root/CPUBoards/Full+Size - Resolves
临时服务器与IIS 7.0：
Staging Server with IIS 7.0:
Root/CPUBoards/Full Size - Resolves
Root/CPUBoards/Full%20Size - Resolves
Root/CPUBoards/Full+Size - 404 Not Found Error.
任何想法？我需要的EN codeD的版本有几个原因...工作不会跟他们浪费时间。
Any ideas? I need to work with the encoded version for several reasons... won't waste your time with them.
HttpUtility.UrlEn code（全尺寸）与加唱...全文+大小，则返回的版本。这工作对我的dev的盒子，而不是临时服务器上。我想preFER只得到它的工作在服务器上，因为我已经拥有一切测试，并在当地工作，但我不知道从哪里开始寻找服务器配置来获得它的行为方式相同。
HttpUtility.UrlEncode("Full Size") returns the version with the plus sing... Full+Size. This works on my dev box, but not on the staging server. I would prefer to just get it working on the server, since I already have everything else tested and working locally, but I have no idea where to start looking on the server configuration to get it to behave the same way.
谢谢！
推荐答案
+ 只被在一个空间的特殊含义应用程序/ x -www外形urlen codeD 数据，如URL的查询字符串部分。
+ only has the special meaning of being a space in application/x-www-form-urlencoded data such as the query string part of a URL.
在像路径组件的URL的其他部分， + 的字面意思是一个加号。因此，解决全+尺寸来的unen codeD名称全尺寸不应该在任何地方工作。
In other parts of the URL like path components, + literally means a plus sign. So resolving Full+Size to the unencoded name Full Size should not work anywhere.
在路径组件的空间的唯一正确的形式为 20％。 （它仍然有效时，因为浏览器察觉错误并纠正它为您键入一个实际的空间。）％20 也适用于形式的URL-CN codeD数据为好，所以这是一般最安全的始终使用。
The only correct form of a space in a path component is %20. (It still works when you type an actual space because the browser spots the error and corrects it for you.) %20 also works in form-URL-encoded data as well, so it's generally safest to always use that.
不幸的是 HttpUtility.UrlEn code 被误导命名。它产生 + 在它的输出，而不是％20 ，所以这真的是一个形式的URL-CN codeR而不是一个标准的URL-CN $ C $铬。不幸的是我不知道的ASP.NET功能为真正的URL-CN code字符串中的路径使用，所以我只能建议是做一个字符串替换的 + 到 20％之后的编码。
Sadly HttpUtility.UrlEncode is misleadingly-named. It produces + in its output instead of %20, so it's really a form-URL-encoder and not a standard URL-encoder. Unfortunately I don't know of an ASP.NET function to "really URL-encode" strings for use in a path, so all I can recommend is doing a string replace of + to %20 after encoding.
另外，应避免使用路径的部分空间，如：通过替换它们 - 。这是常见的被插入到URL'塞'的标题，他们减少了简单的字母数字和'安全'的标点符号，以避免难看的％NN 序列填充的URL。
Alternatively, avoid using spaces in path parts, eg. by replacing them with -. It's common to ‘slug’ titles being inserted to URLs, reducing them to simple alphanumerics and ‘safe’ punctuation, to avoid filling the URL with ugly %nn sequences.
这篇关于加号（+）在MVC参数会导致404在IIS 7.0上的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！