GUID可以有多短?

Greg Dean的回答是正确的,但是为了理解GUID是如何生成的以及为什么不应该缩短它,我强烈建议您阅读下面的文章。

The Old New Thing : GUIDs are globally unique, but substrings of GUIDs aren't :

这个想法是生成一个GUID并抛出 离开下半场,保持领先 前八个字节。他们想知道

不,这不是个好主意。

GUID生成算法依赖于 用于建立唯一性,如果 你扔掉一半,你就输了 独特性。

“GUID”,全局唯一ID。典型的现代“通用”GUID是为任何应用程序设计的,它们的“G”,它们的“Global”,字面上就是这样。全球的全世界。跨应用程序、跨国家、跨地域、跨一切。16字节是大量的信息。

现在,如果在您的应用程序中,您的“G”没有那么大,如果您没有期望或意图让“G”在世界意义上是全局的,而不是简单地在应用程序空间意义上是全局的,那么您可以很容易地将大小缩小到应用程序的范围。

你们公司有四个部门,永远不会有更多?2位--0,1,2,3是一个足够大的“GUID”用于此任务。显然,这是一个人为的应用程序。

在过去,我们已经了解到当我们努力解决Y2K问题时“限制比特数”的后果。因此,“位很便宜”是一个不限制GUID大小的充分理由,并且是一个“目前位太多”的错误。但是,说实话,许多应用程序只是受到限制,许多应用程序可能会生成大量数据,或者带宽受限于不需要16字节GUID的地方,使用一个GUID会影响性能和资源。

因此,请理解GUID的概念,以及它如何应用于您的应用程序。然后你可以做任何尺寸的。

Coding Horror: Equipping our ASCII Armor

在这里,他展示了如何将GUID缩短为20个可打印字符,从而保持GUID的“唯一性”。

http://betterexplained.com/articles/understanding-the-birthday-paradox/ . 作为(非常近似但有用的)经验法则,如果(在N个可能的UID中)您指定 sqrt(N) ...左右因此,一个128位的ID是非常安全的,即使是数十亿个ID,也不会发生意外冲突;但是如果你把它缩短到,比如说,32位,你会有很大的冲突风险,即使是对于几万个ID。

从技术上讲,缩短它们的效果将因生成它们所用的算法而异。考虑到您使用的API(可能)不能保证特定的版本或实现,缩短它们是个坏主意。即使是这样,这也是个坏主意。如果需要的熵小于16字节,则不应使用GUID。

有关更多信息: http://en.wikipedia.org/wiki/Globally_Unique_Identifier

简单地说,guid保证是唯一的,因为它们的行为类似于坐标。

传统上,一半是特定于机器的(通过使用MAC地址),另一半来自时间。

但是,这意味着,如果放弃GUID的任何部分,将失去唯一性的保证。Martelli先生很好地解释了为什么这是一个比你想象的更大的问题。

*