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

Posted 2023-02-16

【中文标题】查询字符串键是不是区分大小写？

【英文标题】：Are query string keys case sensitive?查询字符串键是否区分大小写？

【发布时间】：2014-09-02 04:36:27

【问题描述】：

假设我有一个这样的网址：

http://www.example.com?key=123&KEY=198

那会是什么结果

request.querystring("key")

and 

request.querystring("KEY")

我有点困惑。

【参考方案1】：

根据hurl.it，key 将等于123 和KEY，198。它们可以作为两个不同的查询字符串访问。

【讨论】：

如果语言更改为经典 ASP 会怎样。

@ch.smrutiranjanparida，语言选择与查询参数的处理方式无关。无论您使用 COBOL、Perl、Erlang、Classic ASP、R、Java、Lisp 都没有关系。当然，解释查询字符串的库可能存在错误，程序员可能会努力将查询字符串小写（并且不应该），但从 URI 的角度来看，如果大小写不同，它们会有所不同不同。有关详细信息，请参阅accepted answer 中的RFC。

@Abel 明白了。感谢您的输入。 :)

【参考方案2】：

The RFC for URIs 说：

6.2.2.1。案例归一化

当 URI 使用通用语法的组件时，组件语法等效规则始终适用；即，方案和主机不区分大小写，因此应标准化为小写。例如，URI HTTP://www.EXAMPLE.com/ 等价于http://www.example.com/。

除非方案另有明确定义（参见第 6.2.3 节），否则假定其他通用语法组件区分大小写。

请注意，方案（此处为“http”）、主机（服务器名称）不区分大小写，但无论如何都应该小写。其余部分区分大小写，除非您使用不同的方案明确表示它应该不区分大小写。

因此，根据规范，key 和 KEY 在所有基于 http 的 URI 中都是不同的东西。

编辑： @Nicholas 假设权威定义了它接受的部分是错误的，这对于定义自己的 URI 的自定义方案和权威来说是正确的，但是 http 是一个定义明确的规范，每个人都遵守（或者你可以有 http 查询，比如说，管道字符作为分隔符。想象一下那里的混乱！）

RFC spec for HTTP 说：

方案和主机不区分大小写，通常在 小写；所有其他组件都在区分大小写的情况下进行比较 方式。 “保留”集中的字符以外的字符是 相当于它们的百分比编码八位位组：正常形式是 不对它们进行编码（参见 [RFC3986] 的第 2.1 和 2.2 节）。

因此，由 HTTP 方案规范定义的 URI 的查询部分是区分大小写的。如果 Microsoft 有一个不区分大小写的查询字符串解析器，则它不符合规范。并不是说我认为这种挑剔程度真的很重要。

【讨论】：

请注意，这些区分大小写的部分与 HTTP 和 html 行为有关，这意味着用户代理（即浏览器）必须重复它们收到的相同大小写。服务器可以解释提交的路径以及所有查询参数名称和值，因为它看起来合适，并且不受任何规范的限制。

@MikkoRantalainen 不是这样，HTTP 规范指的是整个查询字符串。这包括诸如使用哪个字符作为分隔符以及使用什么编码系统等规范。对此进行不同解释的服务器不再使用 http 规范，而是使用自己的自定义规范，并且还可以使用不同的分隔符（例如管道）

例如，tools.ietf.org/html/rfc7231#section-4.3.1 说“考虑资源标识符很诱人 [...] 但是，在实践中没有这样的限制 [...] 只有源服务器需要知道它的每个资源标识符如何对应于一个实现 [...] GET 请求消息中的有效负载没有定义的语义”。 HTML 定义了三种编码，遵循这些编码会使用户代理更容易工作：html.spec.whatwg.org/multipage/…

现在可以使用 XHR 在 HTTP 上创建几乎自定义的实现，并使用 WebSocket 创建完全自定义的实现。只有当你想使用 relative URLs 时，你才需要注意使用斜杠或管道或任何你想用作资源标识符的字符。使用绝对 URL，浏览器不需要理解主机之后的 HTTP 或 HTTPS URL 的任何部分。除了所有内容都区分大小写。

【参考方案3】：

@gbjbaanb 的回答不正确：RFC 只为查询字符串指定了允许的字符集。与 URI 的 path 和 fragment 组件一样，query URI 组件仅对提供资源。

这东西是否区分大小写完全取决于权威。

在 C# 和 IIS 的情况下，HttpRequest 对象中已解析查询字符串的后备存储是 System.Collections.Specialized.NameValueCollection，可能不区分大小写（默认情况下）。

由于该类提供其他构造函数允许提供不同的相等比较器，因此绝对没有什么可以阻止实现使其区分大小写。

此外，由于页面本身（以及客户端 javascript）可以访问原始 URI，因此他们可以随意使用它。

如果查询字符串是作为 HTML 表单提交的结果构建的，则键（名称）来自表单控件 name 属性的值，HTML 规范说该属性区分大小写。但据我所知，没有人真正做到这一点。

因此，归根结底，您必须知道请求处理程序在您的查询字符串中期望什么。它可能（或可能不）区分大小写。

【讨论】：

我正在查看遗留 C# 代码，试图理解为什么键被视为不区分大小写，您的回答很好地解释了这一点。 +1

【参考方案4】：

简而言之，它们在许多编程语言中被认为是平等的。

URL 的不同部分在区分大小写方面是不同的：

协议 (http) -- 不区分大小写 主机名 (example.com) -- 不区分大小写 路径 (/folder/document.html) -- 区分大小写 查询字符串 Key(?fuzz=bar OR ?FUZZ=bar) -- 不区分大小写 查询字符串值 (?fuzz=bar&buzz=BAR) -- 区分大小写

【讨论】：

很多，但不是全部。最重要的是，行为不仅在语言之间存在差异，而且在不同的 Web 框架之间也存在差异。

以上忽略混合大小写 FuZz？