标准的 UUID 很长，你不能通过双击来选择整个东西。
例如123e4567-e89b-12d3-a456-426655440000
我喜欢较短的 ID。
我喜欢能够双击一个 ID 来选择它。
我的问题是：将标准 ID 编码为 22（ish）字符长的 base62 字母数字字符串是否有任何问题？
例如71jbvv7LfRKYp19gtRLtkn
编辑：添加上下文
我们需要在 NoSQL 数据存储服务（例如 DynamoDB）中进行一般数据存储。碰撞不应该发生，但我的理解是与 UUID 的碰撞风险可以忽略不计。标准 UUID 可以满足我们的需求，所以我要问的是……标准 UUID 不存在的 base62 编码是否有任何区别、额外风险或不可预见的问题？
谢谢。
我认为这是一个好主意，并且我本人强烈考虑将其用于我当前的项目。
但仅用于外部表示，不用于内部存储。
实际上，UUID 基本上只是 128 位整数，或者 16 字节或 128 位的数组。
为了高效的 DB 存储，它们应该以二进制形式存储（例如 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 的更多信息：
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/
您的问题的解决方案通常被命名为Url62，一些项目正在使用此约定。他们正在将普通的 UUID 转换为 Base62 格式。
如果您使用 Java 进行开发，请查看 FriendlyId 项目：https ://github.com/Devskiler/friendly-id