哪两个分隔符可用于 URL 锚点?
我在 URL 中使用锚点,允许人们在 Web 应用程序中为“活动页面”添加书签。 我使用锚点是因为它们很容易融入 GWT 历史机制。
我现有的实现将导航和数据信息编码到锚点中,并用“-”字符分隔。 即创建像 #location-location-key-value-key-value 这样的锚点
除了负值(如 -1)会导致严重的解析问题之外,它还有效,但现在我发现有两个分隔符会更好。 另外,考虑到负数问题,我想放弃使用“-”。
URL 锚点中还有哪些其他字符不会干扰 URL 或其 GET 参数? 这些未来的稳定性如何?
I use anchors in my URLs, allowing people to bookmark 'active pages' in a web application. I used anchors because they fit easily within the GWT history mechanism.
My existing implementation encodes navigation and data information into the anchor, separated by the '-' character. I.e. creating anchors like #location-location-key-value-key-value
Other than the fact that negative values (like -1) cause serious parsing problems, it works, but now I've found that having two separator characters would be better. Also, givin the negative number issue, I'd like to ditch using '-'.
What other characters work in a URL anchor that won't interfere with the URL or its GET params? How stable will these be in the future?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
查看 URL 的 RFC,第 3.5 节 片段标识符(其中我相信您指的是)定义为
附录 A
有趣的是,规范还规定
“允许使用字符斜杠(“/”)和问号(“?”)来表示片段标识符中的数据。”
因此,真正的锚点(如)
应该是合法的,并且非常类似于正常的 URL 查询字符串。 (快速检查验证这些至少在 chrome、firefox 和 ie 中可以正常工作)既然这样有效,我假设您可以使用您的方法来获得像
http://www.site.com/foo.html 这样的 URL? real=1¶meters=2#fake=2¶meters=3
没有问题(例如片段中的“parameters”变量不应干扰查询字符串中的变量)
您也可以必要时使用百分比编码...并且在子分隔符中定义了许多其他可用的字符。
注意:
同样来自规范:
“片段标识符组件由数字符号(“#”)字符的存在指示,并以 URI 的末尾终止。”
所以 # 之后的所有内容都是片段标识符,并且不应该干扰 GET 参数。
Looking at the RFC for URLs, section 3.5 a fragment identifier (which I believe you're referring to) is defined as
and from Appendix A
Interestingly, the spec also says that
"The characters slash ("/") and question mark ("?") are allowed to represent data within the fragment identifier."
So it appears that real anchors, like
are supposed to be legal, and is very much like the normal URL query string. (A quick check verified that these do work correctly in at least chrome, firefox and ie) Since this works, I'm assuming you can use your method to have URLs like
http://www.site.com/foo.html?real=1¶meters=2#fake=2¶meters=3
with no problem (e.g. the 'parameters' variable in the fragment shouldn't interfere with the one in the query string)
You can also use percent encoding when necessary... and there are many other characters defined in sub-delims that could be usable.
NOTE:
Also from the spec:
"A fragment identifier component is indicated by the presence of a number sign ("#") character and terminated by the end of the URI."
So everything after the # is the fragment identifier, and should not interfere with GET parameters.