根据 id 生成唯一可反转短字符串（防止用户 id 等暴露), 用 hashids 稳妥不？

[kkk212]

https://hashids.org/ Hashids is a small open-source library that generates short, unique, non-sequential ids from numbers.

It converts numbers like 347 into strings like “ yr8 ”, or array of numbers like [27, 986] into “ 3kTMd ”.

You can also decode those ids back. This is useful in bundling several parameters into one or simply using them as short UIDs.

比如字符串长度设置 4-6 位，等用户量大了接近 4-6 位字符能表示的用户量时, 会不会出现重复的。

[xenme]

个人以为加盐后，hashid 足够满足你要求了。
默认 hashid 基本是 base62,6 位的话，最多可以表示 56800235584，超过 500 亿，你用户量也不可能更多了。

[xenme]

@woodensail 前面也说了，安全性要求并不是特别高的话，可以考虑 hashid，毕竟即使黑进后台了，也就知道个用户量而已或者用户真正的 ID，并不能怎么样。而且，即使用更安全的算法，能进来看到算法和 salt 的人，估计你的安全算法的密钥也暴露了。
@kkk212 这个 id 的 hash 应该是你在用户注册之后，在后台生成后返回给前台用来代替 user id 的。所以，对应的算法以及 salt 是只有后台人员才知道的。你并不需要在前台编解码，所以并没有暴露出来。

[kkk212]

@jedrek 就是用一个短的字符串代替用户 id 来显示, 不能解密也不会暴露真实的 id。目前用的方案是，生成好一个存储 6 位字符串记录的表(插入 2000 万记录), 创建新用户的时候查出来对应 id 的字符串，存到用户表里。但是用户多了，存储字符串的表查询就会慢了，并且这样得定期维护字符串表，感觉费事。

[jedrek]

@kkk212 我有第一个问题: 真实用户 ID 一定不能暴露吗? 可否说说担忧的原因?

[kkk212]

@jedrek 用户主页开放的话，比如防止按照用户 id，爬用户信息。

[jedrek]

@jedrek 这个好解决, 用户 ID 不是连续自增的就可以了, 参考 instagram 的 ID 策略

[lawler]

用户 ID + 任意固定整数 -> 转 32 进制。

例如 用户 id 1
固定整数 987412312

10 进制值是 987412313
显示 id 是 tdldqp

不定期更新任意固定整数。

[chinvo]

@lawler #27 为了避免重复，你只能增大这个参数而不能减小，而且还需要一个专门的字段保存过去的 ID 对应的字符串

[lawler]

@chinvo 不需要啊。出站入站时反转 userid，换句话说，明天别人拿这个 id 访问这个页面的时候，就是别人的数据了。这个值不入库的。参数只要不是负值，任意值都没问题。

[zhengxiaowai]

@kkk212 https://github.com/zhengxiaowai/shortuuid

看看这个，实测百万无重复

[chinvo]

@lawler #29 你得考虑持久化 URL 的问题，被检索的 URL、印刷的二维码和其他物料

[chinvo]

我厂用 ksuid

[kkk212]

@chinvo ksuid 位数长呀

[arthasgxy]

好奇请教一下楼上各位，我司有类似的，只不过是纯数字，不知道是不是与你们同样的目的。
每个用户，3、4 个 xxid，都是纯数字，有的长，有的短，一直不知道搞这么多有什么特别的意义？

[chinvo]

@arthasgxy #34 大概是历史遗留问题，不同子系统甚至不同表里面用的 ID 不同

[chinvo]

@kkk212 #33 emm，确实长了点

[chinvo]

@kkk212 #33 snowflake 呢？或者自己实现类 ksuid，把 payload 从 128bit 减到 64bit

[arthasgxy]

@chinvo 感谢回复。
感觉上应该跟历史没啥关系。新项目，也是这样搞的。

[agdhole]

转成 int 32/64? steam 是这么做的,不过很长