UDID、UUID、ULID 和 NanoID 的使用 Better

背景

项目登录注册需求开发。后端的图片验证码接口、注册接口、登录接口均需要提供一个唯一标识符。

UDID：Unique Device Identifier（设备唯一标识符）

从名称上也可以看出，UDID这个东西是和设备有关的，而且是只和设备有关的，有点类似于MAC地址。真机调试，然后需要把UDID这个东西添加到Provisoning Profile授权文件中，也就是把设备唯一标识符添加进去，以此来识别某一台设备。 UDID是一个40位十六进制序列，我们可以使用iTunes和Xcode来获取这个值。

UUID：Universally Unique Identifier（通用唯一标识符）

UUID 目前有 5 个版本：

版本1：在许多环境中是不切实际的，因为它需要访问唯一的，稳定的MAC地址，容易被攻击；
版本2：将版本 1 的时间戳前四位换为 POSIX 的 UID 或 GID，问题同上；
版本3：基于 MD5 哈希算法生成，生成随机分布的ID需要唯一的种子，这可能导致许多数据结构碎片化；
版本4：基于随机数或伪随机数生成，除了随机性外没有提供其他信息；
版本5：通过 SHA-1 哈希算法生成，生成随机分布的ID需要唯一的种子，这可能导致许多数据结构碎片化；

这里面常用的就是 UUID4 了，但是，即使是随机的，但是也是存在冲突的风险。
和 UUID 要么基于随机数，要么基于时间戳不同，ULID 是既基于时间戳又基于随机数，时间戳精确到毫秒，毫秒内有1.21e + 24个随机数，不存在冲突的风险，而且转换成字符串比 UUID 更加友好。

npm i uuid --save

const uuidv4 = require('uuid/v4');

// 生成一个理论上不重复的128位16进制表示的数字
uuidv4(); // 0d90c8ac-7c21-486a-a132-39177211d1d4

// 原生获取
const uuid = URL.createObjectURL(new Blob()).substr(-36)
// 相对与引入一整个库来说节约更多的资源, 但高并发等特殊场景下可能不保证唯一性

ULID：Universally Unique Lexicographically Sortable Identifier（通用唯一词典分类标识符）

特性：

• 与UUID的128位兼容性
• 每毫秒1.21e + 24个唯一ULID
• 按字典顺序(也就是字母顺序)排序！
• 规范地编码为26个字符串，而不是UUID的36个字符
• 使用Crockford的base32获得更好的效率和可读性（每个字符5位）
• 不区分大小写
• 没有特殊字符（URL安全）
• 单调排序顺序（正确检测并处理相同的毫秒）

使用：

npm i ulid

import { ulid } from ‘ulid’;
ulid();

/*
01FHZXHK8PTP9FVK99Z66GXQTX
时间戳 (48 bits) - 01FHZXHK8P
随机数 (80 bits) - TP9FVK99Z66GXQTX
*/

NanoID

使用：

npm i nanoid

import { nanoid } from 'nanoid';
model.id = nanoid();

参考

http://t.zoukankan.com/hero11223-p-6757311.html ios udid
https://blog.csdn.net/pushiqiang/article/details/117365290
https://juejin.cn/post/7070775470974828580#comment
https://juejin.cn/post/7039960318897815565 NanoID
https://zhuanlan.zhihu.com/p/472060150 NanoID