为什么很多人在需要字符串 ID 的场景下使用 UUID？为什么没有普及 UUID-Slim 这种算法（我编的名字），把 UUID base32 编码一下缩短一半？
drymonfidelia · 172 天前 · 930 次点击这是一个创建于 172 天前的主题，其中的信息可能已经有所发展或是发生改变。
UUID 只能包含 0-F ，信息密度也太低了，只能表示 16^32 个值，如果能把 UUID base32 编码一下，一位能表示 32 个字符，就是 32^16 个值，数量不变，直接缩短一半了。至于为什么是 base32 ，可以自定义编码表保留 UUID 输入不用切大小写、不使用 1 I L O 这 4 个易混淆字符的特性。
UUID 做文件名的例子太多了，随便翻了下电脑，macos 自带的相册 app 文件名就都是 UUID
UUID 做文件名的例子太多了，随便翻了下电脑，macos 自带的相册 app 文件名就都是 UUID
 |
1
cover 172 天前
那为什么不用 number 存？
|
 |
2
drymonfidelia OP @cover 对随机 ID 进行加减运算没有意义，如果用自增 ID 会被人看出此类数据数量
|
|
3
drymonfidelia OP @drymonfidelia #2 会暴露数据数量给用户的意思
|
 |
4
rockyastor 172 天前
您是否在搜索 NanoId?
算是短版 UUID 了 |
|
5
drymonfidelia OP @rockyastor 看了下它用的是 base64 ，这样就失去了 UUID 输入不用切大小写、没有易混淆字符的优点，我觉得 base32 是最合适的
|
 |
6
flmn 172 天前
有更多比 uuid 更优秀的 id 方案，时间有序的
|
 |
7
neptuno 172 天前
试一下 nanoid
|
 |
8
snowolfy 172 天前
捉个虫，16^32 != 32^16 。
16^32 = (2^4)^32 = 2^128 32 ^16 = (2^5)^16 = 2^80 差别还蛮大的 |
 |
9
julyclyde 171 天前
硬盘那点钱比起背离行业保准的代价来说，根本不值一提
|
|
10
drymonfidelia OP @julyclyde 大部分文件系统都有最长路径限制，能减半的话我能多套几层
|
Select Language