Request.Querystring自动url解码字符串？

Question

I'm working with a page where I have a url like:
/directory/company/manufacturer

Using some re-write rules this gets re-written

testing with /directory/company/dunkin%26donuts/

Some manufacturers have an ampersand in their name. So I thought I could just replace the ampersand with %26 . However, when I debug the code and hover over Request.QueryString it shows me {qq=company&manf=dunkin&donuts&cond=} and Request.QueryString["manf"] gives me 'dunkin'

If I use %24 ($) instead of ampersand, hovering over Request.QueryString gives me {qs=company&manf=dunkin%24donuts&cond=} and Request.QueryString["manf"] gives me 'dunkin$donuts'

I don't understand the different behavior here. Why does it seem as though the url-encoded value for an ampersand gets decoded before you actually request a specific key, but another url-encoded character, like a dollar sign, only gets decoded after you actually request that specific key?

Is this a recent change? I always thought Request.QueryString[key] returned the actual text without decoding it first. Or does it have something to do with url re-writes?

Answer 1

ASP.NET automatically calls UrlDecode() when you access a property by key index (ie ( Request.QueryString["key"] ).

If you want it encoded, just do:

HttpUtility.UrlEncode(Request.QueryString["key"]);

In terms of the ampersand specifically, that is a special case character because it is already used as a query string delimeter. URL Encoding and decoding an ampersand should always give you & for that very reason.

Answer 2

Replacing the ampersand with %26 should cause that value to be escaped, so Request.QueryString["manf"] would yield dunkin&donuts .

The asker of this similar question ended up realizing that some other code on the same page ended up pre-decoding his ampersands. Is it possible that you've got something similar happening? Perhaps some javascript is decoding the %26 into an ampersand before sending it to your server. Try using Firebug or Chrome's developer tools to see the actual URL string that is being sent from the browser.

Update

After looking at the question again, I realize that you're probably using a URL Rewriter. This post describes a similar problem, and I don't know of a solution for sure, but you may want to try double-encoding the ampersand using %2526 instead of %26 .

Answer 3

I think a solution might be to modify the UrlRewrite rule to something like.

    <rule name="TagPage" stopProcessing="true">
      <match url="^(tag)/([^/]+)/?$"/>
      <conditions logicalGrouping="MatchAll">
        <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true"/>
        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true"/>
      </conditions>
      <action type="Rewrite" url="ListByTags.aspx?tag={UrlEncode:{R:2}}"/>
    </rule>

The important line here is the {UrlEncode:{R:2}}. It solved the problem for me!