字符“|”是？对 URL 参数名称有效吗？

发布于 2025-01-12 21:01:22 字数 236 浏览 1 评论 0原文

这是有效的网址吗？应该是字符“|”被包含在其中吗？当然，这可行，但我认为这不是正确的方法

https://sales-stage-api.techsg.cloud/requests/statistics?"meetingTime"|date:timeZone={"start":"2022-02-01 00:00:00 +07:00","end":"2022-02-28 23:59:00 +07:00"}

原文

Is this a valid URL? Should the character "|" be included in it?
Sure, this works but I don't think it's the right way to do it

https://sales-stage-api.techsg.cloud/requests/statistics?"meetingTime"|date:timeZone={"start":"2022-02-01 00:00:00 +07:00","end":"2022-02-28 23:59:00 +07:00"}

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

像极了他 2025-01-19 21:01:22

垂直线 (U+007C) 不应出现在a URI，因为它与 RFC-3986

query         = *( pchar / "/" / "?" )
pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
              / "*" / "+" / "," / ";" / "="

请注意，空格和大括号也是可疑的。

查询字符串中的键/值对通常表明它们是 application/x -www-form-urlencoded 表示某些信息（例如，从 HTML 表单输入控件收集的值）；因此您通常需要确保该信息的序列化与反序列化相匹配。

键和值应该使用什么拼写（序列化之前/反序列化之后）主要是本地设计问题：源服务器控制自己的资源标识符空间，因此如果它想要有一些名称，例如：

"meetingTime"|date:timeZone

那么可以吗？这是权衡——你放弃一些东西，并得到其他东西作为回报；如果你得到的东西比你放弃的东西更重要，那么你就赢了。

也就是说，我根本不知道这位设计师认为他们会得到什么回报，以抵消这种拼写惯例带来的各种痛苦。

如果没有大量支持文档，这个设计就无法通过我的审核过程。

A Vertical Line (U+007C) should never appear in the query part of a URI, because it is not consistent with the production rules defined in RFC-3986

query         = *( pchar / "/" / "?" )
pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims    = "!" / "quot; / "&" / "'" / "(" / ")"
              / "*" / "+" / "," / ";" / "="

Note that the spaces and braces are also suspect.

Key/Value pairs in the query string are normally an indication that they are an application/x-www-form-urlencoded representation of some information (for instance, values collected from HTML Form input controls); so you'll usually want to ensure that the serialization of that information matches the deserialization.

What spellings should be used for keys and values (before serialization/after deserialization) is largely a local design concern: the origin server controls its own space of resource identifiers, so if it wants to have some name like:

"meetingTime"|date:timeZone

Then that's fine? It's tradeoffs - you give up something, and get something else in return; if the thing you get is more important than the thing you are giving up, then you are winning.

That said, I haven't the foggiest idea what this designer thinks they are getting in return, that offsets the assorted miseries that this spelling convention introduces.

This is not a design that would make it through my review process without a lot of supporting documentation.

回复收藏 0 原文

~没有更多了~