生成短URL的代码与算法：截断哈希摘要的安全性及碰撞问题

Hey，我来帮你拆解短URL生成里的这几个关键问题——我之前做过不少短链接服务的架构设计，刚好能给你一些实用的见解：

1. 编码前截断哈希摘要是否安全？ #

这里的“安全”得分两个维度看：

• 哈希碰撞风险：截断确实会提升理论上的碰撞概率，但只要你选择的哈希算法足够健壮（比如SHA-256而非MD5），并且截断后的长度能覆盖你的业务规模，风险完全可控。比如6字符的base62编码对应约560亿种可能，这个量级足够支撑绝大多数中小规模的短链接服务。
• 原URL保密性：截断不会影响哈希的不可逆性，攻击者无法通过截断后的摘要还原出原URL，这一点上是安全的。

2. URL安全编码是否有必要？ #

非常有必要，核心原因有两个：

• 提升字符利用率：标准哈希的十六进制输出（0-9a-f）只有16种字符可选，而用URL安全的字符集（比如base62：0-9a-zA-Z，共62种），相同长度的摘要能映射出多得多的可能组合。比如同样6个字符，十六进制只能提供16^{6≈1677万种组合，而`base62`能提供62}6≈560亿种，差距巨大。
• 符合URL规范：哈希原始输出可能包含URL不允许的特殊字符（比如base64的+和/），必须转成URL安全的字符（比如替换成-和_），才能保证短链接在所有浏览器和平台上正常访问。

3. 仅使用截断后的摘要是否存在碰撞风险？ #

存在，但在实际业务场景中几乎可以忽略。
碰撞概率主要由两个因素决定：哈希算法的抗碰撞能力，以及截断后的摘要长度。以SHA-256为例，即使截断到前40位（对应6个base62字符），根据生日悖论，要达到50%的碰撞概率，需要生成约2^20（约100万）个短链接——这对大多数服务来说是远超过日常规模的。

如果想要彻底规避碰撞风险，可以加一层校验逻辑：生成截断后的短标识后，先查询数据库是否已有相同的标识；如果存在，就给原URL拼接一个随机字符串（比如原URL?rand=xxx），重新哈希生成新的短标识即可。

内容的提问来源于stack exchange，提问作者Integralist