Request.Querystring 会自动对字符串进行 url 解码吗? [英] does Request.Querystring automatically url decode a string?

查看:32
本文介绍了Request.Querystring 会自动对字符串进行 url 解码吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在处理一个页面,其中的 url 如下:
/目录/公司/制造商

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

使用一些重写规则,这会被重写

Using some re-write rules this gets re-written

使用/directory/company/dunkin%26donuts/进行测试

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

某些制造商的名称中带有与号.所以我想我可以用 %26 替换 & 号.但是,当我调试代码并将鼠标悬停在 Request.QueryString 上时,它会显示 {qq=company&manf=dunkin&donuts&cond=}Request.QueryString["manf"] 给了我 'dunkin'

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'

如果我使用 %24 ($) 而不是 & 符号,将鼠标悬停在 Request.QueryString 上会给我{qs=company&manf=dunkin%24donuts&cond=}Request.QueryString["manf"] 给我 'dunkin$donuts'

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'

我不明白这里的不同行为.为什么看起来好像在您实际请求特定密钥之前对&符号的 url 编码值已被解码,但另一个 url 编码字符(如美元符号)仅在您实际请求该特定密钥后才被解码?

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?

这是最近的变化吗?我一直认为 Request.QueryString[key] 没有先解码就返回了实际的文本.还是跟url重写有关系?

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?

推荐答案

%26 替换 & 号应该会导致该值被转义,所以 Request.QueryString["manf";] 将产生 dunkin&donuts.

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

这个类似问题的提问者结束了意识到同一页面上的其他一些代码最终对他的&符号进行了预解码.你有没有可能发生过类似的事情?也许某些 javascript 在将 %26 发送到您的服务器之前将其解码为&符号.尝试使用 Firebug 或 Chrome 的开发人员工具查看从浏览器发送的实际 URL 字符串.

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.

再次查看问题后,我意识到您可能正在使用 URL 重写器.这篇文章描述了一个类似的问题,我不确定有什么解决方案,但您可能想尝试使用 %2526 而不是 %26 对&符号进行双重编码.

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.

这篇关于Request.Querystring 会自动对字符串进行 url 解码吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆