UUID 生成
UUID Generator
批量生成 UUID v1、v4、v5 和 v7，并能从 v1 或 v7 的值里解出时间戳。
在浏览器里生成 UUID——v4 是纯随机，v7 用在你希望 id 按创建时间排序的时候，v5 和 v3 用在同样的输入必须永远给出同样的 id 的时候。它也能解码：粘一个 UUID，它读出版本、变体位，以及藏在 v1、v6 或 v7 里的时间戳。
122 位随机。默认值，只要不需要排序，它就是答案。
0个 UUID
在这个标签页里用 `crypto.getRandomValues` 生成。不向服务器要任何东西，所以这些值没有第二个人见过。
拆开一个 UUID
粘贴任意 UUID，可以读出版本、变体位，以及 v1、v6 和 v7 里面藏着的时间戳。
版本位和变体位遵循 RFC 9562，并拿它附录 A 的实例对过。v1 和 v6 的节点 id 是置了多播位的随机数——浏览器没有 MAC 地址可泄。
怎么用
选版本
没有理由就用 v4。有理由的话通常是排序——v7 的前几位带着 Unix 毫秒数，以它为键的表会保持插入顺序，索引不会碎片化。
设置格式
大写、连字符，以及 Windows 和 .NET 用的 `{…}` 花括号。这些只改文本，从不改底下那 128 位。
v3 和 v5 要给命名空间和名字
这两个版本对这一对做哈希，所以同一个 DNS 命名空间配 `www.example.com` 永远得到同一个 UUID——在任何地方、任何时候。这就是它们的意义，也是它们不随机的原因。
复制整批，或检查其中一个
「全部复制」拿走整个列表；某一行旁边的「检查」把它载入解码面板，那里还会打印出 16 个原始字节。
常见问题
这些随机到能当令牌用吗？
v4 有 122 个来自 `crypto.getRandomValues` 的随机位，那是真正的 CSPRNG——和任何 122 位的秘密一样不可猜。但 v1、v6 或 v7 大部分是时间戳，v3 或 v5 是对别人也许猜得到的输入做的哈希。只有 v4 不可预测。
v1 会泄露我的 MAC 地址吗？
在这里不会。最初的 v1 用的是网卡地址，这个版本的名声就是这么来的。浏览器接触不到网卡，所以节点字段是随机的并置上多播位——这正是规范为这种情况留的出口。
为什么一批 v5 UUID 不是全都一样？
因为每一行都在名字后面追加了一个序号——否则一批十个就是同一个值打印十次，正确但没用。如果你要的是你那个名字精确的哈希，一次只生成一个。
UUID 适合做主键吗？
v7 通常适合；v4 通常不适合。随机键把插入打散到整棵 B 树上，让索引碎片化，在大表上是能测出来的。如果你已经在用 v4 并且吃到了苦头，v7 就是大家迁移的方向。
可以从这些接进来
接下来
这些工具吃得下当前工具的产出，结果可以直接送过去。
Unix 时间戳转换
Unix Timestamp Converter
在 epoch 秒、毫秒、ISO 8601 和人读日期之间按任意时区互转。
ULID 与 NanoID 生成
ULID & NanoID Generator
按指定的字母表和长度生成可排序的 ULID 或短小的 NanoID，并给出碰撞概率。
随机密钥生成
Random Key Generator
按指定长度生成密码学随机字节，输出十六进制、Base64 或 Base64URL，用作应用的 secret。
Base64 编码解码
Base64 Encoder & Decoder
对文本和文件做 Base64 与 Base64URL 编解码，UTF-8 处理正确。
curl 转代码
curl to Code
把一条 curl 命令转成 fetch、axios、Python requests、Go、PHP 或 PowerShell 代码。
文本哈希计算
Text Hash
算出字符串的 MD5、SHA-1、SHA-256、SHA-384、SHA-512 和 CRC-32，输出可选大写或 Base64。