UUID惟一资源命名空间的前因后果(RFC4122)

日期：2014-04-26(该死, 又凌晨了)
原文参考：http://tools.ietf.org/html/rfc4122.html

前言：高级与普通程序员的区别就是, 普通程序只复(cao)用(xie)代码片断, 而高级一点的无非就只知道点规范, 写点东西, 让其余人Copy

本屌最讨厌的面试题是, XXX为何这么设计, TMD我哪知道啊, 创始人就这么写, 我也没辙啊!

简介

UUID, 又名全球独立标识(Globally Unique Identifier), 固然原名更高大上点儿, A.K.A 宇宙独立标识（Universally Unique Identifier). UUID最初用在一个本屌没听过的网络系统中, 而后被普遍应用到微软抄作系统.

UUID是128位(长度固定)unsigned integer, 可以保证(真的假的？)在空间(Space)与时间(Time)上的惟一性。并且无需注册机制保证, 能够按需随时生成。

据WIKI, 随机算法生成的UUID的重复几率为170亿分之一

因为UUID定长且与时间有关, 有必定可能性UUID会重复出现（大概在西元(A.D)3400, 与具体实现算法有关）

UUID生成算法最高支持10,000,000(一千万)每秒每台机器, 因此能够用做交易流水ID

uuid(Python)和NSUUID(iOS)遵循本RFC

UUID生成三种方式

1. 基于利用MAC地址（若因为某种缘由包括隐私考虑, MAC地址不可用或强烈不推荐, 采用如下两种替代方法）
2. 基于伪随机数
3. 基于加密哈希(MD5之类的东东)和应用自定义字符串

字符表示

[time-low]-[time-mide]-[time-high-and-version]-[clock-seq-and-reserved 和 clock-seq-low]-[node]

time-low = 32位 unsigned integer
time-mid = 16位 unsigned integer
time-high-and-version = 16位 unsigned integer(时间戳高位部分与版本(Version)号混合)
clock-seq-and-reserved = 8位 unsigned integer(时钟序列高位部分与预约义变量(Variant)混合组成)
clock-seq-low = 8位 unsigned integer
node = 48位 unsigned integer

urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

字段组成(详情与事例代码,参考RFC4122 section4 till the end)

UUID采用Big-endian字节序排列

变量(variant), 或称作类型, 4 bytes, 包括如下4种（其中X为任意值）:
0XX NCS兼容预留
10X RFC4122采用
110 微软兼容预留
111 还未定义, 留做之后它用

版本号(version), 4 bytes, 一共如下5个版本:
0001 时间的版本
0010 DCE Security
0011 MD5哈希
0100 (伪)随机数
0101 SHA-1哈希

时间戳(timestamp), 60bit:
版本1: 时间戳采用UTC时间,以100ns为间隔,重1582年10月15日00:00:00.00开始计算

时钟序列, 14bit:
版本1: 用来防止在时间回调的状况下,致使的UUID重复问题
若是有时间回调(可能有系统断电致使),若是生成器在回调时间以后有生成新的UUID,那么时钟序列应该改变, 若是新生成的UUID时钟序列可知,那么时钟序列递增便可; 若不可知, 那么时钟序列应重置到一个47位随机数,或一个47位高质量的伪随机数,而且第48位设置为1,用来区别真正的MAC地址(因为全部MAC地址在网卡中第48为0)

节点(node), 48bit:
版本1: 为主机MAC地址, 若主机有多个MAC地址,随机选其中一个, 若系统没有MAC地址, 则采用(伪)随机数.

其余版本请参考原文, 其中版本2没有在原文中叙述

Nil UUID

128位中,每一位都是零, (A.K.A)
urn:uuid:00000000-0000-0000-0000-000000000000

感谢您的大驾光临, 不管您是习惯右手, 仍是左手点赞都木有关系, 若是本文对您有那么丁点儿帮助, 请用您最销魂的姿式点个赞. 若有问题请留言!