通用唯一识别码

通用唯一识别码（英语：Universally Unique Identifier，缩写：UUID）是用于计算机体系中以识别信息的一个128位标识符。

UUID按照标准方法生成时，在实际应用中具有唯一性，且不依赖中央机构的注册和分配。UUID重复的概率接近零，可以忽略不计。

因此，所有人都可以自行创建和使用UUID，而且几乎可以确定其不会与既有的标识符重复。也因为如此，在不同地方产生的UUID可以使用于同一个数据库或同一个频道中，而且几乎不可能重复。

UUID的应用相当普遍，许多计算平台都提供了对于生成和解析UUID的支持。

1990年代， UUID 原本是用于阿波罗电脑的网络计算系统，后被用于开放软件基金会的分布式运算环境。分布式运算环境UUID的初始设计基于网络计算系统UUID，其设计受 Domain/OS 中定义和使用的（64位）唯一标识符的启发，这是一个也由 阿波罗电脑 设计的操作系统。后来，微软视窗平台采用分布式运算环境设计作为全局唯一标识符（GUID）。

2005年7月，RFC 4122 为 UUID 注册了一个 URN 名字空间，并制定了早期的规范。当 RFC 4122 作为互联网工程任务组标准发布时，国际电信联盟基于先前的标准和 RFC 4122 早期版本标准化了 UUID。

UUID 由开放软件基金会标准化，作为分布式运算环境（DCE）的一部分。

UUID 被纪录为 ISO/IEC 11578:1996 "Information technology – Open Systems Interconnection – Remote Procedure Call（RPC）" 和后来的 ITU-T Rec. X.667 | ISO / IEC 9834-8：2005 规范的一部分。

互联网工程任务组公布了标准 RFC 4122，技术上等同于 ITU-T Rec. X.667 | ISO/IEC 9834-8。

在其规范的文本表示中，UUID 的 16 个 8 位字节表示为 32 个十六进制数字，由连字符 '-' 分隔成五组显示，形式为“8-4-4-4-12”总共 36 个字符（32 个十六进制数字和 4 个连字符）。

例如：

四位数字 M表示 UUID 版本，数字 N的一至三个最高有效位表示 UUID 变体。在例子中， 是 1 而且 是 a（10xx2），这意味着此 UUID 是“变体1”、“版本1”UUID；即基于时间的 DCE/RFC 4122 UUID。

规范的 `8-4-4-4-12` 格式字符串基于 UUID 的16个字节的“记录布局”：

这些字段对应于“版本1”和“版本2”（基于时间的）UUID中的字段，但是“8-4-4-4-12”的表示适用于所有UUID，即使对于生成方式不同的UUID也是如此。

RFC 4122 第 3 节要求以小写形式生成字符，同时对输入不区分大小写，尽管一些常用的实现违反了此规则。

Microsoft GUID有时会以大括号表示：

不应将此格式与“Windows注册表格式”相混淆，后者指的是大括号内的格式。

RFC 4122为UUID定义了统一资源名称（URN）名字空间。作为URN呈现的UUID如下：

UUID 的二进制编码因系统而异。UUID的变体1是目前世界最常见的UUID，完全以大端序（big-endian）二进制存储与传输 UUID 。

例如，00112233-4455-6677-8899-aabbccddeeff 编码为字节 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff。

其他系统，特别是 Microsoft 在其 COM/OLE 库中对 UUID 的字符串表示，使用混合端格式，其中 UUID 的前三组是小端序/小尾序（little-endian），后两组是 大端序/大尾序（big-endian）。

例如，00112233-4455-6677-8899-aabbccddeeff 编码为字节 33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff。

UUID的变体（variant）字段，占1到3比特。RFC 4122定义了4种变体：

目前的UUID规范使用变体1和2。在文字表示上，两种变体只有代表变体的比特不同。上面的字段也定义了两种变体之间的字节转换。前三个字段是无正负号的32和16位数字，需要进行转换，而后两个字段是由未解释的字节组成，不需要进行转换。这种转换同样适用于版本3、4和5，其中的规范字段与UUID的内容无关。

虽然一些重要的GUID名义上是变体2的UUID，例如组件对象模型（Component Object Model）IUnknown接口的标识符，但是在微软Windows软件中所生成和使用的、被称为“GUID”的许多标识符是使用标准的变体1的RFC 4122/DCE 1.1大端序UUID。目前，Microsoft guidgen工具软件产生变体1的结果。某些微软文档称GUID与UUID是同义词，如同RFC 4122中表示UUID“也被称作GUID”。这些文件表明了虽然“GUID”最初指代微软所使用的其中一种UUID变体，但现在已经成为UUID的另一个名称，含括变体1和2。

对于“变体（variants）1”和“变体2”，标准中定义了五个版本（versions），并且在特定用例中某些版本可能比其他版本更合适。

版本由字符串中的 M 指示。

版本1的UUID是根据时间和节点ID（通常是MAC地址）生成；版本2的UUID是根据标识符（通常是组或用户ID）、时间和节点ID生成；版本3、版本5透过对名字空间（namespace）标识符和名称进行散列生成确定性的UUID；版本4的UUID则使用随机性或伪随机性生成。

Nil UUID是一个特例，值为 00000000-0000-0000-0000-000000000000 ；也就是说，所有位都设置为 0。

版本1的UUID，是根据 60-bit 的时间戳和节点（生成UUID的计算机）的48-bit MAC地址而生成的。

时间戳的是这样计算的：自公历首次于天主教会和教皇国以外的地方使用的日期，也就是协调世界时（UTC）1582年10月15日午夜算起，每经过100纳秒时间戳加1。RFC 4122声明时间值在公元3400年左右算术溢出:3，取决于所使用的算法，代表此 60-bit 时间戳是有符号数量。但是，某些软件（如libuuid库）将时间戳视为无符号，把溢出时间推迟至公元5236年。ITU-T Rec. X.667所定义的溢出时间为公元3603年:v。

13-bit 或 14-bit“无统一”（uniquifying）时钟序列扩展了时间戳，以便处理处理器时钟不能足够快地前进的情况，或者每个节点有多个处理器和 UUID 生成器的情况。对于每个“版本1”UUID 对应于空间（节点）和时间（间隔和时钟序列）中的单个点，两个正确生成的“版本1”UUID 无意中相同的可能性实际上为零。由于时间和时钟序列总共74位，每个节点 id 可以生成 ${\displaystyle 2^{74}}$，至少必须生成多少个版本4的UUID可由下式近似计算：

${\displaystyle \sqrt{2\times <!--\; \times \; -->2^{122}\times <!--\; \times \; -->\ln <!--\; \; -->\frac{1}{1-<!--\; -\; -->p}}}$

因此，在 103 万亿个版本4 UUID 中找到重复的概率是 ${\displaystyle \frac{1}{1000000000}}$（十亿分之一）。

重要用途包括 ext2/ext3/ext4 文件系统用户空间工具（e2fsprogs 使用 util-linux 提供的 libuuid）、LUKS 加密分区、GNOME、KDE 和 Mac OS X，其中大部分源自 曹子德（Theodore Ts'o）的实现。

Solaris 中 UUID 的一种用途（使用开放软件基金会的实现）是识别正在运行的操作系统实例，以便在内核崩溃的情况下将故障转储数据与故障管理事件配对。

分区标签和分区UUID都存储于超区块中。两者皆为文件系统的一部分，而不是分区的一部分。例如，ext2-ext4包含UUID，而NTFS或FAT32则没有。

超区块是文件系统的一部分，因此被完全包含在分区中，因此如果你执行dd if=/dev/sda1 of=/dev/sdb1，sda1和sdb1都会拥有相同的标签和UUID。

Microsoft的组件对象模型（COM）中使用了几种GUID ：

UUID 通常用作数据库表中的唯一键。

Microsoft SQL Server 版本4 Transact-SQL 中的 NEWID 函数会返回标准随机版本4的UUID，而 NEWSEQUENTIALID 函数返回类似于 UUID 的 128 位标识符，这些 UUID 会依序递增，直到下次系统重启。

另一方面，尽管名称如此，但 Oracle Database SYS_GUID 函数不会返回标准 GUID；相反，它根据主机标识符和进程或线程标识符返回一个16字节的 128 位 RAW 值，有点类似于 GUID。

PostgreSQL 包含一个 UUID 数据类型，并且可以通过使用模块中的函数生成大多数版本的UUID。

MySQL 提供了一个 UUID 函数，它生成标准的版本1 UUID。

当 UUID 用作主键时，版本3、4和5 UUID 的随机性以及 版本1和2 UUID 内的字段的排序可能会产生数据库定位或性能问题。例如，2002年 Jimmy Nilsson 报告说，当用作主键的版本4 UUID 被修改为包含基于系统时间的非随机后缀时，Microsoft SQL Server的性能显着提高。Nilsson 承认，这种所谓的“COMB”（组合时间和GUID）方法使UUID非标准并且更有可能被复制，但 Nilsson 仅要求在应用程序中的唯一性。透过重新排序和编码版本1和版本2的UUID，将时间戳放在最前面，可以避免插入所造成的性能损失。

诸如Laravel这样的部分网络框架支持“时间戳优先”的UUID，可以将UUID有效存储于索引数据库中。这种UUID是版本4格式的COMB UUID，但其中前48位组成了一个时间戳，就像版本1的UUID一样。其他基于COMB UUID概念的指定格式包括：