将 UUID 转换为短代码是否安全？（仅使用前 8 个字符）答案

【问题标题】：Is it safe to turn a UUID into a short code? (only use first 8 chars)将 UUID 转换为短代码是否安全？（仅使用前 8 个字符）
【发布时间】：2010-12-30 16:01:54
【问题描述】：

我们使用 UUID 作为 db 中的主键（由 php 生成，存储在 mysql 中）。问题是，当有人想要编辑某些东西或查看他们的个人资料时，他们在 url 的末尾有一个巨大的、可怕的、丑陋的 uuid 字符串。（编辑？id=.....）

如果我们只使用前 8 个字符，即第一个连字符之前的所有字符，是否安全（阅读：仍然是唯一的）？

如果它不安全，是否有某种方法可以将其转换为更短的内容以便在 url 中使用，可以将其转换回十六进制以用作查找？我知道我可以对其进行 base64 编码以将其减少到 22 个字符，但还有更短的吗？

编辑我读过this question，它说使用base64。再说一遍，还有更短的吗？

【问题讨论】：

您是否希望 UUID 的前 8 个字符以外的所有字符都是多余的？他们在那里使它独一无二。无论哪种方式，如果它是 8 个字符而不是 22 个字符，您真的认为这会带来更友好的用户体验吗？我不会花时间担心这个。我在地址栏中看到过更疯狂的 URI，它当然不会影响网站的可用性。
我在想类似于如何缩短 md5 哈希值（在某处读过但不记得在哪里），因为字符对于某个子字符串具有均匀分布。
我明白了。加密散列函数预计具有可接受的冲突发生水平，截断输出字符串只会增加这种机会。您的情况不能承受任何“冲突”的机会（一个 id 指向多个记录）。

标签： php algorithm base64 uuid

【解决方案1】：

缩短 UUID 会增加发生冲突的可能性。你可以这样做，但这是个坏主意。仅使用 8 个字符意味着只有 4 个字节的数据，因此一旦您拥有大约 2^16 个 ID，您就会预期会发生冲突 - 远非理想。

您最好的选择是获取 UUID 的原始字节（不是十六进制表示）并使用 base64 对其进行编码。或者，不要太担心，因为我严重怀疑您的用户是否关心 URL 中的内容。

【讨论】：

FWIW 由于生日悖论，您预计会在 2^16 条记录之前发生碰撞
记录通常是 4 字节 = 32 位，所以它是 2^32 而不是 2^16

【解决方案2】：

不要从该 UUID 中删除任何一点：您无法控制生成它的算法，有多种可能的实现，算法实现可能会发生变化（例如：随着您的 PHP 版本而变化使用）

如果你问我地址栏中的 UUID 看起来一点也不可怕或困难，即使是简单的谷歌搜索“UUID”也会产生看起来最糟糕的 URL，而且每个人都习惯于查看谷歌 URL！

如果您想要更好看的 URL，请查看此 stackoverflow.com 文章的地址栏。他们使用的是文章 ID，后跟问题的标题。只有ID部分是相关的，其他的都是为了让读者容易看（去试试吧，你可以删除ID后面的任何东西，你可以用垃圾替换它——没关系）。

【讨论】：

【解决方案3】：

截断 uuid 是不安全的。此外，它们被设计为全球唯一的，所以你不会有运气缩短它们。您最好的选择是为每个用户分配一个唯一编号，或者让用户选择一个可以解码的自定义（唯一）字符串（如用户名或昵称）。因此，您可以使用 edit?id=.... 或 edit?name=blah ，然后将 name 解码为脚本中的 uuid。

【讨论】：

选择自定义名称会起作用，但它并不总是在编辑用户配置文件。可能是用户创建的东西，除了 uuid 之外没有任何独特的东西（想想相册）。

【解决方案4】：

这取决于您生成 UUID 的方式 - 如果您使用 PHP 的 uniqid，那么最右边的数字更“独特”。但是，如果您要截断数据，则无法真正保证它是唯一的。

不管怎样，我想说这是一种不太理想的方法 - 有没有办法在查询字符串中使用唯一的（并且非常有意义的）文本引用字符串而不是 ID？（如果没有对问题领域的更多了解，很难知道，但在我看来，这始终是一种更好的方法，即使 SEO 等不是一个因素。）

如果您使用这种方法，您还可以让 MySQL 生成唯一 ID，这可能是一种比尝试在 PHP 中处理这个更明智的方法。

【讨论】：

【解决方案5】：

如果您担心 URL 中的 UUID 会吓到用户，为什么不将其写到隐藏的表单字段中呢？

【讨论】：

我想在这个（裸 url）和在你正在编辑的 url 中有一些视觉提示之间找到一些妥协。最终可能会采用这种方法。