开发者工具 · UUID 生成器
手动读取 UUID：版本和变体位所在的位置
· 工作原理
uuid 密码学 浏览器 API
每个 UUID 中的两个十六进制字符告诉您哪个版本生成了它以及它遵循哪种变体布局。学会一眼阅读它们并知道它们不能告诉你什么。
哪个系统创建了此 ID？ — 版本半字节可以回答的日志取证问题
UUID 字符串具有 36 个字符：三十二个十六进制数字和 8-4-4-4-12 位置处的四个连字符。每个 UUID 中的两个字符（出现在 14 和 19 位置）编码元数据：版本字段告诉您哪个算法生成了 ID，变体字段告诉您它遵循哪种标准布局。不使用工具读取这两个字符是日志取证技能：您在数据库转储或错误消息中发现 UUID ，并立即知道它是 v1 时间戳（泄漏创建时间）、v4 随机值（从 CSPRNG 生成）还是其他值。版本号占用 UUID 的位 48–51，映射到第三组的第一个十六进制字符。
五组中的 128 位布局 — 8-4-4-4-12 如何映射到字节以及为什么这些组是历史性的，而不是功能性的
对于字符串 xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx，位置 14 处的字符是版本。 RFC 9562 定义版本 1 到 8：v1 基于公历时间并泄漏创建时间； v4 是随机的； v7 是基于 Unix 时间且可排序的。版本 0、9 及更高版本已保留或未使用。如果您看到 v1 UUID，您就知道时间和硬件地址已混合在一起；如果您看到 v4，则 ID 是带有版本位集的随机字节；如果您看到 v7，它会按创建时间排序。版本不可选；每个正确形成的 UUID 都有一个。变体字段占用 UUID 的位 64–65，即八位字节 8 的两个最高有效位。
版本半字节 — 第三组的第一个字符，1 到 8 的含义，以及 0 或 9 表示什么
在文本表示 xxxxxxxx-xxxx-xxxx-Nxxx-xxxxxxxxxxxx 中，第四组的第一个字符（位置 19）对变体进行编码。对于 RFC 9562 变体（现代使用的标准），此字符必须是 8、9、a 或 b — 1000、1001、1010 和 1011 的二进制十六进制表示形式。任何其他字符 (0–7, c–f) 表示不同的变体： 0–7 是 NCS 向后兼容性； c–d 是具有小端字节顺序的 Microsoft 旧版 GUID； e–f 保留。当您阅读位置 19 并看到 8、9、a 或 b 时，您正在查看 RFC 9562 UUID。任何其他值都意味着字节遵循不同的解释。 128 位布局分为八位字节 0–15，但文本格式将它们按组分隔以提高可读性，而不是功能。
变体字段 — 为什么第四组的第一个字符是 8、9、RFC UUID 的 a 或 b，以及 c/d（Microsoft 旧版）或 0–7 (NCS) 信号
这五组代表历史字段边界：前三个字段包含 v1 UUID 中的时间戳和版本，第四个字段包含时钟序列和变体，第五个字段包含节点标识符。版本 4 和更高的 UUID 版本不使用这些字段名称，但相同的位位置仍然携带版本和变体。读取 v4 UUID 意味着接受大多数 128 位是随机负载，但其中两个（文本中的 14 和 19 位置）是由标准固定的。这些固定位证明 ID 是 v4 和 RFC 变体。 nil UUID 是 00000000-0000-0000-0000-000000000000，全部为零，并且根本没有版本。最大 UUID 为 ffffffff-ffff-ffff-ffff-ffffffffffff，全部为 f 字符，并且也是保留的且无版本控制。
工作示例 — 逐个字符解码三个样本标识符，包括 v4 和 v7
每个其他格式正确的 UUID 在第三组中有一个版本，在第四组中有一个变体。使用三个示例 ID 进行测试：123e4567-e89b-12d3-a456-426614174000（v1，变体 RFC，因为位置 19 是 a）； 9b2e4f1a-4f3e-4c1a-8a7d-1b2c3d4e5f60（v4，变体 RFC，因为位置 19 是 8）； 018f0c2e-1b5a-7c3d-9e4f-5a6b7c8d9e0f（v7，变体 RFC，因为位置 19 是 9）。 ToolAcre 检查器会确认您的读数。格式检查无法告诉您 ID 是唯一的、存在于数据库中还是安全生成的。版本 v1 使用时间和硬件作为输入，因此来自不同计算机的相同 v1 UUID 意味着时钟偏差或同步问题。版本 v4 是随机的，因此重复的 v4 UUID 意味着要么随机性被破坏，要么天文数字上不太可能发生碰撞（大约每 2. 7 万亿个具有良好随机性的 UUID）。
Nil 和 Max — 两个全零和全 F 值，根本不携带版本
版本 0 或 9 表示该字符串根本不是有效的 UUID。阅读版本和变体是理解 ID 是什么的第一步；检查它是否存在或唯一是第二步和第三步，由数据库和业务逻辑完成。了解位位置有助于调试数据迁移。从旧系统导入 UUID 时，某些工具会导出与 RFC 9562 标准不匹配的变体字段。 c 或 d 的变体字段指示采用小端字节顺序的 Microsoft GUID。这些 GUID 是 Microsoft 系统内的有效标识符，但在没有字节顺序转换的情况下不能与 RFC 9562 UUID 互操作。读取位置 19 会立即告诉您哪个系统生成了 ID。如果您看到 8、9、a 或 b，则您拥有 RFC 标准 UUID。
格式检查无法告诉您的信息 — ID 存在于您的数据库中、它是安全生成的或者它是唯一的
如果您看到 c 或 d，则您有一个 Microsoft GUID。如果您看到任何其他字符，则标识符格式错误或来自模糊系统。 ToolAcre 生成器始终生成位置 19 作为 8、9、a 或 b 之一的 RFC 9562 UUID。三位版本字段编码七个可能的值（1–7；版本0 和8 有特殊含义）。版本 1 是公历时间戳，版本 3 是基于 MD5 的命名空间，版本 4 是随机的，版本 5 是基于 SHA-1 的命名空间，版本 6 是基于 Unix 时间戳的（建议），版本 7 是基于 Unix 时间戳的可排序（在 RFC 9562 中标准化），版本 8 保留用于自定义格式。读取位置-14 字符会立即告诉您使用了哪种算法。如果您正在调试 UUID 冲突或意外排序，版本号是您的第一个线索。 ToolAcre 专门从加密生成 v4 UUID。
要点：两个字符，大量上下文 - 使用 ToolAcre 格式正确的检查来确认字符串解析，然后自己读取版本半字节
getRandomValues；它生成的每个 UUID 在位置 14 处都有一个 4。手动解析 UUID 结构对于调试无法使用工具的复杂系统来说是一项有用的技能。在生产事件中，您可能需要从数据库转储、错误日志或缓存中读取 UUID，而无需运行特殊工具。您寻找位置 14 来识别版本（它是否泄漏时间？它是随机的吗？它是可排序的吗？）。您查找位置 19 来标识变体（它是 RFC 标准吗？它是 Microsoft GUID？它是保留的吗？）。这两个字符（总共 36 个）携带元数据。剩余的 34 字符是有效负载：时间戳或随机字节或其他特定于算法的数据。了解有效负载代表什么有助于您了解 ID 在系统中的角色。