标准 UUID 很长，您无法通过双击选择整个内容。
例如 123e4567-e89b-12d3-a456-426655440000
我喜欢较短的 ID。
我喜欢能够双击一个 ID 来选择它。
我的问题是：将标准 ID 编码为 22(ish) 个字符长的 base62 字母数字字符串是否有任何问题？
例如 71jbvv7LfRKYp19gtRLtkn
编辑：添加上下文
我们的需求是在 NoSQL 数据存储服务（如 DynamoDB）中存储一般数据。碰撞不应该发生，但我的理解是与 UUID 的碰撞风险可以忽略不计。标准 UUID 将满足我们的需求，所以我要问的是......在 base62 中编码是否存在标准 UUID 不存在的任何差异、额外风险或不可预见的问题？
谢谢。
我认为这是一个好主意，我自己正在强烈考虑将其用于我当前的项目。
\n\n但仅用于外部表示，不用于内部存储。
\n\n事实上，UUID 本质上只是 128 位整数，或者是 16 字节或 128 位的数组。
\n\n为了高效的数据库存储，它们应该以二进制形式存储（例如MySQL中的BINARY(16)列）。它将节省空间（通常文本表示为 16 字节 vs 36 字节，或者 Base62 为 22 字节），并且在查询或索引时执行速度更快（字符串 don\xe2\x80\x99t 的排序速度与数字一样快，因为它们依赖于排序规则）。
\n\n规范表示是十六进制编码，采用 8-4-4-4-12 分组，基于每组字节的语义（这在大多数情况下我们不关心）。
\n\n但这只是一个约定，根本不适合人类。因此，我认为不同的编码（例如 Base62）是完全可以接受的，可以暴露在人类交互发生的地方（例如在 URL 中），或者用于基于文本的接口或存储系统（例如 HTTP API，或 CSV/ 中的文件存储）。 JSON/XML...）。
\n\n在内部，您的应用程序应该以二进制形式使用它们。我不了解 PHP，但例如 Java 有java.util.UUID类。
对于 Java，还有一个非常好的库，可以非常轻松地在原始 UUID 和 Base62 文本表示之间进行转换：
\n\nhttps://github.com/Devkiller/friend-id
\n\n有关 UUID 的更多信息：
\n\n\nBase62 不像 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/