UUID的定義以及作用

UUID含義是通用唯一識別碼 (Universally Unique Identifier)，這 是一個軟件建構的標准，也是被開源軟件基金會 (Open Software Foundation, OSF) 的組織應用在分布式計算環境 (Distributed Computing Environment, DCE) 領域的重要部分。

作用：

UUID 的目的是讓分布式系統中的所有元素，都能有唯一的辨識資訊，而不需要透過中央控制端來做辨識資訊的指定。如此一來，每個人都可以建立不與其它人沖突的 UUID。在這樣的情況下，就不需考慮數據庫建立時的名稱重復問題。目前最廣泛應用的 UUID，即是微軟的 Microsoft's Globally Unique Identifiers (GUIDs)，而其他重要的應用，則有 Linux ext2/ext3 檔案系統、LUKS 加密分割區、GNOME、KDE、Mac OS X 等等。

組成：

UUID是指在一台機器上生成的數字，它保證對在同一時空中的所有機器都是唯一的。通常平台會提供生成的API。按照 開放軟件基金會(OSF)制定的標准計算，用到了以太網卡地址、納秒級時間、芯片ID碼和許多可能的數字

UUID由以下幾部分的組合：

（1）當前日期和時間，UUID的第一個部分與時間有關，如果你在生成一個UUID之后，過幾秒又生成一個UUID，則第一個部分不同，其余相同。

（2）時鍾序列。

（3）全局唯一的IEEE機器識別號，如果有網卡，從網卡MAC地址獲得，沒有網卡以其他方式獲得。

UUID的唯一缺陷在於生成的結果串會比較長。關於UUID這個標准使用最普遍的是微軟的GUID(Globals Unique Identifiers)。在ColdFusion中可以用CreateUUID()函數很簡單地生成UUID，其格式為：xxxxxxxx-xxxx- xxxx-xxxxxxxxxxxxxxxx(8-4-4-16)，其中每個 x 是 0-9 或 a-f 范圍內的一個十六進制的數字。而標准的UUID格式為：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (8-4-4-4-12)，可以從cflib 下載CreateGUID() UDF進行轉換。

 

應用：

使用UUID的好處在分布式的軟件系統中（比如：DCE/RPC, COM+,CORBA）就能體現出來，它能保證每個節點所生成的標識都不會重復，並且隨着WEB服務等整合技術的發展，UUID的優勢將更加明顯。根據使用的特定機制，UUID不僅需要保證是彼此不相同的，或者最少也是與公元3400年之前其他任何生成的通用唯一 標識符有非常大的區別。UUID最少在3000+年內不會重復。

通用唯一標識符還可以用來指向大多數的可能的物體。微軟和其他一些軟件公司都傾向使用全球唯一標識符（GUID），這也是通用唯一標識符的一種類型，可用來指向組建對象模塊對象和其他的 軟件組件。第一個通用唯一標識符是在網絡計算機系統（NCS）中創建，並且隨后成為 開放軟件基金會（OSF）的 分布式計算環境（DCE）的組件。

 

代碼：

 

C#

1 2 3 4 5 6 7 8 9 10 11

using  System; namespace  Demo{      public  class  Test      {          public  static  void  Main()          {              Guid guid=Guid.NewGuid();              Console.WriteLine(guid);          }      } }

Java

1 2 3 4 5 6 7

package  com.mytest; import  java.util.UUID; public  class  UTest {      public  static  void  main(String[] args) {          UUID uuid = UUID.randomUUID();          System.out.println(uuid); }}

Go

1 2 3 4 5 6 7 8

import (      "github.com/nu7hatch/gouuid"      "fmt" )    func main(){      fmt .Println(uuid.NewV4().String()) }

 

 

其他版本的介紹，組合在一起加深理解

什么是UUID？

UUID是Universally Unique Identifier的縮寫，它是在一定的范圍內（從特定的名字空間到全球）唯一的機器生成的標識符。UUID具有以下涵義：

• 經由一定的算法機器生成

為了保證UUID的唯一性，規范定義了包括網卡MAC地址、時間戳、名字空間（Namespace）、隨機或偽隨機數、時序等元素，以及從這些元素生成UUID的算法。UUID的復雜特性在保證了其唯一性的同時，意味着只能由計算機生成。

• 非人工指定，非人工識別

UUID是不能人工指定的，除非你冒着UUID重復的風險。UUID的復雜性決定了“一般人“不能直接從一個UUID知道哪個對象和它關聯。

• 在特定的范圍內重復的可能性極小

UUID的生成規范定義的算法主要目的就是要保證其唯一性。但這個唯一性是有限的，只在特定的范圍內才能得到保證，這和UUID的類型有關（參見UUID的版本）。

UUID是16字節128位長的數字，通常以36字節的字符串表示，示例如下：

3F2504E0-4F89-11D3-9A0C-0305E82C3301

其中的字母是16進制表示，大小寫無關。

GUID（Globally Unique Identifier）是UUID的別名；但在實際應用中，GUID通常是指微軟實現的UUID。

UUID的版本

UUID具有多個版本，每個版本的算法不同，應用范圍也不同。

首先是一個特例－－Nil UUID－－通常我們不會用到它，它是由全為0的數字組成，如下：

00000000-0000-0000-0000-000000000000

UUID Version 1：基於時間的UUID

基於時間的UUID通過計算當前時間戳、隨機數和機器MAC地址得到。由於在算法中使用了MAC地址，這個版本的UUID可以保證在全球范圍的唯一性。但與此同時，使用MAC地址會帶來安全性問題，這就是這個版本UUID受到批評的地方。如果應用只是在局域網中使用，也可以使用退化的算法，以IP地址來代替MAC地址－－Java的UUID往往是這樣實現的（當然也考慮了獲取MAC的難度）。

UUID Version 2：DCE安全的UUID

DCE（Distributed Computing Environment）安全的UUID和基於時間的UUID算法相同，但會把時間戳的前4位置換為POSIX的UID或GID。這個版本的UUID在實際中較少用到。

UUID Version 3：基於名字的UUID（MD5）

基於名字的UUID通過計算名字和名字空間的MD5散列值得到。這個版本的UUID保證了：相同名字空間中不同名字生成的UUID的唯一性；不同名字空間中的UUID的唯一性；相同名字空間中相同名字的UUID重復生成是相同的。

UUID Version 4：隨機UUID

根據隨機數，或者偽隨機數生成UUID。這種UUID產生重復的概率是可以計算出來的，但隨機的東西就像是買彩票：你指望它發財是不可能的，但狗屎運通常會在不經意中到來。

UUID Version 5：基於名字的UUID（SHA1）

和版本3的UUID算法類似，只是散列值計算使用SHA1（Secure Hash Algorithm 1）算法。

UUID的應用

從UUID的不同版本可以看出，Version 1/2適合應用於分布式計算環境下，具有高度的唯一性；Version 3/5適合於一定范圍內名字唯一，且需要或可能會重復生成UUID的環境下；至於Version 4，我個人的建議是最好不用（雖然它是最簡單最方便的）。

通常我們建議使用UUID來標識對象或持久化數據，但以下情況最好不使用UUID：

• 映射類型的對象。比如只有代碼及名稱的代碼表。
• 人工維護的非系統生成對象。比如系統中的部分基礎數據。

對於具有名稱不可重復的自然特性的對象，最好使用Version 3/5的UUID。比如系統中的用戶。如果用戶的UUID是Version 1的，如果你不小心刪除了再重建用戶，你會發現人還是那個人，用戶已經不是那個用戶了。（雖然標記為刪除狀態也是一種解決方案，但會帶來實現上的復雜性。）

UUID生成器

我沒想着有人看完了這篇文章就去自己實現一個UUID生成器，所以前面的內容並不涉及算法的細節。下面是一些可用的Java UUID生成器：

• Java UUID Generator (JUG)：開源UUID生成器，LGPL協議，支持MAC地址。
• UUID：特殊的License，有源碼。
• Java 5以上版本中自帶的UUID生成器：好像只能生成Version 3/4的UUID。
  

此外，Hibernate中也有一個UUID生成器，但是，生成的不是任何一個（規范）版本的UUID，強烈不建議使用。

 

【References】

[1] 百度百科（http://baike.baidu.com/item/UUID）

[2] http://www.blogjava.net/feelyou/archive/2008/10/14/234320.html