真的QueryString不区分大小写吗? [英] Is really QueryString case insensitive?
问题描述
我正在一个支付平台上工作，作为对支付的响应，对我的听众进行了一个简单的GET调用，在查询字符串中有一些参数:
I am working on a payment platform and, in response to a payment, a simple GET call, with some params in the query string, is made to my listener:
http://localhost/mytest/listener?TIMECREATED = 04.08.2015 + 12％3A22％3A27& statoattuale = OK& PREVIOUSSTATE = IN& CURRENTSTATE = payment_approved& tipomessaggio = PAYMENT_STATE& > DESCRIZIONE = CAMBIO + DI + STATO& datacreazione = 04.08.2015 + 12％3A22％3A27& 稳定器 = xxxxxx& 商家编号 = xxxxxx& descrizione = CAMBIO + DI + STATO& OBJECT =付款&TIMEGENERATED = 04.08.2015 + 12％3A23％3A17& MERCHANTNUMBER = xxxxxx& statoprecedente = IN& MERCHANTACCOUNT = xxxxxx& numeroOrdine =我的订单; numeroCommerciante = xxxxxx& datagenererazione = 04.08.2015 + 12％3A23％3A17& ORDERNUMBER = myOrderNo& Stabilimento = xxxxxx& mac = CaWJiRCxbWH％2FsNFMvHUD2A％3D％3 strong> MAC = AnsEvRHkvMwRL％2FgehVtnhA％3D％3D
http://localhost/mytest/listener?TIMECREATED=04.08.2015+12%3A22%3A27&statoattuale=OK&PREVIOUSSTATE=IN&CURRENTSTATE=payment_approved&tipomessaggio=PAYMENT_STATE&DESCRIZIONE=CAMBIO+DI+STATO&datacreazione=04.08.2015+12%3A22%3A27&stabilimento=xxxxxx&MerchantNumber=xxxxxx&descrizione=CAMBIO+DI+STATO&OBJECT=PAYMENT&TIMEGENERATED=04.08.2015+12%3A23%3A17&MERCHANTNUMBER=xxxxxx&statoprecedente=IN&MERCHANTACCOUNT=xxxxxx&numeroOrdine=myOrderNo&numeroCommerciante=xxxxxx&datagenerazione=04.08.2015+12%3A23%3A17&ORDERNUMBER=myOrderNo&Stabilimento=xxxxxx&mac=CaWJiRCxbWH%2FsNFMvHUD2A%3D%3D&MAC=AnsEvRHkvMwRL%2FgehVtnhA%3D%3D
当我检查Request.QueryString时，得到的是混乱的参数顺序和大小写.好像它们是第一次调整大小写重新排列的.像这样:
When I inspect Request.QueryString what I get is a mess of the param order and case. Seems like they are reordered with adjusted case for the first occurence. Like this:
TIMECREATED = 04.08.2015 12:22:27& statoattuale =确定&PREVIOUSSTATE = IN& CURRENTSTATE = payment_approved& tipomessaggio = PAYMENT_STATE& DESCRIZIONE = CAMBIO DI STATO& DESCRIZIONE = CAMBIO DI STATO& datacreazione = 04.08.2015 12:22:27& stabilimento = xxxxxx& stabilimento = xxxxxx& MerchantNumber = xxxxxx& MerchantNumber = xxxxxx& OBJECT = PAYMENT& TIMEGENERATED = 04.08.2015 12:23:17& statoprecedente = IN& MERCHANTACCOUNT = 999988801& numeroOrdine = myOrderNo& numeroCommerciante = xxxxxx& datagenerazione = 04.08.2015 12:23:17& ORDERNUMBER = myOrderNo& mac = CaWJiRCxbWH/sNFMvHUD2A ==& mac = AnsEvRHkvMwRL/gehVtnhA ==
TIMECREATED=04.08.2015 12:22:27&statoattuale=OK&PREVIOUSSTATE=IN&CURRENTSTATE=payment_approved&tipomessaggio=PAYMENT_STATE&DESCRIZIONE=CAMBIO DI STATO&DESCRIZIONE=CAMBIO DI STATO&datacreazione=04.08.2015 12:22:27&stabilimento=xxxxxx&stabilimento=xxxxxx&MerchantNumber=xxxxxx&MerchantNumber=xxxxxx&OBJECT=PAYMENT&TIMEGENERATED=04.08.2015 12:23:17&statoprecedente=IN&MERCHANTACCOUNT=999988801&numeroOrdine=myOrderNo&numeroCommerciante=xxxxxx&datagenerazione=04.08.2015 12:23:17&ORDERNUMBER=myOrderNo&mac=CaWJiRCxbWH/sNFMvHUD2A==&mac=AnsEvRHkvMwRL/gehVtnhA==
在我看来，这似乎是个错误，因为RFC3986规定:
To me it looks like a bug, becasue the RFC3986 states:
当URI使用通用语法的组件时，该组件 语法等效规则始终适用；即，该计划和 主机不区分大小写，因此应标准化为 小写.例如，URI是 等效于 http://www.example.com/.其他通用语法 除非特别说明，否则假定组件区分大小写 由方案另行定义(请参阅第6.2.3节).
When a URI uses components of the generic syntax, the component syntax equivalence rules always apply; namely, that the scheme and host are case-insensitive and therefore should be normalized to lowercase. For example, the URI is equivalent to http://www.example.com/. The other generic syntax components are assumed to be case-sensitive unless specifically defined otherwise by the scheme (see Section 6.2.3).
此刻，我通过手动解析Url.Query解决了我的问题，但我仍然不认为Request.QueryString的行为是正确的.
At the moment I solved my problem by manually parsing Url.Query, but I still do not think that how behave Request.QueryString is correct.
有人可以阐明这件事吗?
Can someone shed some light on the matter?
推荐答案
不幸的是，API并未提供使Request.QueryString集合区分大小写(或Request.Headers或Request.Form集合)的方法.问题).
Unfortunately, the API doesn't provide a way to make the Request.QueryString collection case sensitive (or the Request.Headers or Request.Form collections, for that matter).
但是，通过反射进行一些逆向工程，并不难做到.
However, with a bit of reverse engineering via reflection, it is not that difficult to do.
public class CaseSensitiveQueryStringCollection : System.Collections.Specialized.NameValueCollection
{
public CaseSensitiveQueryStringCollection(string queryString, bool urlencoded, System.Text.Encoding encoding)
// This makes it case sensitive, the default is StringComparer.OrdinalIgnoreCase
: base(StringComparer.Ordinal)
{
if (queryString.StartsWith("?"))
{
queryString = queryString.Substring(1);
}
this.FillFromString(queryString, urlencoded, encoding);
}
internal void FillFromString(string s, bool urlencoded, System.Text.Encoding encoding)
{
int num = (s != null) ? s.Length : 0;
for (int i = 0; i < num; i++)
{
int startIndex = i;
int num4 = -1;
while (i < num)
{
char ch = s[i];
if (ch == '=')
{
if (num4 < 0)
{
num4 = i;
}
}
else if (ch == '&')
{
break;
}
i++;
}
string str = null;
string str2 = null;
if (num4 >= 0)
{
str = s.Substring(startIndex, num4 - startIndex);
str2 = s.Substring(num4 + 1, (i - num4) - 1);
}
else
{
str2 = s.Substring(startIndex, i - startIndex);
}
if (urlencoded)
{
base.Add(HttpUtility.UrlDecode(str, encoding), HttpUtility.UrlDecode(str2, encoding));
}
else
{
base.Add(str, str2);
}
if ((i == (num - 1)) && (s[i] == '&'))
{
base.Add(null, string.Empty);
}
}
}
}
用法
var query = new CaseSensitiveQueryStringCollection(
HttpContext.Current.Request.Url.Query,
true,
System.Text.Encoding.UTF8);
使用?MAC=123&mac=456之类的查询字符串时，您会发现它们是分开的.
When you use a querystring like ?MAC=123&mac=456, you can see they are kept separate.
这篇关于真的QueryString不区分大小写吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
