压缩URL中的参数

时间:2010-01-13 12:00:27

标签: c# asp.net

我网站上的网址可能会变得很长,我的理解是网址会随着http请求一起传输。所以我的想法来压缩网址中的字符串。

从我在互联网上搜索,我找到了使用短网址的建议,然后将其链接到长网址。我更喜欢不使用此解决方案,因为我必须进行额外的数据库检查以在长网址和短网址之间进行转换。

这留下了3个选项:

  1. 哈希,我不认为这是一个选择。如果你想要一个安全的哈希算法,它会很长。
  2. 压缩url字符串,基本上让服务器在获取url参数时按下字符串。
  3. 更改网址使其不具描述性,这很糟糕,因为这会让我的开发变得更加困难(这是一个单人项目)。
  4. 考虑到那里有大量的操作系统/浏览器,我认为id好像其他人已经尝试过这个或者有一些聪明的建议。

    如果它匹配url参数可以达到100+个字符。

    示例:

    mysite.com/Reports/Ability.aspx?PlayerID=7737&GuildID=132&AbilityID=1140&EventID=1609&EncounterID=-1&ServerID=17&IsPlayer=True
    

    编辑:

    让我澄清一下,这不是打破网站。它更多地是关于我学习找到一个好的解决方案(我很清楚这是微优化,我的网站是非常快的atm)并使我的网站更快(挑战自己,成为一个更好的编码器)。

    还有一个美容问题,我个人认为比地址栏更长的URL看起来很糟糕。

9 个答案:

答案 0 :(得分:2)

您有一些冲突的要求,因为您希望缩短/压缩网址,而不会使其描述性降低。通过缩短URL的本质,您将在一定程度上使其不那么具有描述性。

据我所知,您的目标是通过少发送请求进行优化。你提到100多个字符,而不是1000+,我认为这意味着他们没有那个大?在这种情况下,我认为这是一种不必要的微观优化。

要添加以前使用POST的建议,如果您不想进行完整的网址缩短,只需缩短密钥而不是使用全名,例如:

mysite.com/Reports/Ability.aspx?pid=7737&GID=132&AID=1140&EID=1609&EnID=-1&SID=17&IsP=True

这些显然不那么具有描述性。

但就像我说的那样,你有长网址的真正问题吗?

答案 1 :(得分:1)

我不确定我理解长网址的问题是什么?一般来说我会尽量避免使用它们,但是如果有必要那么你不会依赖用户记住它,那么为什么要经历所有的压缩麻烦呢?即使URL为1000个字符(~2KB),页面请求也不会很慢。

但是,如果可能的话,我会考虑使用POST而不是GET来美化URL,但这当然取决于你的实现/环境。

答案 2 :(得分:1)

这里建议使用几次而不是GET。我强烈建议AGAINST通过URL看起来选择您的HTTP操作。这个选择比在浏览器中显示的更多。

快速概述:

http://www.w3.org/2001/tag/doc/whenToUseGet.html#checklist

答案 3 :(得分:1)

要添加到其他答案的几个选项:

  • 使用子类LinkButton进行导航。这将额外数据(例如PlayerId)保存在其视图状态中作为属性。如果您通过电子邮件向人们提供网址,这将没有多大帮助。
  • 使用MVC路由引擎生成稍微改进的URL - 没有查询字符串的键。例如mysite.com/Reports/Ability/7737/132/1140/1609/-1/17/True
  • Create your own URL shortener喜欢tinyurl.com。将URL与每个查询字符串值一起存储在数据库中以进行查找。
  • 只需为最热门的报告设置一些友好的网址,例如mysite.com/Reports/JanuaryReport。您也可以使用MVC路由引擎执行此操作。

MVC路由引擎是独立的,可以在没有您的站点成为MVC站点的情况下工作。

答案 4 :(得分:1)

使用我的方案,可以将URL的params部分编码为base64字符串,比直接base64表示短约50%。所以对于你的情况,你得到:

  • 〜更短的params部分
  • 一个基础64字符串,隐藏了很多细节

请参阅http://blog.alivate.com.au/packed-url/

答案 5 :(得分:0)

大多数浏览器可以在URL中处理2048个字符;如果您不想使用长参数列表,可以随时通过POST请求传递参数。

答案 6 :(得分:0)

扩展网址存在理论问题。确切的限制因浏览器(IE的排序版本大约为2k)和服务器(Apache中的4-8k,版本和配置不同)而有所不同,并且在我所知道的任何RFC中都没有正式指定。

我同意synhershko,如果您担心自己的网址增长太长,请使用表单POST参数替换网址。

答案 7 :(得分:0)

我过去遇到过类似的情况,虽然我的优化原因是SEO。对我来说,这取决于你对页面URL变量做了什么,它们是否被附加在所有/大多数页面上?如果他们对我来说几乎总是有一个更好的方式,虽然如果你在发展道路上很远,那么现在可能已经太晚了。

我希望能够“读取”某个网址,特别是当我在导航中深入2层或更多层的未知网站时,网站设计不佳,这通常是高级用户查找的最简单,最快捷的方式他们在网站上的位置。

如果您从SEO的角度对它感兴趣,通常最好有一个只包含以下内容的层次结构:/ - _ 搜索引擎会尝试读取网址see this video by Matt Cutts(不记得他提到的视频有多远,但无论如何它都是一块好的手表......)

答案 8 :(得分:0)

对URL的任何形式的压缩(散列,压缩,非描述性)都将:

  1. 让网址更难阅读,记住并正确输入
  2. 会对性能产生影响,因为您必须先解密/解压缩/转换网址才能使用它。
  3. 此外,哈希通常是considered to be non-reversible - 给定一个散列值,你不应该弄清楚生成它的是什么,但是你可以用它在数据库中查找一个值,这会让你回到你的第一个短期查找问题。

    您可以轻松地删除每个参数末尾的冗余“ID”,并可能删除元音或类似内容以“缩短”网址,而不会从请求的语义中丢失太多。

    但说实话,您的网址长度是性能方面最不值得关注的问题之一 - 查看您在浏览器和服务器之间来回发送的任何Cookie的大小,以及您要发回的页面大小。