什么是有效的，什么不在 URI 查询中? [英] What's valid and what's not in a URI query?

问题描述

背景(进一步的问题)

我一直在谷歌搜索这个来回阅读RFC和SO问题试图破解这个问题，但我仍然没有杰克.

所以我想我们只是投票给最好的"回答就这样，或者?

基本上归结为这个.

<块引用>

3.4.查询组件

查询组件是由资源解释的一串信息.

query = *uric

在查询组件中，字符;"、/"、?"、:"、@"、&"、=、"、+"、、"和$"保留.

首先让我难以置信的是 *uric 是这样定义的

<块引用>

uric = 保留 |毫无保留 |转义

reserved = ";";|/";|?"|:"|@"|&"|="|+"|$"|","

然而，这在一些段落中得到了澄清，例如

<块引用>

保留"上面的语法类指的是在 URI 中允许但在通用 URI 语法的特定组件中可能不允许的那些字符；它们用作第 3 节中描述的组件的分隔符.

保留"中的字符set 并非在所有上下文中都保留.在任何给定 URI 组件中实际保留的字符集由该组件定义.通常，如果 URI 的语义发生变化，并且该字符被其转义的 US-ASCII 编码替换，则该字符将被保留.

最后一段摘录感觉有点倒退，但它明确指出保留字符集取决于上下文.然而 3.4 声明所有保留字符都在查询组件中保留，然而，这里唯一会改变语义的是转义问号 (?)，因为 URI 没有定义查询字符串的概念.

此时我已经完全放弃了 RFC，但发现 RFC 1738 特别有趣.

<块引用>

HTTP URL 采用以下形式:

http://:/?

在<路径>内和<搜索部分>组件，/"，;"，?"被保留./"字符可以在 HTTP 中用于指定层次结构.

我至少在 RFC 1738 取代 RFC 2396 的 HTTP URL 方面解释了这一点.因为 URI 查询没有查询字符串的概念，所以保留的解释也不允许我像我一样定义查询字符串我现在习惯了.

问题

这一切都始于我想将一个数字列表与另一个资源的请求一起传递.我没有多想，只是将它作为逗号分隔值传递.令我惊讶的是，虽然逗号被转义了.查询 page.html?q=1,2,3 编码变成了 page.html?q=1%2C2%2C3 它有效，但它很丑，没有期待吧.那是我开始浏览 RFC 的时候.

我的第一个问题很简单，编码逗号真的有必要吗?

我的回答，根据 RFC 2396:是的，根据 RFC 1738:否

后来我找到了有关在请求之间传递列表的相关帖子.csv 方法很糟糕.这反而出现了(以前没见过).

page.html?q=1;q=2;q=3

我的第二个问题，这是一个有效的 URL 吗?

我的回答，根据 RFC 2396:不，根据 RFC 1738:不(; 被保留)

我在传递 csv 时没有任何问题，只要它是数字，但是是的，如果突然需要逗号用于其他用途，您确实会遇到必须来回编码和解码值的风险.无论如何，我在 ASP.NET 中尝试了分号查询字符串，但结果不是我所期望的.

Default.aspx?a=1;a=2&b=1&a=3Request.QueryString["a"] = "1;a=2,3";Request.QueryString["b"] = "1";

当我要求a"时，我看不出这与 csv 方法有多大不同.我得到一个带逗号的字符串.ASP.NET 当然不是参考实现，但它并没有让我失望.

但最重要的是——我的第三个问题——规范在哪里?你会做什么或不做什么?

解决方案

在通用 URL 组件中保留的字符并不意味着当它出现在组件中或组件中的数据中时必须对其进行转义.该字符还必须在通用或特定于方案的语法中定义为分隔符，并且该字符的外观必须在数据中.

通用 URI 的当前标准是 RFC 3986，它是这样说的:><块引用>

2.2.保留字符

URI 包括由保留"集中的字符分隔的组件和子组件.这些字符被称为保留"，因为它们可能(或可能不会)被通用语法、每个方案特定的语法或 URI 解引用算法的实现特定的语法定义为定界符.如果 URI 组件的数据与作为分隔符的保留字符的用途相冲突 [强调]，那么必须在形成 URI 之前对冲突的数据进行百分比编码.

 保留 = gen-delims/sub-delimsgen-delims = ":"/"/"/"?"/"#"/"["/"]"/"@"子delims =！"/"$"/"&"/"'"/"("/")"/"*"/"+"/","/";"/"="

3.3.路径组件

[...]

pchar = unreserved/pct-encoded/sub-delims/":"/"@"

[...]

3.4 查询组件

[...]

 query = *( pchar/"/"/"?" )

因此，在查询字符串中明确允许使用逗号，并且仅当特定方案将其定义为分隔符时才需要在数据中转义.HTTP 方案不使用逗号或分号作为查询字符串中的分隔符，因此不需要对它们进行转义.浏览器是否遵循这个标准是另一回事.

使用 CSV 应该适用于字符串数据，您只需要遵循标准的 CSV 约定并引用数据或使用反斜杠转义逗号.

至于 RFC 2396，它还允许在 HTTP 查询字符串中使用未转义的逗号:

<块引用>

2.2.保留字符

许多 URI 包括由某些组成或分隔的组件特殊的角色.这些字符被称为保留"，因为它们在 URI 组件中的使用仅限于它们的保留目的.如果 URI 组件的数据与保留目的，那么冲突的数据必须在之前被转义形成 URI.

由于逗号在 HTTP 方案下没有保留用途，因此它们不必在数据中进行转义.§ 2.3 中关于保留字符的注释是那些在百分比编码时改变语义的字符，仅适用于一般情况；字符可以在不改变特定方案的语义的情况下进行百分比编码，但仍然保留.

Background (question further down)

I've been Googling this back and forth reading RFCs and SO questions trying to crack this, but I still don't got jack.

So I guess we just vote for the "best" answer and that's it, or?

Basically it boils down to this.

3.4. Query Component

The query component is a string of information to be interpreted by the resource.

query = *uric

Within a query component, the characters ";", "/", "?", ":", "@", "&", "=", "+", ",", and "$" are reserved.

The first thing that boggles me is that *uric is defined like this

uric = reserved | unreserved | escaped

reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","

This is however somewhat clarified by paragraphs such as

The "reserved" syntax class above refers to those characters that are allowed within a URI, but which may not be allowed within a particular component of the generic URI syntax; they are used as delimiters of the components described in Section 3.

Characters in the "reserved" set are not reserved in all contexts. The set of characters actually reserved within any given URI component is defined by that component. In general, a character is reserved if the semantics of the URI changes if the character is replaced with its escaped US-ASCII encoding.

This last excerpt feels somewhat backwards, but it clearly states that the reserved character set depends on context. Yet 3.4 states that all the reserved characters are reserved within a query component, however, the only things that would change the semantics here is escaping the question mark (?) as URIs do not define the concept of a query string.

At this point I've given up on the RFCs entirely but found RFC 1738 particularly interesting.

An HTTP URL takes the form:

http://<host>:<port>/<path>?<searchpart>

Within the <path> and <searchpart> components, "/", ";", "?" are reserved. The "/" character may be used within HTTP to designate a hierarchical structure.

I interpret this at least with regards to HTTP URLs that RFC 1738 supersedes RFC 2396. Because the URI query has no notion of a query string also the interpretation of reserved doesn't really let allow me to define query strings as I'm used to doing by now.

Question

This all started when I wanted to pass a list of numbers together with the request of another resource. I didn't think much of it, and just passed it as a comma separated values. To my surprise though the comma was escaped. The query page.html?q=1,2,3 encoded turned into page.html?q=1%2C2%2C3 it works, but it's ugly and didn't expect it. That's when I started going through RFCs.

My first question is simply, is encoding commas really necessary?

My answer, according to RFC 2396: yes, according to RFC 1738: no

Later I found related posts regarding the passing of lists between requests. Where the csv approach was poised as bad. This showed up instead, (haven't seen this before).

page.html?q=1;q=2;q=3

My second question, is this a valid URL?

My answer, according to RFC 2396: no, according to RFC 1738: no (; is reserved)

I don't have any issues with passing csv as long as it's numbers, but yes you do run into the risk of having to encode and decode values back and forth if the comma suddenly is needed for something else. Anyway I tried the semi-colon query string thing with ASP.NET and the result was not what I expected.

Default.aspx?a=1;a=2&b=1&a=3

Request.QueryString["a"] = "1;a=2,3"
Request.QueryString["b"] = "1"

I fail to see how this greatly differs from a csv approach as when I ask for "a" I get a string with commas in it. ASP.NET certainly is not a reference implementation but it hasn't let me down yet.

But most importantly -- my third question -- where is specification for this? and what would you do or for that matter not do?

解决方案

That a character is reserved within a generic URL component doesn't mean it must be escaped when it appears within the component or within data in the component. The character must also be defined as a delimiter within the generic or scheme-specific syntax and the appearance of the character must be within data.

The current standard for generic URIs is RFC 3986, which has this to say:

2.2. Reserved Characters

URIs include components and subcomponents that are delimited by characters in the "reserved" set. These characters are called "reserved" because they may (or may not) be defined as delimiters by the generic syntax, by each scheme-specific syntax, or by the implementation-specific syntax of a URI's dereferencing algorithm. If data for a URI component would conflict with a reserved character's purpose as a delimiter [emphasis added], then the conflicting data must be percent-encoded before the URI is formed.

   reserved    = gen-delims / sub-delims

   gen-delims  = ":" / "/" / "?" / "#" / "[" / "]" / "@"

   sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
               / "*" / "+" / "," / ";" / "="

3.3. Path Component

[...]

pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

[...]

3.4 Query Component

[...]

      query       = *( pchar / "/" / "?" )

Thus commas are explicitly allowed within query strings and only need to be escaped in data if specific schemes define it as a delimiter. The HTTP scheme doesn't use the comma or semi-colon as a delimiter in query strings, so they don't need to be escaped. Whether browsers follow this standard is another matter.

Using CSV should work fine for string data, you just have to follow standard CSV conventions and either quote data or escape the commas with backslashes.

As for RFC 2396, it also allows for unescaped commas in HTTP query strings:

2.2. Reserved Characters

Many URI include components consisting of or delimited by, certain special characters. These characters are called "reserved", since their usage within the URI component is limited to their reserved purpose. If the data for a URI component would conflict with the reserved purpose, then the conflicting data must be escaped before forming the URI.

Since commas don't have a reserved purpose under the HTTP scheme, they don't have to be escaped in data. The note from § 2.3 about reserved characters being those that change semantics when percent-encoded applies only generally; characters may be percent-encoded without changing semantics for specific schemes and yet still be reserved.

这篇关于什么是有效的，什么不在 URI 查询中?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！