NSURL 的参数字符串与使用“';'”的混淆VS '&'
我想使用 -[NSURL parameterString] 解析出我传递的 URL 的参数。它说 URL 必须符合 RFC 1808 但现在想知道我们的是否符合？！？我们使用类似：
http://server/path/query?property1=value1&property2=value2
，但 RFC 1808 从未提及与符号 (&) 作为有效的参数分隔符（至少是我读的方式）。它建议使用分号 (;)。也许是因为它是 1995 年起草的？ & 是否取代了 ;？如果是这样，有人验证 NSURL 的parameterString 是否也会用 & 进行解析。作为分隔符？
在我们挖一个大洞之前，“正确”的方法是什么？
I'd like to use -[NSURL parameterString] to parse out the parameters of a URL I've been passed. It says URL must conform to RFC 1808 but now wondering if ours do?!? We use something like:
http://server/path/query?property1=value1&property2=value2
but RFC 1808 never mentions the ampersand (&) as a valid parameter separator (at least the way I read it). It suggests the semicolon (;). Perhaps because it was drafted in 1995? Has the & replaced the ;? If so anyone verify if NSURL's parameterString will also parse with & as delimiter?
What's the "right" way before we dig a big a hole?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
根据 RFC 1808（2.1. URL 语法组件），正确的语法如下：
它表示查询信息的格式按照 RFC 1738 第 3.3 节的格式，该节告诉我们：
“在路径和搜索部分组件内，“/”、“;”， “？”保留。
对我来说，上面的内容是说，在您的 URL 中，路径（到您的 CGI）是 :
，查询是 :
，其中不包含任何保留字符。所以你没问题。事实上使用“&”这里查询字符串中的分隔符源自 CGI 规范，而不是 URL RFC：
“表单数据是由 & 字符分隔的名称=值对的流。”
According to RFC 1808 (2.1. URL Syntactic Components) correct syntax is as follows :
It says query information is formatted as per Section 3.3 of RFC 1738 which tells us :
"Within the path and searchpart components, "/", ";", "?" are reserved."
To me the above says that in your URL the path (to your CGI) is :
and the query is :
Which does not contain any reserved characters. So you are OK. In fact the use of the "&" as a separator in the query string here derives from the CGI specification and not the URL RFC :
"Form data is a stream of name=value pairs separated by the & character."
RFC1808 没有定义查询字符串的内部格式。我相信 1808 正在讨论的分号内容是不同类型的附加信息（在路径上），实际上从未使用过。
据我所知， NSURL 接口不包含任何处理解析/分割查询字符串本身内容的方法，因此该类对此不感兴趣，而且您的 URL 确实符合 1808 标准。
实际上，查询字符串本身并不具有任何 RFC 定义的格式；您可以完美地将任何字符串放入其中并在服务器端原封不动地检索它们。然而，HTML 标准描述了一种从表单内容创建查询字符串的方法，并且大多数服务器端脚本都使用这种
application/x-www-form-urlencoded格式。根据 HTML4 第 17.13.4.1 节，
&是浏览器必须用来从多个参数创建查询字符串的参数分隔符，所以是的，您必须支持 & 符号作为参数分隔符。 HTML4 建议服务器端脚本接受分号作为查询字符串中与号的替代分隔符，因为这样可以避免更多转义。但它并不需要它，而且实际上（不幸的是）许多服务器/表单读取环境不接受分号用于此目的。RFC1808 doesn't define the internal format of the query string. I believe the semicolon stuff 1808 is talking about is additional information of a different sort (on paths), which is in practice never used.
As far as I can see, the NSURL interface does not include any methods that deal with parsing/splitting the contents of the query string itself, so this is of no interest to the class, and indeed your URL is 1808-compliant.
Actually query strings don't inherently have any RFC-defined format; you can perfectly well put any string in them and retrieve them untouched at the server side. However the HTML standard describes a way of creating query strings from form contents, and this
application/x-www-form-urlencodedformat is used by most server-side scripts.According to HTML4 section 17.13.4.1,
&is the parameter separator browsers must use to create query strings from multiple parameters, so yes, you must support the ampersand as a parameter separator. HTML4 recommends that server-side scripts should accept the semicolon as an alternative separator to the ampersand in query strings, as that avoids more escaping. But it doesn't require it, and indeed (unfortunately) many server/form-reading environments do not accept the semicolon for this purpose.