如何为在线资源生成唯一的文本 ID

发布于 2024-09-16 11:02:03 字数 863 浏览 2 评论 0原文

我想生成一个唯一的 ID,该 ID 将在 URL 中用于标识特定资源。原则上它与pastebin.com等相同。

id 和资源不是很秘密,但我希望它是这样,这样你就不能递减 id,然后获取另一个用户资源。我正在考虑使用 CHAR(8),它在 URL 中看起来不错,而且仍然足够大以减少猜测的机会。但我如何生成这个呢?对于 INT,您可以使用 auto_incrementprimary key 来确保唯一性。

但是,如果我按顺序执行以下操作

  1. 在我的应用程序中生成 CHAR(8)
  2. 确保该 ID 不存在。
  3. 如果不存在,则存储,否则转到 1。

我必须将 2. 和 3. 包装在原子事务中。

但还有更好的办法吗?或者我不应该关心检查(2.),因为冲突不会经常发生。如果有帮助的话,我使用 MySql 和 .Net (C#)。是否有可能以某种方式“加密”一个自动递增的 int 作为文本 ID,并以精确的 8(或 10)个字符再次解密它。

我已阅读数据库 ID 需要一个较小的 GUID 替代方案,但 URL 仍然是唯一且随机的,这很有用,但 MySql 不支持使用 GUID(据我所知)。但对线程中的 LongToShortCode 方法的质量发表评论也将受到赞赏。

注意:资源不能更改,只能查看。

此致, 拉塞

I want to generate a unique id which will be used in URLs to identify a specific resource. In principle it is the same as pastebin.com etc. does.

The id and resource is not very secret but I want it to be so you just can't decrement a id and then get another users resource. I´m thinking of a CHAR(8) which will look nice in a URL and still be large enough to reduce the chance of guesses. But how do I generate this? For an INT, you can use auto_increment and primary key to insure the uniqueness.

But if I do the following in order

  1. Generate a CHAR(8) in my application
  2. Insure that this ID doesn't exists.
  3. If it not exists, store, else goto 1.

I have to wrap 2. and 3. in a atomic transaction.

But is there a better way? or shouldn't I care about the the check (2.) because a clash doesn't occur regularly. I use MySql and .Net (C#) if that helps. Is it possible to somehow 'encrypt' a auto-incremented int as the text-id and decrypt it again in precisely 8 (or 10) characters.

I have read Need a smaller alternative to GUID for DB ID but still unique and random for URL which was useful, but the use of GUID is not supported in MySql (as far as I know). But a comment on the quality of the LongToShortCode method in the thread would also be appreciated.

Note: the resources can't be changed, only viewed.

Best regards,
Lasse

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

拥抱没勇气 2024-09-23 11:02:03

MySql 实现了 UUID。这似乎是一个具有不同名称的 GUID。所以您仍然可以使用该选项。

如果您仍打算使用 char(8),那么您确实需要担心 ID 的唯一性,因为如果您正在查看提供的 URL,您可能不知道已发生违规直到人们开始报告问题。

MySql implements the UUID. Which appears to be a GUID with a different name. So that option is still available for you.

If you are still going to use char(8), then you do need to worry about uniqueness of your ID, simply because if you're looking at served URLs, you may not know a violation has occurred until people start reporting problems.

硬不硬你别怂 2024-09-23 11:02:03

您可以使用 int 身份,然后在使用它之前对其进行加密/解密,但这在重负载下可能不是最好的主意。

You could use an int identity and then encrypt/decrypt it before using it, probably not the best idea under heavy load though.

兲鉂ぱ嘚淚 2024-09-23 11:02:03

伪原子地做到这一点的简单方法是

  1. 生成随机字符串
  2. ,存储该字符串(实际上是保留它),
  3. 检查是否存在另一个字符串
  4. ,如果存在另一个字符串,则删除刚刚创建的字符串,然后返回到步骤 1

碰撞仍然可能发生,但是当他们这样做时,会导致两个线程再次尝试,在这种情况下这不是问题。

编辑:我建议为您的生成函数采用加密哈希或其他内容的前几个字符,但这并不重要。

The easyish way of doing that pseudo-atomically is to

  1. generate the random string
  2. store the string (in effect reserving it)
  3. check if another one exists
  4. if another one exists, remove the one you just made, and return to step 1

Collisions can still happen, but when they do it causes both threads to try again, which in this case isn't a problem.

EDIT: I would suggest taking the first few characters of a cryptographic hash or something for your generation function, but it doesn't really matter.

伤感在游骋 2024-09-23 11:02:03

我想我会这样做:
8 个字符的文本 ID 最多可以存储 64^8 = 2^48 个数字。

然后,我将使用两列:

  • ID,INT 2^32 自动递增
  • Rand,INT 2^16

然后,当我添加一行时,我将生成一个随机的 2^16 整数并将其放入新行中。然后简单地根据两个数字的组合生成文本 ID。检索很简单,只需将其拆分并在数据库中进行简单查找即可。可笑的简单解决方案,应该消除行冲突并且足够随机(2^16)以减少猜测。

对此方法的反馈将不胜感激。

I think I'll do it like this:
A 8 character text id can store a number up to 64^8 = 2^48.

I will then use two columns:

  • ID, INT 2^32 auto-increment
  • Rand, INT 2^16

Then, when I add a row, I will generate a random 2^16 integer and put it in a new row. The text id is then simply generated from from the two numbers combined. And retrieval is easy two - just splitting it up and a simple lookup in the database. Ridiculous simple solution which should eliminate row clashes and be random enough (2^16) to reduce guesses.

Feedback on this approach will be appreciated.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文