§

UUID 生成器 — 免费在线 UUID v4 生成器

v4 是默认选项。v7 按生成时间字典序排序,是数据库主键的最佳选择。
输出格式
§

输出

    UUID 是国内分库分表与微服务的常客。阿里云 PolarDB、腾讯云 TDSQL-C、华为云 GaussDB 在分片表里常用 UUID v4 作为业务主键,避免雪花算法跨数据中心时钟回拨;接入支付宝、微信支付时,商户订单号 out_trade_no 经常用 UUID 拼接业务前缀;京东、拼多多、抖音电商的开放平台幂等键 idempotency_key 多为去掉连字符的 32 位 UUID;医疗 HL7 FHIR R4 接口对接卫健委区域全民健康信息平台时,Resource.id 直接采用 RFC 9562 v7 以满足时序与 PIPL 审计要求。

    // 相关工具

    ./base64-encoder
    Base64 编码器
    将文本和文件编码为 Base64 格式。
    →
    ./url-encoder
    URL 编码器
    对字符串进行百分号编码，以便在 URL 中安全传输。
    →
    ./hash-generator
    哈希生成器
    在浏览器中生成 MD5、SHA-1、SHA-256 和 SHA-512 摘要。
    →
    ./
    全部工具
    浏览 Ultim8Soft 在线工具的完整合集。
    →

    什么是 UUID？

    UUID(通用唯一标识符)是一个 128 位的值,以 36 个字符的字符串呈现,例如 550e8400-e29b-41d4-a716-446655440000。其格式与版本语义由 RFC 4122 定义(v1 到 v5),并由 RFC 9562 定义较新的 v6、v7 和 v8。本工具生成 v4(纯随机)、v1(时间戳加随机节点 ID)和 v7(Unix 毫秒时间戳前缀加随机后缀,可按生成时间排序),全部在你的浏览器中通过平台的 Web Crypto API 完成,不会向任何服务器发送数据。

    UUID 生成是如何工作的？

    不同版本在确定性、可排序性和熵之间的权衡各不相同。工具会根据您的选择采用相应算法:

    1. v4(随机)调用浏览器的 crypto.randomUUID(),返回 122 位密码学随机数,并在正确的位置设置 6 个固定位(版本 0100 与变体 10)。碰撞概率极低——大约需要生成 2.71 × 10^18 个 v4 UUID,才能以 50% 的概率出现一次重复。
    2. v1(时间戳 + 节点)将 60 位的格里高利时间戳(自 1582-10-15 起的 100 纳秒计数)装入 time_low / time_mid / time_hi_and_version,把版本半字节设为 0001,选择带变体位的 14 位时钟序列,并使用 48 位随机节点 ID,且强制将多播位置 1(RFC 4122 §4.5 明确允许在没有硬件 MAC 时使用随机节点 ID,多播位将其标记为非 MAC)。
    3. v7(可排序时间戳)按 RFC 9562 §5.7 排布:48 位大端 Unix 毫秒时间戳,紧接着 4 位版本 0111,然后 12 位随机数,再是 2 位变体 10,最后还有 62 位随机数。由于时间戳位于最高有效位,v7 UUID 按生成顺序进行字典序排序——这是其他 UUID 版本未经额外编码无法做到的特性。
    4. 所有随机性都来自 crypto.getRandomValues(),即浏览器的密码学安全 RNG。v1 和 v7 都加入了同一时钟刻度内的单调性保护,使同一刻度内两次连续调用的第二个值仍排在第一个之后——这对跑得比毫秒时钟还快的批量生成至关重要。
    5. 生成完成后会运行格式化流水线。你可以去掉连字符、切换为大写、用花括号包裹值({…}——微软 GUID 约定),或将原始 16 字节渲染为 base64(22 字符输出,无填充)。base64 模式会覆盖其他格式选项,因为 base64 本身就是一种独立表示。

    为什么使用这个 UUID 生成器？

    • 没有数据离开你的浏览器。Web Crypto API 在本地运行;页面在文档初始加载之后不发出任何网络请求。打开 DevTools,点击生成,网络面板始终是空的。
    • 符合 RFC 的输出。v4 遵循 RFC 4122 §4.4,v1 遵循 §4.2 与 §4.5,v7 遵循 RFC 9562 §5.7。版本半字节和变体位都按标准放在正确位置——每个 UUID 都能通过对应版本的正则校验。
    • 可排序的 v7 适合用作数据库主键。在 Postgres、MySQL 或 SQL Server 中把 v7 UUID 作为聚集主键,可以让插入保持索引追加写——没有页分裂,没有随机 I/O——同时仍然全局唯一。v4 做不到,因为它的位是随机的。
    • 批量生成不受速率限制。一次可生成 1、10、100 或 1,000 个 UUID。没有配额,也不需要注册——工具运行在你的标签页里,上限是你的 CPU,而不是某个供应商的 API 套餐。

    UUID 的常见应用有哪些？

    只要系统需要在不与中央机构协调的情况下获得全局唯一标识,UUID 就会派上用场:

    • 数据库主键。自增整数会泄露行数并破坏分片。UUID 跨分片稳定、跨区域合并安全,而且(在 v7 下)能让 B 树插入保持热区不发生页分裂。典型应用在客户端生成 UUID,把它放进 INSERT 中,从不需要为获取主键而往返服务器。
    • 请求关联 ID。HTTP 中间件为每个入站请求附加一个 v4 UUID,在每条 span 中记录,并向下游传递(通常作为 X-Request-Id 头)。当客户报告 bug 时,支持工程师粘贴该 ID,跨服务、跨时区的整条请求轨迹便毫无歧义地浮现出来。
    • 幂等键。支付 API(Stripe、Adyen、Square)接受 Idempotency-Key 头,使重试的请求不会向客户重复扣款。客户端生成的 UUID 保证该键对每次逻辑操作都是唯一的,这正是这些 API 所要求的契约。

    UUID 示例是什么样的？

    在 Node.js 或现代浏览器中,一行 crypto.randomUUID() 即可返回一个新的 v4 UUID——例如 3f50b5a8-2c54-4b9c-9c1f-3e5c7e2b8d12。用它做请求 ID 或幂等键即可。如果 UUID 要进入将作为聚集主键的数据库列,则应改为生成 v7:相隔一毫秒生成的两个 v7 值,如 0190a3b0-7d4f-7c9e-8b21-a4d6f0bd9c11 与 0190a3b0-7d50-7f15-9c4e-72b3e0c1d8a4,按生成顺序按字典序排序。Postgres 的 uuid 类型对两种版本的存储完全一致——差异出现在索引写入时:v7 在 B 树右端追加,而 v4 的插入则散布各处,迫使产生随机 I/O。

    这款 UUID 生成器只做一件事:把一次点击变成一个或多个符合 RFC 的标识符,按你需要的格式输出,而不会把请求发送到任何服务器。选版本、选数量、选格式——生成、复制、继续手头的工作。