UUID Decoder

Decode and inspect UUID structure, version, and embedded data

加载示例

UUID 输入

请在上方粘贴 UUID 进行检查

也可以试试：UUID v4生成器 UUID v1生成器 UUID v7生成器 UUID v3生成器 UUID v2生成器 ULID生成器 NanoID生成器 CUID v1生成器 CUID2生成器

UUID 结构

UUID（通用唯一标识符）是一个 128 位值，表示为 32 个十六进制数字，由连字符分成五组：

格式

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

xxxxxxxx (8)8 个十六进制数字——32 位

xxxx (4)4 个十六进制数字——16 位

Mxxx (4)4 个十六进制数字——16 位。第一个数字 M 编码 UUID 版本（1–8）。

Nxxx (4)4 个十六进制数字——16 位。第一个数字 N 编码 UUID 变体（RFC 4122、NCS、Microsoft 或保留）。

xxxxxxxxxxxx (12)12 个十六进制数字——48 位

版本和变体是唯一保证在每个 UUID 中都存在的两个字段。所有其他字段取决于版本。

版本字段

版本半字节是第三组的第一个十六进制数字（完整字符串中的位置 14）。它标识用于生成标识符的 UUID 版本。

JavaScript

const hex = uuid.replace(/-/g, '')
const version = parseInt(hex[12], 16)  // single hex digit → 1, 2, 3, 4, 5, 6, 7, or 8

版本 7（UUID v7）是最新的广泛使用版本，在 RFC 9562（2024 年）中引入。它在高位编码 Unix 毫秒时间戳以实现可排序性。

变体字段

变体编码在第四组第一字节的高位中。它标识 UUID 使用的布局和字节排序约定。

高位	第一个十六进制数字范围	变体	描述
0xxx xxxx	0x00–0x7F	NCS 向后兼容	遗留网络计算系统（NCS）UUID。为向后兼容性保留。
10xx xxxx	0x80–0xBF	RFC 4122 / RFC 9562	标准 RFC 4122 / RFC 9562 UUID 变体。用于所有现代 UUID 版本（v1–v8）。
110x xxxx	0xC0–0xDF	Microsoft 向后兼容	具有不同字节排序的遗留 Microsoft COM/DCOM GUID。在 Windows COM 组件中仍然存在。
111x xxxx	0xE0–0xFF	保留	为将来定义保留。任何当前 UUID 版本都不使用。

在实践中，你遇到的几乎所有 UUID 都使用 RFC 4122 / RFC 9562 变体（位模式 10xx xxxx，第四组的第一个字节在 0x80–0xBF 范围内）。NCS、Microsoft COM 和 Reserved 变体是旧式格式，在现代系统中很少见。

UUID 版本参考

RFC 4122 定义了版本 1–5。RFC 9562（2024 年）添加了版本 6、7 和 8：

版本	名称	标准	描述
v1	基于时间	RFC 4122	时间戳（格里高利纪元，100 纳秒精度）+ MAC 地址。每台主机顺序排列，但泄露主机身份。
v2	DCE 安全	RFC 4122	基于 UUID v1，time_low 字段替换为 POSIX UID/GID。在遗留 DCE/RPC 系统之外很少使用。
v3	基于名称的 MD5	RFC 4122	确定性的：命名空间 UUID + 名称字符串的 MD5 哈希。相同输入始终产生相同 UUID。优先选择 v5。
v4	随机	RFC 4122	122 位加密安全随机数。最常用的通用 UUID 版本。
v5	基于名称的 SHA-1	RFC 4122	类似 v3 但使用 SHA-1。比 MD5 更具抗碰撞性。对于新的基于名称的 UUID 优先选择 v3。
v6	重新排序的时间	RFC 9562	重新排序 UUID v1 时间戳字段，使 UUID 按时间顺序可排序。在 RFC 9562 中定义。
v7	Unix 时间	RFC 9562	高位 48 位 Unix 毫秒时间戳 + 随机数据。可排序且对 B 树索引友好。对新的时间排序 ID 优先选择。
v8	自定义	RFC 9562	自由格式：除版本和变体之外的所有位都由应用程序定义。未指定生成算法。

解码 UUID v1 时间戳

UUID v1 嵌入了一个 60 位格里高利时间戳（自 1582 年 10 月 15 日起的 100 纳秒间隔），分散在三个字段中：time_low（位 0–31）、time_mid（位 32–47）和 time_hi（位 48–59）。此工具重新组装并将它们转换为标准 UTC 日期。

JavaScript

// UUID v1: 6ba7b810-9dad-11d1-80b4-00c04fd430c8
//           ^^^^^^^^ ^^^^ ^^^^ ^^^^^ ^^^^^^^^^^^^
//           time-low  mid  hi  clk   node (MAC)
//                          ^
//                          version nibble (1)

const hex = '6ba7b8109dad11d180b400c04fd430c8'

const tLow = parseInt(hex.slice(0, 8),  16)  // 0x6ba7b810
const tMid = parseInt(hex.slice(8, 12), 16)  // 0x9dad
const tHi  = parseInt(hex.slice(13, 16), 16) // 0x1d1 (skip version nibble at index 12)

// Reconstruct 60-bit timestamp (100-ns intervals since Oct 15, 1582)
const t = (BigInt(tHi) << 48n) | (BigInt(tMid) << 32n) | BigInt(tLow)

// Subtract Gregorian offset (Oct 15, 1582 → Jan 1, 1970 in 100-ns units)
const GREGORIAN_OFFSET = 122192928000000000n
const unixMs = (t - GREGORIAN_OFFSET) / 10000n

console.log(new Date(Number(unixMs)).toISOString())
// → 1998-02-04T22:13:53.578Z

Note:时钟序列字段（14 位）在时钟向后移动时防止重复。节点字段（48 位）通常是生成主机的 MAC 地址。

UUID v1 应被视为敏感的：嵌入的 MAC 地址和精确时间戳可以识别生成机器和生成时间。

解码 UUID v7 时间戳

UUID v7 在前 48 位（第一组 + 第二组的前 4 个数字）中嵌入了 48 位 Unix 毫秒时间戳。此工具读取这些位并将它们转换为具有毫秒精度的 UTC 日期。

JavaScript

// UUID v7: 018e4bc8-1000-7000-8000-000000000001
//           ^^^^^^^^^^^^
//           48-bit Unix ms timestamp

const hex = '018e4bc8100070008000000000000001'

// First 48 bits (12 hex chars) = Unix timestamp in milliseconds
const ms = parseInt(hex.slice(0, 12), 16)  // 0x018e4bc81000

console.log(new Date(ms).toISOString())
// → 2024-03-11T…Z

// Everything after byte 6 is random (except version/variant bits)

与 UUID v1 不同，UUID v7 时间戳使用熟悉的 Unix 纪元（1970 年 1 月 1 日），不嵌入任何主机信息。剩余 74 位是随机的。

此工具如何检测 UUID 版本和变体

解码器读取规范 UUID 字符串的位置 14（版本半字节）和位置 19（变体半字节）。不需要外部状态或上下文——所有信息都包含在 UUID 字符串中。

JavaScript

// Detect UUID version from the 13th hex character (index 12)
function uuidVersion(uuid) {
  const clean = uuid.replace(/-/g, '')
  return parseInt(clean[12], 16)
}

uuidVersion('550e8400-e29b-41d4-a716-446655440000') // → 4
uuidVersion('018e4bc8-1000-7000-8000-000000000001') // → 7
uuidVersion('6ba7b810-9dad-11d1-80b4-00c04fd430c8') // → 1

// Detect variant from the 17th hex character (index 16, first char of 4th group)
function uuidVariant(uuid) {
  const clean = uuid.replace(/-/g, '')
  const b = parseInt(clean[16], 16)
  if ((b & 0x8) === 0)      return 'NCS'
  if ((b & 0xC) === 0x8)    return 'RFC 4122'
  if ((b & 0xE) === 0xC)    return 'Microsoft'
  return 'Reserved'
}

特殊 UUID

Nil UUID

Nil UUID 00000000-0000-0000-0000-000000000000 全为零。它由 RFC 4122 定义为表示「无 UUID」的哨兵值——类似于 null。它不是有效的生成 UUID。

Max UUID

Max UUID ffffffff-ffff-ffff-ffff-ffffffffffff 全为一（每字节 0xFF）。在 RFC 9562 中定义，它是 Nil UUID 的补充，用作最大哨兵值。

常见问题

我如何判断 UUID 的版本？

查看规范 UUID 字符串中的位置 14（第三个连字符分隔组的第一个字符）。该单个十六进制数字是版本号：1、2、3、4、5、6、7 或 8。将 UUID 粘贴到此工具中，它将为你解码版本。

我可以解码 UUID 来恢复原始数据吗？

这取决于版本。UUID v1 和 v7 嵌入了可以完整恢复的时间戳。UUID v1 还嵌入了 MAC 地址。UUID v3 和 v5 是单向哈希——你无法从 UUID 中恢复原始名称。UUID v4 是纯随机的——没有任何东西可以恢复。

UUID 中的「变体」是什么意思？

变体字段标识 UUID 的字节布局和解释约定。你遇到的几乎所有 UUID 都将具有 RFC 4122 变体（高位 10），编码为位置 19 的十六进制数字 8、9、a 或 b。其他变体（NCS、Microsoft）是 1990 年代的遗留格式。

为什么有些 UUID 看起来与其他 UUID 不同？

视觉差异在于版本半字节（位置 14）和变体半字节（位置 19）。例如，UUID v4 在位置 14 始终有 4，而 UUID v7 始终有 7。在这些约束内，剩余数字根据版本是随机的或来自时间戳。

Nil UUID 与空 UUID 相同吗？

概念上是的——Nil UUID（全为零）用于表示缺少 UUID，类似于 null。它不是随机生成的 UUID，不应作为真实标识符存储。某些系统将其用作默认或占位符值。

UUID 可以无效吗？

UUID 可以在语法上有效（正确格式）但在语义上不寻常——例如，版本半字节为 0 或变体为 11x（保留）。Nil UUID 和 Max UUID 在语法上有效，但都是哨兵值。此工具将显示存在的任何版本和变体半字节，并标记无法识别的版本。

UUID 和 GUID 有什么区别？

GUID（全局唯一标识符）是 Microsoft 对同一概念的名称。GUID 遵循相同的 RFC 4122 128 位格式。唯一实际区别是遗留 Microsoft GUID 可能使用 Microsoft 变体（高位 110）而非 RFC 4122 变体——这影响二进制表示中的字节排序。文本表示是相同的。

UUID Decoder

UUID 结构

版本字段

变体字段

UUID 版本参考

解码 UUID v1 时间戳

解码 UUID v7 时间戳

此工具如何检测 UUID 版本和变体

特殊 UUID

Nil UUID

Max UUID

常见问题

相关工具