-1

我们正在为我们的网站构建 URL 缩短功能。

我们目前提出的内容：

  • 我们获取一个 URL ( http://www.google.com ) 并对其进行 sha1 处理，最终得到一个 40 个字符的哈希 (738ddf35b3a85a7a6ba7b232bd3d5f1e4d284ad1)。
  • 我们获取 sha1 哈希并将其编码为 base62（基本上是 AZ、az、0-9）并最终得到一个 28 个字符的哈希（jNMYchEoche67ro1k5gsCcHfDzmR），我们可以将其解码回原始 sha1。

我们使用 sha1 的原因是确保用户无法从当前/过去的 URL 中猜测下一个 URL。

我们使用 base62 的原因是为了使 URL 对用户有效且可读。

现在，将附加到我们的域 ( http://www.google.com/r/jNMYchEoche67ro1k5gsCcHfDzmRis ) 的 28 个字符的“短 URL”有点太长了，尤其是考虑到 Twitter 的字符限制时。

我们目前正在考虑将 sha1 减少大约 20 个字符，这将产生一个 14 个字符的短 url，但如果再减少，我们担心我们会很快遇到冲突。

我们还考虑过将大数字（或字符串）压缩为小值，但这需要我们将 28 或 14 个字符的散列分成 2 部分并对这些部分进行排序，我们不知道如何从那里返回原始散列。

有人知道我们能做什么吗？我们更喜欢不依赖数据库来构建 URL 的解决方案，但如果需要数据库，请记住我们仅限于 Redis / MongoDB（这意味着没有自动增量整数字段）。

4

1 回答 1

0

我不确定我是否了解您的所有要求，但这就是我的想法。

减少 sha1 似乎是正确的方法。

如果您在数据库中“注册”每个短 URL，则可以通过尝试在发生冲突时分配备用短 URL 来避免冲突（如果在您的数据库中已经找到哈希，则说明发生了冲突）。

它会像这样工作：

  1. 尝试分配一个新的哈希，尽可能多地削减 sha1，我们有 HASH1 作为结果
  2. 检查 DB 中是否有冲突，没有冲突，在 DB 中注册 HASH1 并完成
  3. 如果发生冲突，尝试分配一个新的哈希，例如通过将 sha1 减少一个字符（导致更长的哈希），我们有 HASH2 作为结果
  4. 检查碰撞..（步骤 2）等等

每次您想查找正确的长 URL 以获取哈希值时，您当然必须咨询您的数据库。我想这就是你现在已经在做的事情，因为 sha1 是不可逆转的。

您最初应该将 sha1 削减多远？我会尽可能多地说，只要您满足您的要求，即很难猜测下一个 url。我会说只留下 5 个字节的 sha1（即 40 位）将很难猜测..（如果您的数据库中有 100 万个短 URL，它仍然是百万分之一的猜测）

于 2013-01-31T16:18:38.460 回答