查询字符串键区分大小写吗？

小开

According to hurl.it, key will be equal to 123 and KEY, 198. They will be accessible as two different querystrings.

小开

最佳答案

The RFC for URIs says:

6.2.2.1. Case Normalization

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 HTTP://www.EXAMPLE.com/ 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).

Note that scheme ("http" here), host (server name) are case-insensitive but should be in lowercase anyway. The rest is case-sensitive unless you're using a different scheme that explicitly says it should be insensitive.

So key and KEY are different things in all http-based URIs according to the spec.

Edit: @Nicholas is partly wrong in assuming that the authority defines what it accepts, that's true for custom schemes and authorities that define their own URIs, but http is a well-defined spec that everyone conforms to (or you could have http queries that have, say, the pipe character as a delimiter. Imagine the chaos there!)

the RFC spec for HTTP says:

The scheme and host are case-insensitive and normally provided in lowercase; all other components are compared in a case-sensitive manner. Characters other than those in the "reserved" set are equivalent to their percent-encoded octets: the normal form is to not encode them (see Sections 2.1 and 2.2 of [RFC3986]).

So the query part of the URI as defined by the spec for the HTTP scheme is case-sensitive. If Microsoft has a case-insensitive parser for query strings, its not conforming to the spec. Not that I guess this level of pickiness really matters much.

小开

@gbjbaanb's answer is incorrect: The RFCs only specify the allowed character set for the query string. Like the path and fragment components of the URI, the query URI component only has meaning only to the authority providing the resource.

It is entirely up to that authority on whether this stuff is case-sensitive or not.

In the case of C# and IIS, the backing store for the parsed query string in the HttpRequest object is a System.Collections.Specialized.NameValueCollection which happens to be case-insensitive (by default).

Since that class offers other constructors allow different equality comparers to be provided, there is absolutely nothing to prevent an implementation from making it case-sensitive.

Further, since the page itself (and the client-side javascript) have access to the raw URI, they are free to do whatever they want with it.

If the query string is built as a result of an HTML form submission, the keys (names) come from the value of the form controls name attribute, which the HTML specs say is case-sensitive. But as near as I know, nobody really does that.

So, at the end of the day, you have to know what the request handler is expecting in your query string. It might (or it might not) be case-sensitive.

小开

In short, they are considered equal in many programming languages.

Different parts of the URL are different in terms of case sensitivity:

Protocol (http) -- case insensitive
Host name (example.com) -- case insensitive
Path (/folder/document.html) -- case sensitive
Query string Key(?fuzz=bar OR ?FUZZ=bar) -- case insensitive
Query string Value (?fuzz=bar&buzz=BAR) -- case sensitive