logo标签列表

使用base62（字母数字）UUID有问题吗？

uuidbase62
11

标准的UUID过长，无法通过双击选择整个ID。

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

我喜欢更短的ID。

我希望能够双击一个ID进行选择。

我的问题是：将标准的ID编码为长度约为22个字符的base62字母数字字符串是否存在任何问题？

例如：71jbvv7LfRKYp19gtRLtkn

编辑：添加上下文
我们需要在NoSQL数据存储服务（如DynamoDB）中进行一般数据存储。不应该发生冲突，但我了解到UUID的冲突风险是可以忽略不计的。标准的UUID适合我们的需求，所以我的问题是...使用base62编码是否存在任何差异、额外风险或未预见的问题，而这些问题在标准的UUID中不存在？

谢谢。

7
请记住，UUID 是一个128位的值，而不是字符串。我们使用字符串来向人类显示 UUID。规范的文本表示法是一个由四个连字符分隔的十六进制数，共32 + 4 = 36个字符。但只要发送方和接收方都能理解并且可以获取这128位，就可以生成任何你想要的文本表示法。如 dabest1 所提到的，你也可以省略连字符，因为它们只是使十六进制对于人更易读和识别成 UUID 而已。 - Basil Bourque
2
请注意，一些数据库（例如Postgres）本身支持UUID作为数据类型，可以高效地仅存储底层值的128位而不是字符串。 - Basil Bourque
谢谢，Basil。这就是我在寻找的信息 :) - JeremyTM
使用本地的16字节数据类型（如果可用）还有一个优点，就是搜索时没有“大小写不敏感”的问题。 - martinstoeckli
我们正在处理一个应用程序，它存储Guid的36个字符表示，并且在某些数据库（如Oracle）中，默认的字符串比较是区分大小写的。这可能会使编写正确的Sql查询变得困难。 - martinstoeckli
显示剩余3条评论
3个回答
6

我认为这是一个好主意，我正在考虑在我的当前项目中使用。但仅适用于外部表示，不适用于内部存储。

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

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

规范化的表示是十六进制编码，采用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的更多信息：

3
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的相同冲突可忽略性。 - JeremyTM
3
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接