Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

兼容各种 URL 参数形式

  前端页面接收参数通常都是通过 URL 传递的,但是 URL 中除了 QueryString 还有 Hash。虽然 Hash 最初的设计只是为了锚点定位,但后来被人们用作单页跳转后逐渐颠覆了它原来的功能。我觉得前端程序处理页面 URL 参数时应该同时处理 QueryString 和 Hash。
  前段时间我就纠结过单页应用到底使用什么作为 URL 。最终的结论是 URL Path 和 URL QueryString 都无法共享 HTTP 缓存,只有使用 URL Hash 才可以,所以推荐走前端路由的单页应用使用 URL Hash。
  但是在实践中,并不是所有程序都会通过 URL Hash 来跳到自己的页面。比如第三方授权之类的业务就需要页面跳转到第三方,然后再跳回来,并且在 URL 中插入新的参数。也就是说,当 URL 涉及到与第三方传参时,第三方未必会使用我们需要的 URL Hash 方式传参,可能依然是 QueryString。所以在程序中应该同时解析 QueryString 和 URL Hash。
  如果只是同时处理 QueryString 和 URL Hash 其实并没有什么问题。然而有时候第三方的程序是比较傻逼的,比如传一个带 Hash 的 URL 作为回调地址,第三方程序会直接在后面接一个问号,然后 key=value。完全无视原有的 Hash,直接强行加上 QueryString。所以在处理这类 URL 时我们还需要加上一些防呆处理,比如将所有「#」、「?」、「&」这些字符采取统一的处理方式,把第三方那傻逼的 URL 拼接也给兼容上。
  虽然这并不规范,但是大环境是这样的,我们有什么办法呢?
网名:
3.80.55.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^