将 UUID 转换为短代码安全吗？ （仅使用前 8 个字符）
我们使用 UUID 作为数据库中的主键（由 php 生成，存储在 mysql 中）。问题是，当有人想要编辑某些内容或查看他们的个人资料时，他们的 url 末尾有一个巨大、可怕、丑陋的 uuid 字符串。 (edit?id=.....)
如果我们只使用前 8 个字符（第一个连字符之前的所有字符），会安全吗？
如果它不安全，是否有某种方法可以将其转换为其他更短的内容，以便在 url 中使用，然后可以将其转换回十六进制以用作查找？我知道我可以对其进行 base64 编码，将其减少到 22 个字符，但是还有更短的吗？
编辑 我已阅读这个问题，它说使用base64。再说一遍，还有更短的吗？
We use UUIDs for our primary keys in our db (generated by php, stored in mysql). The problem is that when someone wants to edit something or view their profile, they have this huge, scary, ugly uuid string at the end of the url. (edit?id=.....)
Would it be safe (read: still unique) if we only used the first 8 characters, everything before the first hyphen?
If it is NOT safe, is there some way to translate it into something else shorter for use in the url that could be translated back into the hex to use as a lookup? I know that I can base64 encode it to bring it down to 22 characters, but is there something even shorter?
EDIT
I have read this question and it said to use base64. again, anything shorter?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
缩短 UUID 会增加发生冲突的可能性。你可以做到，但这是一个坏主意。仅使用 8 个字符意味着仅 4 个字节的数据，因此一旦您拥有大约 2^16 个 ID，您就会预料到会发生冲突 - 远非理想。
最好的选择是获取 UUID 的原始字节（不是十六进制表示形式）并使用 base64 对其进行编码。或者，不要太担心，因为我严重怀疑您的用户关心 URL 中的内容。
Shortening the UUID increases the probability of a collision. You can do it, but it's a bad idea. Using only 8 characters means just 4 bytes of data, so you'd expect a collision once you have about 2^16 IDs - far from ideal.
Your best option is to take the raw bytes of the UUID (not the hex representation) and encode it using base64. Or, just don't worry much, because I seriously doubt your users care what's in the URL.
不要从该 UUID 中删除任何一个位：您无法控制生成它的算法，有多种可能的实现，算法实现可能会发生变化（例如：随您使用的 PHP 版本而变化）
如果你问我地址栏中的 UUID 看起来一点也不可怕或困难，即使是简单的 google 搜索“UUID”也会产生看起来最糟糕的 URL，每个人都习惯查看 google URL！
如果您想要更好看的 URL，请查看这篇 stackoverflow.com 文章的地址栏。他们使用文章 ID，后跟问题标题。只有 ID 部分是相关的，其他所有内容都是为了方便读者阅读（继续尝试，您可以删除 ID 后面的任何内容，也可以用垃圾替换它 - 没关系）。
Don't cut a single bit out of that UUID: You have no control over the algorithm that produced it, there are multiple possible implementation, algorithm implementation is subject to change (example: changed with the version of PHP you're using)
If you ask me an UUID in the address bar doesn't look scary or difficult at all, even a simple google search for "UUID" produces worst looking URL's, and everybody's used to looking at google URL's!
If you want nicer looking URL's, take a look at the address bar of this stackoverflow.com article. They're using the article ID followed by the title of the question. Only the ID part is relevant, everything else is there to make it easy on the eyes of readers (go ahead and try it, you can delete anything after the ID, you can replace it with junk - doesn't matter).
截断 uuid 并不安全。此外，它们被设计为全球唯一的，因此您不会幸运地缩短它们。最好的选择是为每个用户分配一个唯一的号码，或者让用户选择一个可以解码的自定义（唯一）字符串（例如用户名或昵称）。因此，您可以使用 edit?id=.... 或 edit?name=blah，然后将 name 解码为脚本中的 uuid。
It is not safe to truncate uuid's. Also, they are designed to be globally unique, so you aren't going to have luck shortening them. Your best bet is to either assign each user a unique number, or let users pick a custom (unique) string (like a username, or nick name) that can be decoded. So you could have edit?id=.... or edit?name=blah and you then decode name into the uuid in your script.
这取决于您如何生成 UUID - 如果您使用 PHP 的 uniqid< /a> 那么最右边的数字更“独特”。但是，如果您要截断数据，则无法真正保证它是唯一的。
不管怎样，我想说这在某种程度上是一种次优的方法——有没有办法可以在查询字符串中使用唯一的（并且理想地有意义的）文本参考字符串而不是 ID ？ （如果没有对问题领域有更多的了解，很难知道，但在我看来，即使 SEO 等不是一个因素，这始终是一个更好的方法。）
如果您使用这种方法，您也可以让 MySQL 生成唯一的ID，这可能是比尝试在 PHP 中处理此问题更为明智的方法。
It depends on how you're generating the UUID - if you're using PHP's uniqid then it's the right-most digits that are more "unique". However, if you're going to truncate the data, then there's no real guarantee that it'll be unique anyway.
Irrespective, I'd say that this is a somewhat sub-optimal approach - is there no way you can use a unique (and ideally meaningful) textual reference string instead of an ID in the query string? (Hard to know without more knowledge of the problem domain, but it's always a better approach in my opinion, even if SEO, etc. isn't a factor.)
If you were using this approach, you could also let MySQL generate the unique IDs, which is probably a considerably more sane approach than attempting to handle this in PHP.
如果您担心 URL 中的 UUID 吓到用户，为什么不将其写入隐藏的表单字段呢？
If you're worried about scaring users with the UUID in the URL, why not write it out to a hidden form field instead?
老问题，但我认为应该提到的是，“短 ID”是一种常见的做法，正是为了呈现更人性化的代码，它们并不意味着完全取代完整的 ID。此外，这对于任何标识符都有效，无论是数字、UUID、SHA 还是其他标识符。
正如其他答案已经提到的，您应该始终使用完整的 UUID 作为记录的事实密钥。
短 id 的实现会根据您的需求而有很大差异，但有两件事在实现中确实很常见：
以下是一些常见的实现：
作为奖励，如果您只想显示字母代码而不是数字，您可以使用 hashids< 等库将基于数字的 id 编码为代码/a>.
Old question but I think that it should be mentioned that "short ids" are a common practice exactly to present more human-friendly codes and they're not meant to replace the full ids entirely. Also, this is valid for any identifier, be it a number, UUID, SHA, or whatever.
As other answers already mentioned, you should always use the full UUID as the de facto key for your records.
The implementation of short ids will vary greatly depending on your needs but two things are really common across implementations:
Here are some common implementations:
gitcommits are an example but they use SHA instead of UUID.As a bonus, if you just want to display lettered codes instead of numbers you can encode number-based ids as codes with libs like hashids.