问题标签 [rfc1738]

我们只是升级到 v3.0，同时重构我们的代码。

在这样做的同时，我们注意到当使用http_build_querywhich 采用关联数组并将其转换为 RFC1738 有效 URL 时，SagePay 失败并出现以下错误：

提交到 SagePay 端点的表单的 enctype 为application/x-www-form-urlencoded.

但是...如果我们手动构建要加密的字符串，请执行以下操作：

有用...

现在，据我了解 RFC1738，如果 url 中存在 url，则应该对其进行编码，即

RFC1738：

贤者支付：

当然，如果 SagePay 遵循 RFC1738，对 URL 进行编码应该可以吗？还是因为字符串是加密的，这意味着它并不重要？

有什么想法吗？

谢谢

加文

TL;TR：查询的 URL 部分是（第一个）问号还是只是一个分隔符，后跟查询？

RFC 1738第3.3 节建议“？” （问号）不是查询字符串的一部分，而只是将其与路径分开：

RFC 3986附录 A.中的语法也表示“？” 不是实际查询字符串的一部分：

现在，让我们考虑两个 URL：

1. http://server.com/api/item.json
2. http://server.com/api/item.json?

它们是等价的还是不同的？

区分它们并用于识别两种不同的资源是否有效？

跟进我可以在 URL 中使用 at 符号 (@) 吗？

根据投票最多的答案，@不是 URL 路径中的保留字符（尽管它在主机中）。

但是，给定@路径中的一个，URL 编码的形式是否可以互换？换句话说，twitter.com/@user严格等价于twitter.com/%40user?

在实践中，它们似乎经常可以互换使用，但很好奇是否严格如此（例如AbC@gmail.com，在技术上与 不同abc@gmail.com，但几乎每个人都将它们视为相同）。

更广泛地说，什么时候需要将字符和 URL 编码版本视为相同，以及何时不同（例如，与 不同example.com/path%2Fasdf）example.com/path/asdf……</p>

今天我们和同事争论这是否是一个有效的 URL http://domain.com?some_param=1。定义 URL 结构的 RFC 没有明确声明这是无效结构。根据RFC 1738，第 3.3 部分

但是，在同一文档的第 3.1 部分末尾，它说

用 curl 检查发现了一些有趣的事情

所以，问题是

这是一个有效的 URL 吗？http://domain.com?some_param=1

RFC1738 SEC 2.2说：

因此，只有字母数字、特殊字符“$-_.+!*'()”和用于其保留目的的保留字符可以在 URL 中未编码地使用。

经过一番搜索，我总结出应该编码的字符有以下三种：

• 不安全字符：'#'、''、'"'、'%'、'<'、'>'、'{'、'}'、"|"、''、'^'、'~'、' [', ']', '`'。
• 保留字符：';'、'/'、'?'、':'、'@'、'='、'&'。
• 特殊字符："$-_.+!*'(),"

我知道为什么以及何时应该对不安全字符和保留字符进行编码。RFC1738 规定可以使用未编码的特殊字符，但我发现urllib2.quote也可以将这些特殊字符编码为"%24-_.%2B%21%2A%27%28%29%2C%7E". 所以，我有点困惑，如果特殊字符可以在 URL 中未编码使用，为什么要编码特殊字符，以及为什么它们是特殊的。

我需要使用使用 RFC 1738 进行 URL 编码的 R字符串进行解码。

这些字符串来自 PHP 请求，并使用默认使用 RFC1738http_build_query的 PHP 函数进行编码。

例如，Hello, World!变成Hello%2C+world%21。

您可以使用以下 PHP 代码轻松在线试用：

不幸的是，R 基础 URL 编码使用 RFC 3986，这是不同的！

我想"Hello, world!"回来！我怎么能用 R 做到这一点？

我很高兴将+符号替换为空格，但如果这是您的答案，请说明为什么这是正确的。到目前为止，我的研究并未表明 RFC 1738正是带有加号的 RFC 3986，我不想要奇怪的边缘情况......