选择Go中的URL编码标准的方法是什么？

大家好，今天本人给大家带来文章《选择Go中的URL编码标准的方法是什么？》，文中内容主要涉及到，如果你对Golang方面的知识点感兴趣，那就请各位朋友继续看下去吧~希望能真正帮到你们，谢谢！

我有一个 go 客户端，它正在与遵循 rfc 1738 url 编码规则的服务器进行通信。 rfc 1738 此后已被 rfc 3986 更新（取代），go 似乎正在使用 rfc 3986，至少在 v1.17.7 中是这样。

s := "blue+~light blue"
s = url.queryescape(s)
fmt.println(s) // blue%2b~light+blue

在 rfc 1738 中，~ 是保留（“不安全”）字符，应编码为 %7e，而在 rfc 3986 中则无需编码 ~。这只是两个 rfc 之间的一个区别，可能还有其他一些我还没有研究过，这就是为什么用 %7e 替换 ~ 的天真的方法不是我想要走的路。

我可以让 go 创建一个“rfc 1738 兼容”编码的 url 吗？如果没有，是否有第三方库可以做到这一点，也许可以通过接受 rfc 编号参数？ time 已经这样做了：

t.Format(time.RFC822)
t.Format(time.RFC850)
t.Format(time.RFC1123)
t.Format(time.RFC3339)

正确答案

~ 未保留。它在 URI 中没有特殊含义。

1738中的保留字符是：“;” | “/”| “？” | “：” | “@” | “&”| ”=。 3986中的保留字符有：“:”/“/”/“?” /“#”/“[”/“]”/“@”/“！” / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" /“=”。 3986保留集包含1738保留集的所有字符。这是一个超集。

Unsafe 是不同的，RFC 3986 出于充分的理由摆脱了 unsafe。

RFC 1738 使字符“不安全”，因为它们可能对于其他编码具有特殊含义。

这在 1994 年可能是有意义的，当时事情更加宽松，URL 被期望可以自由地嵌入文本中，但在 2022 年，“已知网关和其他传输代理有时会修改此类字符”早已被提出不再使用。

现在，人们有责任使用文本进行自己的转义，因此 RFC 3986 删除了不安全字符。 RFC 的工作不是猜测其他编码可能使用什么特殊字符。使用您的 URI 的事物有责任根据其规则对其进行转义和编码。如果他们不这样做，那就是一个错误，并且可能对他们来说是一个安全问题。

由于~没有保留；即使您遇到 17 年前的 3986 之前的代码，它也会将 URL 中的 %7E 和 ~ 读取为 ~。

如果 ~ 对它有特殊含义并且它不进行自己的转义，那么它在许多其他方面可能会非常损坏和不安全。它也可能会因为 UTF-8 而卡住。

今天关于《选择Go中的URL编码标准的方法是什么？》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！