blocks|key|1293432|text|感叹号被认为是URL安全的ASCII字符，因此不编码百分比.|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1293433|来自MSDN|offset|length|1293434|UrlEncode方法URL-对被认为是URL安全的一组ASCII字符中的任何字符进行编码。空格被编码为ASCII+"%2B“字符。URL安全的ASCII字符包括ASCI字符(A到Z和a到z)、数字(0到9)和一些标点符号。下表列出了被视为URL安全的ASCII字符的标点符号。|blockquote|1293435|该表包含-+_+.+!+*+(+)|style|CODE|1293436|更新|BOLD|1293437|根据这个答案的说法，Uri.EscapeDataString在处理.NET+4.5项目时应该对.NET进行编码，但我无法在当前的机器上测试它。以前的EscapeDataString框架中的.NET不对上面的字符进行百分比编码。您可能只需使用String.Replace并替换转义URI中的上述字符。|1293438|entityMap|0|LINK|mutability|MUTABLE|url|https://msdn.microsoft.com/en-us/library/system.web.util.httpencoder.urlencode%2528v=vs.110%2529.aspx|1|https://stackoverflow.com/a/21771206/187697^0|0|2|4|0|0|0|4|D|0|0|2|0|A|K|22|G|3C|E|2|4|1|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|12|8|@]|9|@$D|13|E|14|1|15]]|A|$]]|$1|F|3|G|5|H|7|16|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|17|8|@$D|18|E|19|K|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|1A|8|@$D|1B|E|1C|K|O]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1D|8|@$D|1E|E|1F|K|L]|$D|1G|E|1H|K|L]|$D|1I|E|1J|K|L]]|9|@$D|1K|E|1L|1|1M]]|A|$]]|$1|R|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]]|S|$T|$5|U|V|W|A|$X|Y]]|Z|$5|U|V|W|A|$X|10]]]]

An exclamation mark is considered a URL-safe ASCII character and therefore not percentage encoded.

From <a href="https://msdn.microsoft.com/en-us/library/system.web.util.httpencoder.urlencode%28v=vs.110%29.aspx" rel="nofollow noreferrer">MSDN</a>

<blockquote>
 The UrlEncode method URL-encodes any character that is not in the set
 of ASCII characters that is considered to be URL-safe. Spaces are
 encoded as the ASCII "+" character. URL-safe ASCII characters include
 the ASCI characters (A to Z and a to z), numerals (0 to 9), and some
 punctuation marks. The following table lists the punctuation marks
 that are considered URL-safe ASCII characters.
</blockquote>

The table contains <code>- _ . ! * ( )</code>

Update

According to <a href="https://stackoverflow.com/a/21771206/187697">this answer</a>, <code>Uri.EscapeDataString</code> should encode the <code>!</code> when targetting .NET 4.5 projects but I'm unable to test it on my current machine. <code>EscapeDataString</code> on previous .NET frameworks does not percentage encode the characters above. You may simply need to use <code>String.Replace</code> and replace the characters above from the escaped URI.

blocks|key|132790|text|因此，我们有一些字符是在“灰色”区域，可以是，但不需要被编码。|type|blockquote|depth|inlineStyleRanges|entityRanges|data|132791|所有字符都可以编码。http://stackoverflow.com/questions和http://stackoverflow.com/%2571%2575%2565%2573%2574%2569%256F%256E%2573都是相同的。|unstyled|offset|length|style|CODE|132792|唯一不能对字符进行编码的情况是，如果它是以一种在URI中具有特殊意义的方式使用的，例如/分离路径元素。|132793|必须对字符进行编码的唯一时间，如果：|132794|这是其中一个特殊意义的字符，而不是与那个特殊的含义一起使用。|ordered-list-item|132795|它是在特定URI方案或特定位置中可能具有特殊含义的保留字符之一。|132796|它有一个关于U%2B007F的代码点。|132797|不过，最后两种情况也有例外。|132798|在第三种情况下，如果使用IRI，则不对这些字符进行编码，这基本上就是IRI的定义。您可以通过执行或取消该编码在IRI和URI之间进行转换。(主机部分中的任何这样的字符都必须编码，而不是URI编码)。|132799|在第二种情况下，如果字符在所述上下文中不用作分隔符，则不对其进行编码是安全的。例如，&可以保留在某些URI中，但不能放在HTTP中，因为HTTP经常用作查询数据的分隔符。不过，这取决于对特定URI方案的特定知识。这也可能是不值得冒险的一些其他过程，没有意识到它是好的。|132800|!就是一个例子。RFC+3986包括生产：|132801|reserved++++=+gen-delims+/+sub-delims

gen-delims++=+":"+/+"/"+/+"?"+/+"#"+/+"["+/+"]"+/+"@"

sub-delims++=+"!"+/+"$"+/+"&"+/+"'"+/+"("+/+")"
++++++++++++/+"*"+/+"%2B"+/+","+/+";"+/+"="|code-block|syntax|javascript|132802|因此，!在一组字符中，可以安全地保留未编码或不编码，这取决于所使用的方案。|132803|通常，如果您正在编写自己的编码代码(例如编写HttpEncoder实现时)，那么最好始终对!进行编码，但是如果您使用的编码器并不总是对!进行编码，这也是可以的；当然，在HTTP中，这不会有任何区别。|132804|entityMap^0|0|A|Y|19|1G|0|17|1|0|0|0|0|0|0|0|16|1|0|0|1|0|0|3|1|0|M|B|19|1|1V|1|0^^$0|@$1|2|3|4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|1D|8|@$E|1E|F|1F|G|H]|$E|1G|F|1H|G|H]]|9|@]|A|$]]|$1|I|3|J|5|D|7|1I|8|@$E|1J|F|1K|G|H]]|9|@]|A|$]]|$1|K|3|L|5|D|7|1L|8|@]|9|@]|A|$]]|$1|M|3|N|5|O|7|1M|8|@]|9|@]|A|$]]|$1|P|3|Q|5|O|7|1N|8|@]|9|@]|A|$]]|$1|R|3|S|5|O|7|1O|8|@]|9|@]|A|$]]|$1|T|3|U|5|D|7|1P|8|@]|9|@]|A|$]]|$1|V|3|W|5|D|7|1Q|8|@]|9|@]|A|$]]|$1|X|3|Y|5|D|7|1R|8|@$E|1S|F|1T|G|H]]|9|@]|A|$]]|$1|Z|3|10|5|D|7|1U|8|@$E|1V|F|1W|G|H]]|9|@]|A|$]]|$1|11|3|12|5|13|7|1X|8|@]|9|@]|A|$14|15]]|$1|16|3|17|5|D|7|1Y|8|@$E|1Z|F|20|G|H]]|9|@]|A|$]]|$1|18|3|19|5|D|7|21|8|@$E|22|F|23|G|H]|$E|24|F|25|G|H]|$E|26|F|27|G|H]]|9|@]|A|$]]|$1|1A|3|-4|5|D|7|28|8|@]|9|@]|A|$]]]|1B|$]]

<blockquote>
 So we have some characters that are in 'grey' zone and can be but don't have to be encoded.
</blockquote>

All characters can be encoded. <code>http://stackoverflow.com/questions</code> and <code>http://stackoverflow.com/%71%75%65%73%74%69%6F%6E%73</code> are both identical.

The only time a character cannot be encoded, is if it is being used in a way that has a special meaning with URIs, such as the <code>/</code> separating path elements.

The only time a character must be encoded, if:

<ol>
<li>It is one of those special-meaning characters, and not being used with that special meaning.</li>
<li>It is one of the reserved characters that may have a special meaning in a particular URI scheme or particular place.</li>
<li>It has a code point about U+007F.</li>
</ol>

There are exceptions to the last two though.

In the third case if you use a IRI then you don't encode such characters, which is pretty much the definition of an IRI. You can convert between IRI and URI by doing or undoing that encoding. (Any such characters in the host portion must be punycode encoded though, not URI-encoded).

In the second case it's safe to not encode the character if it isn't used as a delimiter in the context in question. So for example, <code>&amp;</code> can be left as it is in some URIs but not in HTTP URIs where it is often used as a separator for query data. This though depends upon having particular knowledge of the particular URI scheme. It's also probably just not worth the risk of some other process not realising it's okay.

<code>!</code> is an example of this. RFC 3986 includes the production:

<pre><code>reserved = gen-delims / sub-delims

gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"

sub-delims = "!" / "$" / "&amp;" / "'" / "(" / ")"
 / "*" / "+" / "," / ";" / "="
</code></pre>

And so <code>!</code> is in the set of characters that can be safe to leave unencoded or not, depending on the scheme in use.

Generally, if you're writing your own encoding code (such as when writing a <code>HttpEncoder</code> implementation) you're probably better off just always encoding <code>!</code>, but if you're using an encoder that doesn't encode <code>!</code> all the time that's probably okay too; certainly in HTTP URIs it shouldn't make any difference.

According to <a href="http://www.w3schools.com/tags/ref_urlencode.asp">http://www.w3schools.com/tags/ref_urlencode.asp</a>
When requests get submitted they are URL encoded, so for example space gets transformed to %20. So far so good.

I have a problem with !. Submitting it in the form converts it to %21 as it should.
However <code>HttpUtility.UrlEncode</code> (or its <code>WebUtility</code> partner) or <code>Uri.EscapeDataString</code> all will return !
Is this an expected behaviour? How should I encode my input from c# so that it converts it proper values?

.NET UrlEncode not working?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

根据，当请求被提交时，它们是被URL编码的，例如，空间被转换为%20。我对此有意见！在表单中提交它将按其应有的方式将其转换为%21。然而，HttpUtility.UrlEncode (或其WebUtility合作伙伴)或Uri.EscapeDataString都将返回！这是否一种预期的行为？我应该如何从c#对输入进行编...

问.NET UrlEncode不工作？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问.NET UrlEncode不工作？EN