礼品卡代码算法

Question

I recently posted this question关于用户可以在线兑换的类似礼品卡的代金券的代码。我想在大键空间、低猜测性和人类可读性之间找到最佳权衡。现在我开始实现了，我意识到我遇到了另一个问题，更多的是算法挑战。

假设我采用某种代码格式 - 为简单起见，从 A 到 Z 假设 10 个字符，然后我开始生成凭证。执行此操作的正确算法是什么？!

我的第一种方法是从 0 到 308,915,776 对所有可能的代码进行编号，然后开始生成该范围内的随机数。但这显然有一个大问题——我必须根据所有以前生成的优惠券代码检查我的随机数，如果它与现有代码冲突，我将不得不丢弃该代码并尝试另一个。随着系统积累更多数据，它会变慢。在极端情况下，当只剩下一个代码时，系统几乎不可能正确猜出它。

我可以预先生成所有代码并打乱它们，然后按顺序使用它们。但这意味着我必须存储很多代码，事实上我的 key 空间比我描述的要大，所以我们谈论的是非常大量的数据。所以这也不太理想。

所以这让我只能按顺序使用代码。不过，我不想要可猜测的优惠券代码。购买代金券“AAAAAAAAAY”的用户如果输入“AAAAAAAAAZ”，应该不太可能获得另一个有效代码。

我可以打乱我的字母表和我的位置，而不是

我使用'ABCDEFGHIJKLMNOPQRSTUVWXYZ'

'LYFZTGKBNDRAPWEOXQHVJSUMIC'

因此代替位置

9 8 7 6 5 4 3 2 1 0位置是

1 8 0 7 5 4 3 9 2 6

使用这个逻辑，给定代码

LNWHDTECMA

下一个代码是

LNEHDTECMA

这绝对不是那么容易猜到的。但它们仍然只相差一个字符，只要给出其中两个凭证，您就会知道哪个位置在递增，并且您有 90% 的机会在 24 次或更少的猜测中获得下一个代码。

我的“逃生舱口”是抛弃所有这些并使用 GUID。它们的字符比我希望我的用户必须输入的字符多，并且包含类似的字符，如 I/1 和 O/0，但它们神奇地消除了上述所有令人头疼的问题。仍然，我很高兴思考这个问题，也许你也是。我很想听听一些替代建议。你有什么？

谢谢!

Answer 1

两个随机生成的代码发生冲突的可能性与用户猜测有效代码的可能性基本相同 - 您无法阻止用户猜测。所以你必须有一个比实际使用的代码数量大得多的 key 空间，随机冲突也极不可能发生(尽管，由于生日悖论，可能不太可能完全忽略它们，至少如果你希望你的代码相当短)，并且检查现有代码并在发生冲突时重新生成是一个完全可行的策略。