URL 缩短器：最好的编码方法？答案

【问题标题】：URL shortener: best encoding method?URL 缩短器：最好的编码方法？
【发布时间】：2011-01-23 11:24:05
【问题描述】：

我正在创建一个链接缩短服务，并且我正在使用递增 ID 字段的 base64 编码/解码来创建我的网址。 ID 为“6”的 url 将是：http://mysite.com/Ng==

我还需要允许用户创建自定义 url 名称，例如 http://mysite.com/music

到目前为止，这是我的（可能是错误的）方法。帮助修复它将不胜感激。

当有人创建新链接时：

当有人创建新链接并传递自定义短 URL 时：

我的计划是 base64_decode 他们的自定义字符串并将其用作链接 ID，但我没有意识到您不能只对任何字母数字字符串进行 base64_decode 并将其转换为数字。

是否有更好的编码方法可以让我将任何数字转换为短字符串，并将任何字符串转换为数字，因此我可以通过将名称转换为数字并查询来随时查找短 url（无论是自定义的还是自动生成的）对于 ID 等于该数字的链接？

【问题讨论】：

【解决方案1】：

首先，确保在 ID 和 short_url_code 列上设置了唯一性约束。

当有人创建新链接时：

从数据库中获取下一个最大链接 ID（出于性能原因，您应该真正使用 autoincrement 或 SEQUENCE，具体取决于您的 RDBMS 提供的内容；否则继续选择MAX(ID)+1)
使用 base64_encode 或任何其他自定义或标准编码方案从 ID 生成短 URL 代码 (http://website.com/[short url name])
插入links 表：ID, short_url_code, destination_url
如果由于违反约束而导致插入失败，请返回步骤 1 尝试新的ID；您可能有违规行为，因为：
1. 相同的 ID 已被另一个线程/进程等并行使用（即插入）（如果您使用 autoincrement 或 SEQUENCE，这将不会发生，并且可能会发生通常情况下），和/或
2. 相同的short_url_code 已被用作自定义网址（这种情况很少发生，除非有人试图在您的网站上制造麻烦）
如果插入成功，提交并返回短网址给用户

当有人创建新链接并传递自定义短 URL 时：

执行与上述相同的步骤 1
不要像上面第 2 步那样从ID 生成短网址部分，而是使用用户提供的自定义short_url_code
执行与上述相同的步骤 3
如果插入失败是因为：
1. ID 上的约束违规：返回步骤 1 尝试新的 ID
2. short_url_code 上的约束违规：向用户返回错误，要求他选择不同的自定义 URL，因为他/她提供的短 URL 已被使用
执行与上述相同的步骤 5

【讨论】：

谢谢弗拉德。我应该提到我已经在处理约束违规了。我已切换到 base32，它允许我将自定义 url 转换为数字并将其作为 ID 插入。这很容易，因为我只需要将 ID 作为主键。如果自定义名称的 base32 表示存在约束冲突，它会告诉他们该名称已被使用。如果非自定义 url 存在约束冲突，它只会不断增加 ID，直到可以插入为止。这听起来像一个不错的解决方案吗？
取决于您愿意做出的权衡；大多数数据库原生 int 类型最多为 64 位（bigint 或等效类型），这意味着如果我为您提供的自定义短 URL 长度超过 64/5=12 (5=log2(32) ) 字符你将无法容纳我。不允许用户提供超过 12 个字符的自定义 URL 是否可以接受？
好点。我确实需要超过 12 个字符。怎么样：创建链接时，如果自定义名称超过 12 个字符，那么我只使用下一个最大的 ID（不包括自定义名称链接的 ID）。如果少于 12 个字符，我会在 ID 中对自定义名称进行编码。然后在通过短名称查找链接时，如果在 DB 中找不到该 ID，则表示它超过 12 个字符，那么我只需通过短名称查找。
虽然有点复杂，但这将保持递增系统（有利于保持 url 简短），并且仍然允许我利用快速选择 12 个字符以下的自定义名称。
没关系，只是决定通过链接名称（而不是 ID）查找链接并放弃整个基本编码。

【解决方案2】：

base64 可用于制作短网址，但也可以使网址变长。例如，数字 1 的 base64_encode 是 'MQ=='，它是大小的 4 倍。 Base64 将始终有 2 个字符来获得 64 位，这对于短 url 来说并不理想。

如果大小是最重要的因素，那么您也许可以依靠internationalization 生成最短的网址。

这可以使 URI 相当长（单个 Unicode 字符最多 9 个 ASCII 字符），但目的是浏览器只需要显示解码的形式，并且许多协议可以发送 UTF-8 而无需 %HH 转义.

请记住，浏览器可以很好地使用 UTF-8，而 twitter 对这些 url 没有任何问题。

【讨论】：