Sqids – 从数字生成短唯一 ID

语言覆盖与社区模式

• 站点列出了许多语言；只有其中一部分已实现，其他只是“骨架”仓库，用来衡量兴趣并邀请贡献。
• 有些人认为这是巧妙的社区建设，也是很适合 FOSS 新手的任务；也有人起初觉得困惑，但注意到视觉提示可以区分已实现语言与占位语言。
• 有人猜测对语言徽章的点击追踪是为了优先安排移植。

与 Hashids 及其他 ID 方案的关系

• Sqids 本质上是 Hashids 的继任者/改名版本，目标相似：把整数编码成短小、适合 URL 的字符串。
• 它被拿来与 base64/base58/base36、nanoid、UUID/ULID、Crockford base32 以及各种自定义方案比较；很多人认为那些方案更简单，而且通常已经“足够好”。
• 有些人更喜欢格式保持加密或基于 Feistel 的置换，而不是用 Sqids 来隐藏顺序 ID。

脏话过滤与黑名单

• 内置黑名单引发了激烈争论。
• 主要担忧：这些名单依赖语言、并不完整，而且维护困难；默认值变动会导致编码结果随时间变化。
• 库建议提供自定义黑名单以保持输出稳定；批评者认为这种设计很脆弱，而且跨语言兼容性可能会分化。
• 另一些替代方案：选择一种让脏话不可能或不太可能出现的字母表（例如去掉元音和容易混淆的字符），而不是对生成后的字符串做过滤。

唯一性、稳定性与算法设计

• 讨论串考察了 Sqids 如何保证从整数数组到字符串的无碰撞映射，包括它在遇到坏词时如何重试而不破坏单射性。
• 一个重要细节：解码是稳定的，但如果黑名单或配置发生变化，同一组数字的编码结果可能改变；除非你强制约束，否则并不保证只有一个规范 ID。

安全性、混淆与用户 ID

• 库明确表示它不是用于安全或隐藏数据的；输出可以通过字母表反向还原。
• 一些人仍把它描述为隐藏顺序 ID 或用户数量的方法，而另一些人则称这具有误导性，或者只是“通过 obscurity 实现安全”。
• 如果要隐藏业务指标或防止 ID 枚举，评论者建议改用随机 UUID、加密 ID、Feistel 网络或其他密码学方法。

用例、实用性与替代方案

• 支持者喜欢 Sqids 带来的视觉上更短、类似“YouTube 风格”的 URL，以及跨语言互操作性。
• 持怀疑态度的人指出，对于很多应用来说，简单的 base-N 编码、slug 或 UUID 更容易、现成可用，而且避免了黑名单复杂性。
• 也有人质疑是否真的需要一个专门的库，因为许多用例其实只是“几行代码”，不过另一些人认为标准化与可移植性足以证明其合理性。