短網址會跟人撞嗎？短碼長度的數學 + 各家服務比較
短網址只有 5-7 個字元，會不會跟別人的撞到？本文解釋短碼空間數學 + 為什麼 bit.ly 用 7 字元、drrop.cc 用 6 字元的考量。
bit.ly 短碼 7 字元、drrop.cc 6 字元、tinyurl 4-6 字元、ppt.cc 看似更短 — 不同服務的短碼長度差別很大。為什麼會有差別？短碼會不會跟人撞？
本文從數學算組合空間 + 用 birthday paradox 算實際碰撞機率 + 比較各家服務的長度選擇。
短碼空間的數學
短碼用「英數字元集」生成。常見字元集：
| 字元集 | 字元數 | 範例 |
|---|---|---|
| 純數字 | 10 | 0-9 |
| 小寫英文 | 26 | a-z |
| 大寫英文 | 26 | A-Z |
| 英數混合 | 62 | a-z + A-Z + 0-9 |
| 英數混合排除易混淆 | 56-58 | 排 0/O/1/l/I 等 |
組合空間 = 字元數 ^ 長度。
不同長度組合空間表
| 字元數 / 長度 | 4 字 | 5 字 | 6 字 | 7 字 | 8 字 |
|---|---|---|---|---|---|
| 10（純數字） | 1 萬 | 10 萬 | 100 萬 | 1000 萬 | 1 億 |
| 36（純小寫英數） | 168 萬 | 6045 萬 | 21.7 億 | 783 億 | 2.8 兆 |
| 56（排除易混淆） | 982 萬 | 5.5 億 | 30.8 億 | 1727 億 | 9.6 兆 |
| 62（英數混合） | 1477 萬 | 9.16 億 | 56.8 億 | 3521 億 | 21.8 兆 |
但 birthday paradox 才是關鍵
「有多少組合」不是真正的問題 — 問題是「在 N 個短網址全部不重複，需要多大空間」。
這是 birthday paradox（生日悖論）：
- 房間裡 23 個人，有兩個人同生日的機率超過 50%
- 雖然一年 365 天，但 23² ≈ 500，已逼近 365
對短網址：
- 生成 N 個短碼隨機，有兩個撞到的機率 ≈ N² / (2 × 組合空間)
實際撞機率（用 birthday paradox 公式）
對 56 字元集 + 6 位長度（30.8 億組合）：
| 已生成短碼數 | 下一個撞機率 | 下一個撞「累積」機率 |
|---|---|---|
| 1 萬條 | 約 0.0003% | 約 0.001% |
| 10 萬條 | 約 0.003% | 約 0.16% |
| 100 萬條 | 約 0.03% | 約 14% |
| 1000 萬條 | 約 0.3% | 約 99.99% |
也就是說：
- 前 10 萬條短碼幾乎不會撞
- 超過 100 萬條開始有相對明顯的撞機率
- 1000 萬條後幾乎肯定有撞
bit.ly 號稱 17 年累積 100 億條短碼 — 但他用 7 字元 + 62 字元集（3521 億組合），仍夠用。
各服務的短碼策略
bit.ly：7 字元 base62
- 組合：62^7 = 3521 億
- 100 億條短碼下，每條撞機率約 0.014%
- 配合碰撞檢測 + 重試生成
tinyurl.com：4-6 字元變動長度
- 4 字元：62^4 = 1500 萬
- 6 字元：62^6 = 568 億
- 早期短碼短，後期自動加長
lihi.io：6-8 字元，含自訂前綴
- 隨機生成 6-8 字
- Pro 版可自訂前綴（lihi1 / lihi3 / lihi2 等變體）
myppt.cc：6 字元
- 跟 drrop.cc 一樣 6 字元
- 但字元集可能含全部 62（不排除易混淆）
drrop.cc：6 位英數混合，排除易混淆字元
- 字元集：56 個（排除
0, O, 1, l, I, i） - 組合：56^6 = 30.8 億
- 已實作碰撞檢測 + 重試 5 次
為什麼 drrop.cc 選 6 字元 + 56 字元集
設計考量：
① 視覺易讀
排除 0/O、1/l/I/i — user 手打不容易錯。實體分享場景（口頭、紙條、PDF screenshot）特別重要。
② 30.8 億組合對 PVH 規模夠用
PVH 預期前 5 年內生成 < 10 萬條短碼（副業規模）。撞機率遠 < 0.01%。
如果未來爆量（> 100 萬條），考慮升 7 字元（56^7 = 1727 億）。
③ 不分大小寫
6 位 case-sensitive 字元，user 看到 aBc 跟 abc 是不同短碼。但 56 字元集仍含大小寫 — 保持空間大、user 視覺仍區分。
④ 短到能口頭分享
電話裡跟人說「drrop.cc 斜線 a-b-c-d-e-f」剛剛好，再加幾位就難記。
碰撞處理：drrop.cc 的實作
伺服器端遇到碰撞時：
1. 隨機生成 6 字元短碼
2. INSERT into D1 → UNIQUE constraint 抓碰撞
3. 抓到 → 換新短碼，retry 最多 5 次
4. 5 次都撞 → 回 error: 'code_collision' (極罕見)
在 30 億空間 + 不超過 100 萬條的階段，retry 1 次即解的機率 > 99.99%。
對「猜短碼攻擊」的考量
攻擊者可能暴力枚舉短碼，找有效的（譬如想找私密內容的網址）。
對 56^6 = 30 億組合：
- 假設攻擊者每秒嘗試 1000 次（被 rate limit 擋）
- 全空間掃完 = 30 億 / 1000 = 300 萬秒 ≈ 35 天 / 一個 IP
drrop.cc 配 rate limit 5/min/IP + Turnstile，單一攻擊者實務上掃不完。
加上：
- 私密內容用密碼保護 — 即便短碼被猜中，密碼錯誤仍進不去
- referrer 鎖 — 限制只允許特定來源
- 過期自動刪 — 短時間窗口
層層保護下，「猜短碼」不是現實風險。
FAQ
Q：兩個人在不同時間建短網址，會不會生成同一個短碼？ A：理論上可能（birthday paradox），但 drrop.cc 在 INSERT 時用 UNIQUE constraint 抓碰撞 + 重試 5 次。實際上 user 不會遇到「跟別人同短碼」狀況。
Q：6 位短碼夠用嗎？ A：對 PVH 規模（< 10 萬條）夠用 1000 倍。如果未來變 bit.ly 規模（100 億條） → 升 7-8 位短碼。
Q：可以自訂 drrop.cc 短碼嗎？
A：目前不行（隨機生成）。考量：自訂短碼會被搶（譬如 user 想用 meet1 已被搶走）+ vanity URL 容易被 abuse（譬如 paypal 短碼釣魚）。
Q：短碼會不會被 reverse engineering？
A：drrop.cc 短碼用 crypto.getRandomValues() 真隨機生成，不是 sequential ID。不能從 short code 推算其他 short code。
Q：drrop.cc 的短碼字元集真的排除 0/O 嗎？
A：對。常數 LINK_CODE_ALPHABET 是 'abcdefghjkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ23456789'（56 字元，排 0/O/1/l/I/i）。
最後
短網址不會「莫名跟人撞」 — 各服務都有 UNIQUE constraint + 碰撞重試機制。
短碼長度的選擇 = 可生成數量 + 視覺記憶度 + 抗暴力枚舉的平衡：
- bit.ly 100 億條 → 必須 7 字 + 62 字元集
- drrop.cc 100 萬條規模 → 6 字 + 56 字元集（排易混淆字元）剛好
數字背後是設計哲學的選擇。
→ 試試 drrop.cc 的 6 位短碼：drrop.cc