是否有可能在.NET中使用所有相同的字符生成GUID？（例如：{11111111-1111-1111-1111-111111111111}）

我們在我們的數據庫設計中廣泛使用GUID; Business Object屬性爲DB空值提供Guid.Empty GUID，如果值爲Guid.Empty，則null始終保存到數據庫。是否有可能在.NET中使用所有相同的字符生成GUID？（例如：{11111111-1111-1111-1111-111111111111}）

除了Guid.Empty（00000000-0000-0000-0000-000000000000）可能性有多大，一個GUID將與所有相同的字符ê產生。 g .: 11111111-1111-1111-1111-111111111111

只是考慮對這些特定值使用GUID。

來源

2010-01-28 Mark Redman

不太可能：d – 2010-01-28 15:25:44

+25

儘管它的瘋狂不太可能的，肯定有一個更好的設計不僅僅是使用的GUID的幻數？ – 2010-01-28 15:27:04

+19

在工作中，一個人得到了一次重複的GUID;他絕不會在彩票中獲勝，因爲他已經度過了所有的幸運 – 2010-01-28 15:30:36

簡而言之：對於GUID根據公佈的標準和規範它根本無法發生產生。一個GUID有一個結構，一些領域實際上有一個含義。更重要的是，.NET生成版本4的GUID，它絕對不會發生。它們的定義方式不會有這樣的GUID。詳情請參閱下文;-)

有5到7位是這裏的主要陷阱。這些是版本標識符（第三部分的前四位）和變體字段，指定了這是什麼變體的GUID。

當前版本可以是1到5之間的任何值。因此，唯一有效的十六進制數字的，我們可以得到在這一點這樣的GUID是 - 很明顯 - 1至5

讓我們來剖析versions一點：

MAC地址和時間戳。兩者都可能很難哄進全部1位數字。
MAC地址和時間戳以及用戶標識。與v1相同。
MD5散列。可能甚至可能工作。
PRNG。永遠不能工作，因爲第四部分的第一個數字是總是無論是8，9，A或B。這與版本號的4矛盾。
SHA-1散列。可能甚至可能工作。

到目前爲止，我們排除了第4版是不可能的，因爲其他人不大可能。讓我們看看變體字段。

的variant field指定向後兼容性某些位模式（x是不在乎），即：

0 x x Reserved. NCS backward compatibility. 
1 0 x The only pattern that currently can appear 
1 1 0 Reserved, Microsoft Corporation backward compatibility 
1 1 1 Reserved for future definition.

由於該圖案是在所述第四部分的一開始，這意味着最重要的位始終設置爲第四部分的第一個十六進制數字。這意味着這個非常數字永遠不可能是1,2,3或5。當然，不包括已經生成的GUID。但那些MSB設置爲0的人恰好是v1或v2。這些時間戳的一部分意味着他們將來必須產生一些千禧年才能解決問題。

來源

2010-01-28 15:32:16 Joey

這是最正確的。例如。如果你使用的是System.Guid，那麼這是不可能的，因爲第13個「半字節」總是4，而第17個總是8,9，A或者B – Nick 2010-01-28 15:36:19

但是，他不只是特別要求「全部1」GUID，他只是以此爲例。這聽起來好像他可能會使用全X引導來區分不同的具體值。這並不是說這個論證真的不那麼有效。 – Kevin 2010-01-28 15:53:51

@Kevin：重寫從零開始。假設根據規範生成的GUID迄今爲止不可能發生。 – Joey 2010-01-28 15:59:43

與其他任意隨機生成的GUID會發生碰撞的可能性很大。所以，極不可能。

雖然，您可能需要重新考慮使用guid來「存儲」類似的數據。它們實際上用於唯一標識對象和組件。

來源

2010-01-28 15:27:17 Kevin

+1「重新考慮使用guid」，考慮使用enum而不是 – 2010-01-28 15:34:44

-1來表示隨機生成的guid可能會發生相同的碰撞 - 生成GUID以便2個GUID不可能發生碰撞，除非在愚蠢的情況下，例如兩臺機器使用相同的MAC地址在同一時間生成GUID。 – Justin 2010-01-28 15:52:41

Kragen，我想你誤解了我的觀點。任何隨機GUID都不可能被重複，所以我指出兩個隨機生成的GUID匹配的概率（除了Johannes提到的具體情況之外）沒有區別，並且隨機引導和11111111-1111 -1111-1111-111111111111將匹配。 – Kevin 2010-01-28 15:59:27

非常非常低。 GUID格式包括識別該方案的幾個比特。如果你自己「生成」它們，那麼GUID方案很可能是錯誤的。

來源

2010-01-28 15:28:20 MSalters

-1

它和其他Guid一樣可能。
如果您將其插入到數據庫中（即使有一些特殊意義），那麼您也可以通過適當的約束來確保它是唯一的。

來源

2010-01-28 15:28:25

約1 5,316,911,983,139,663,491,615,228,241,121,400,000

因此，我認爲你是安全的。

來源：http://msdn.microsoft.com/en-us/library/aa446557.aspx

來源

2010-01-28 15:28:37 Duncan

+36

「所以你說有機會？」 - 電影報價，不由自己 – Martin 2010-01-28 15:30:47

阿呆和Dumber – Erix 2010-01-28 15:35:15

+11

-1 - 來源說，有那麼多的GUID組合，但GUID不只是隨機數，所以這與給定的GUID的概率不一樣現有。 – Justin 2010-01-28 15:55:47

GUID的通常使用的算法，而不是十六進制字符一個真正隨機串中產生。如果您可以確定使用什麼算法來生成它們，則可以確定要用作「幻數」的GUID是否與生成的GUID相沖突。

Wikipedia page on GUIDs有關於使用的算法的大量信息，以便能夠給你一個明確的答案。或者，在.net框架中的Guid.NewGuid（）方法上運行Reflector，但基於查看reference source for the method，這會調用CoCreateGuid in OLE32。

來源

2010-01-28 15:30:22 Rob

爲什麼要使用專門設計的GUID？除了可識別的方面，爲什麼不使用正確生成的GUID呢？（你知道這將是唯一的，那就是點）

來源

2010-01-28 15:32:16 Guvante