Nano ID 生成工具

在浏览器中批量生成 URL 安全的简短唯一 ID。可自由指定字符集(默认、字母数字、小写、大写、数字、十六进制)和长度,非常适合需要比 UUID 更短的 ID 的场景。

ID 格式对比

格式 长度 字符集大小 能否按生成顺序排序 说明
Nano ID 默认21个字符(可指定1〜64个字符) 64个字符 不能(完全随机) 仅由 URL 安全字符组成的短随机 ID,可自由更改字符集和长度。
UUID v4 36个字符(含4个连字符) 16个字符(十六进制) 不能(完全随机) 由 RFC 9562 标准化的128位标识符,以连字符分隔的十六进制表示法为标准格式。
ULID 26个字符 32个字符(Base32) 能(前10个字符为时间戳) 开头带有毫秒级时间戳,因此可以按字符串顺序排列生成顺序。

Nano ID 是什么

Nano ID 是仅以 URL 安全字符构成短随机 ID 的机制。预设由64种字符(A-Za-z0-9_-)组合21个字符而成,比 UUID 更短,同时又能确保实用上足够的随机性。本工具可自由指定字符种类(预设、英数、小写、大写、数字、16进位)与长度、产生条数,一次批量建立 ID。

产生处理全部在浏览器内完成,并使用 Web Crypto API 的密码学随机数,因此完全不会传送至 toolbase.cc 的服务器。输入表单无须处理机密信息,产生的 ID 可直接复制,用于 URL 的 slug、测试数据、文件名称等。

Nano ID 的使用方式

  1. 选择字符种类 由预设(URL 安全64字符)、英数、仅小写、仅大写、仅数字、16进位中,选择符合用途的字符种类。
  2. 设定长度 指定所产生 ID 的字符数。愈短则碰撞机率愈高,请留意与用途相符的平衡。
  3. 指定产生条数 输入一次想建立的 ID 数量。需要多笔(如批量建立测试数据)时可在此一併指定。
  4. 按下产生按钮 按下「产生」后,符合所指定条件的 ID 便会即时在浏览器内建立并列表显示。
  5. 复制 个别 ID 可用「复制」按钮;若想整批使用,则可用「全部复制」一次复制。

用好本工具的小技巧

  • Nano ID 使用基于 Web Crypto API 的密码学安全随机数生成,且全部在浏览器内处理,不会发送到 toolbase.cc 的服务器。
  • 默认的64字符字母表(A-Za-z0-9_-)不含符号或空格,可以直接安全地用作URL 路径或文件名。
  • 将字符集限定为"仅数字"或"十六进制",可以生成符合现有系统 ID 格式(例如订单编号仅为数字)的 ID。
  • 长度越短,碰撞概率越高。发行量大的系统建议保持默认的21个字符左右,少测量试数据用8〜10个字符左右也可能足够。
  • 增加生成数量后使用"全部复制",便于批量创建测试数据或种子数据。

Nano ID 的活用场景

产生 URL 的 slug

作为短网址或分享连结路径部分所用的唯一 ID,可直接使用不含符号的 URL 安全字符串。

投入测试・虚拟资料

作为投入开发中资料库的样本记录主键或识别码,可一次批量产生所需条数。

发行工作阶段 ID 或请求 ID

作为追踪日志或识别 API 请求所用的临时 ID,可备妥简短易用的字符串。

为避免碰撞的档名编号

想为上传文件的储存名称加上随机 ID,以防同名文件覆写时便可活用。

发行简易 API 金钥或参照码

并非正式环境的认证信息,而是可轻松用于内部工具或验证环境所用短参照码的编号。

用语集

Nano ID
指仅以 URL 安全字符种类构成短随机 ID 的产生方式。预设以21字符、64种字符确保高随机性。
UUID
指由 RFC 标准化的128位元识别码。以连字号分隔的36字符16进位表记为标准形式而广泛使用。
ULID
指开头带有毫秒级时间戳的26字符 ID。可依产生顺序作为字符串排序,此点与 Nano ID、UUID 不同。
Web Crypto API
指浏览器标准配备的密码处理用 API。可产生难以预测的随机数,为 ID 安全性的依据。
密码学随机数
指经设计使下一个值无法以统计方式预测的随机数。可降低 ID 被猜测或冒用的风险。
碰撞机率
指不同的产生偶然造出相同 ID 的机率。字符数与字符种类愈多,碰撞机率愈低。
生日问题
指群体人数愈多、愈容易出现同一生日者的现象,用于估算 ID 碰撞机率时的近似计算。

常见问题

如果想直接将短 ID 用于 URL 或文件名,Nano ID 更合适。如果需要 RFC 标准化的格式,或者重视与其他系统的互操作性,UUID(尤其是 v4)是更稳妥的选择。

在默认的21个字符、64种字符的设置下,具有相当于126位的随机性,实际使用中的碰撞概率几乎可以忽略。计算得出,碰撞概率达到50%所需的生成数量约为1.09×10¹⁹个。

可以,但和 UUID v4 一样是完全随机的,因此插入 B-Tree 索引的效率不如 AUTO_INCREMENT。如果需要按插入顺序排序,建议考虑使用开头带时间戳的 ULID 等方案。

是的。即使长度相同,字符集大小(字母表大小)越小,随机性越低(抵御碰撞的能力也越弱)。若要用仅数字(10种字符)达到与64种字符字母表相同的安全性,需要更长的字符数。
工具君

闲话 ― 为什么 Nano ID 能比 UUID 更短

Nano ID 是 PostCSS 的开发者 Andrey Sitnik 于2017年发布的 JavaScript ID 生成库。它没有依赖项,代码量仅有几百字节,却使用密码学安全的随机数,这种设计获得了广泛认可,如今在 npm 上每周下载量达数千万次,成为常用库之一。

ID 的长度取决于所用字符集的大小。UUID 仅使用十六进制(16种字符)来表示128位,因此需要36个字符;而 Nano ID 使用64种字符,仅用21个字符就能表示相当程度的随机性(默认设置下为126位)。这是因为每个字符所携带的信息量(log₂64=6位)大于十六进制(log₂16=4位),这正是缩短长度的原因。

默认设置(21个字符、64种字符)所具有的126位随机性,与 UUID v4 的122位几乎相当。根据生日问题的近似公式计算,碰撞概率达到50%所需的生成数量约为1.09×10¹⁹个,实际使用中几乎无需担心。