什么是有效的,什么不在URI查询中？

Question

背景(问题进一步向下)

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

所以我想我们只是投票给"最好的"答案就是这样,或者？

基本上它归结为这个.

3.4.查询组件

查询组件是要由资源解释的信息字符串.

query = *uric

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

让我感到困惑的第一件事就是*uric就是这样定义的

uric = reserved | unreserved | escaped

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

然而,有些段落澄清了这一点

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

"保留"集中的字符不会在所有上下文中保留.实际上在任何给定URI组件中保留的字符集由该组件定义.通常,如果URI的语义在其转义为US-ASCII编码时被替换,则保留字符.

最后一段摘录感觉有些倒退,但它清楚地说明保留的字符集取决于上下文.然而,3.4声明所有保留字符都在查询组件中保留,但是,这里唯一会改变语义的是逃避问号(？),因为URI没有定义查询字符串的概念.

在这一点上,我完全放弃了RFC,但发现RFC 1738特别有趣.

HTTP URL采用以下形式:

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

在<path>和<searchpart>组件中,"/",";","？" 保留.可以在HTTP内使用"/"字符来指定分层结构.

我至少对RFC 1738取代RFC 2396的HTTP URL进行了解释.因为URI查询没有查询字符串的概念,所以对reserved的解释实际上并不允许我定义查询字符串,因为我习惯了现在做.

题

当我想将一个数字列表与另一个资源的请求一起传递时,这一切都开始了.我没有想太多,只是将它作为逗号分隔值传递给它.令我惊讶的是,逗号被逃脱了.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=3

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

我没有看到这与csv方法有很大不同,因为当我要求"a"时,我得到一个带逗号的字符串.ASP.NET肯定不是一个参考实现,但它还没有让我失望.

但最重要的是 - 我的第三个问题 - 这是针对此的规范？你会做什么或者那件事不是吗？

Answer 1

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

通用URI的当前标准是RFC 3986,它有这样的说法:

2.2.保留字符

URI包括由"保留"集中的字符分隔的组件和子组件.这些字符称为"保留",因为它们可能(或可能不)通过通用语法,每种特定于方案的语法或URI的解除引用算法的特定于实现的语法定义为分隔符.如果URI组件的数据与保留字符作为分隔符 [强调添加] 的目的冲突,则冲突数据必须在形成URI之前进行百分比编码.

   reserved    = gen-delims / sub-delims

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

   sub-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节中关于保留字符的注释是在百分比编码时改变语义的注释,一般只适用; 字符可以进行百分比编码而不改变特定方案的语义,但仍然保留.

Answer 2

为了回答查询字符串中的有效内容,我在发出请求时检查了哪些特殊字符被chrome替换:

Space -> %20
! -> !
" -> %22
# -> removed, marks the end of the query string
% -> %
& -> &
' -> %27
( -> (
) -> )
* -> *
+ -> + (this usually means blank when received at the server, so encode if necessary)
, -> ,
- -> -
. -> .
/ -> /
: -> :
; -> ;
< -> %3C
= -> =
> -> %3E
? -> ?
@ -> @
[ -> [
\ -> \
] -> ]
^ -> ^
_ -> _
` -> `
{ -> {
| -> |
} -> }
~ -> ~

Extended ASCII (like °) -> Every character from this set is encoded

注意:这可能并不意味着当您为链接生成URI时,不应该转义未被替换的字符.例如,~由于兼容性问题,通常建议不要在URI中使用,但它仍然是有效字符.

另一个例子是加号,它是有效的,但当服务器作为请求的一部分接收时,通常将其视为编码空白.因此,当它的目的是表示加号而不是空格时,它应该被编码即使有效.

因此,要回答应该编码的内容:无效的字符和字符,您希望按字面意思处理,但具有特殊含义或可能在服务器端造成麻烦.

Answer 3

只是用 ?q=1+2+3

我在这里回答第四个问题:)没有问但是所有问题都开始于:我如何传递数字列表a-la逗号分隔值？在我看来,最好的方法就是将它们以空格分隔的方式传递给它们,其中空格将被url-form编码+.工作得很好,只要你知道列表中的值不包含空格(数字往往不包​​含).

Answer 4

？page.html中Q = 1; Q = 2; q = 3的

这是一个有效的URL吗？

是.将;被保留,而不是由一个RFC.定义此组件的上下文是application/x-www-form-urlencoded媒体类型的定义,它是HTML标准的一部分(第17.13.4.1节).特别是B.2.2节中隐藏的偷偷摸摸的音符:

我们建议HTTP服务器实现者,特别是CGI实现者支持使用";" 代替"&"来节省作者以这种方式逃避"&"字符的麻烦.

不幸的是,许多流行的服务器端脚本框架(包括ASP.NET)都不支持这种用法.