使用 base62（字母数字）UUID 有什么问题吗？答案

【问题标题】：Is there anything wrong with using base62 (Alphanumeric) UUIDs?使用 base62（字母数字）UUID 有什么问题吗？
【发布时间】：2017-03-07 21:38:05
【问题描述】：

标准的 UUID 很长，你不能通过双击来选择整个东西。

例如123e4567-e89b-12d3-a456-426655440000

我喜欢较短的 ID。

我喜欢能够双击一个 ID 来选择它。

我的问题是：将标准 ID 编码为 22(ish) 字符长的 base62 字母数字字符串是否有任何问题？

例如71jbvv7LfRKYp19gtRLtkn

编辑：添加上下文
我们的需求是 DynamoDB 等 NoSQL 数据存储服务中的通用数据存储。碰撞不应该发生，但我的理解是与 UUID 的碰撞风险可以忽略不计。标准 UUID 可以满足我们的需求，所以我要问的是……标准 UUID 不存在的 base62 编码是否存在任何差异，或者额外的风险或不可预见的问题？ p>

谢谢。

【问题讨论】：

取决于它们的用途、存储位置以及是否关心碰撞。更多上下文？
我在上面添加了上下文。
请记住，UUID 是 128 位值，不是字符串。我们使用字符串向人类显示 UUID。规范的文本表示是hexadecimal，其中散布有四个连字符，32 + 4 = 36。但是您可以生成任何您希望的文本表示，只要发送者和接收者都理解它并且可以获得 128 位。正如 dabest1 所提到的，您可以省略连字符，因为它们只会使十六进制更易于人类阅读，并且更易于识别为 UUID。
另请注意，某些数据库（例如Postgres）原生支持 UUID 作为数据类型，有效地仅存储底层值的 128 位而不是字符串。
谢谢 basil，这是我正在寻找的信息 :)

标签： uuid base62

【解决方案1】：

我认为这是一个好主意，并且我本人强烈考虑将其用于我当前的项目。

但仅用于外部表示，不用于内部存储。

确实，UUID 基本上只是 128 位整数，或者 16 字节或 128 位的数组。

为了高效的数据库存储，它们应该以二进制形式存储（例如 MySQL 中的 BINARY(16) 列）。它将节省空间（16 字节与 36 字节用于通常的文本表示，或 22 字节用于 Base62），并且在查询或索引时执行得更快（字符串的排序不如数字快，因为它们依赖于排序规则）。

规范表示是十六进制编码，基于每组字节的语义含义（在大多数情况下我们并不关心），采用 8-4-4-4-12 分组。

但这只是一种约定，根本不适合人类使用。所以我认为像 Base62 这样的不同编码是完全可以接受的，可以暴露在发生人机交互的地方（例如在 URL 中），或者用于无论如何基于文本的接口或存储系统（例如 HTTP API，或 CSV/ 中的文件存储） JSON/XML...)。

在内部，您的应用程序应该以二进制形式使用它们。我不了解 PHP，但例如 Java 有 java.util.UUID 类。

对于 Java，还有一个非常不错的库，可以非常轻松地在原始 UUID 和 Base62 文本表示之间进行转换：

https://github.com/Devskiller/friendly-id

有关 UUID 的更多信息：

【讨论】：

【解决方案2】：

Base62 不像 base-64 那样标准，但是 base-64 会有两个额外的符号，可能不允许通过双击选择整个事物。

删除破折号 (-) 怎么样？这将使它比原来的更短，并且可以通过双击鼠标轻松选择。
示例：
123e4567e89b12d3a456426655440000

更新：
base-64 有两种常见的编码：[a-zA-Z0-9/+] 和 [a-zA-Z0-9_-]。如果您选择后者，则可以解决您的选择问题。
另一方面，我认为 base-62 的使用比我最初想象的要广泛。这是一篇关于使用 base-62 主题的精彩博客：http://blog.birdhouse.org/2010/10/24/base62-urls-django/

【讨论】：

感谢您抽出宝贵时间@dabest1 - 它仍然很长。假设目标是尽可能短，并且具有与标准 UUID 相同的碰撞可忽略性。

【解决方案3】：

您的问题的解决方案通常被命名为Url62，一些项目正在使用这个约定。他们正在将普通的 UUID 转换为 Base62 格式。

如果您使用 Java 进行开发，请查看 FriendlyId 项目：https://github.com/Devskiller/friendly-id

【讨论】：