ID 内嵌时间解析

功能

• 认 UUID（v1/v3/v4/v5/v6/v7/v8）、ULID、MongoDB ObjectId、Snowflake ID、Windows FILETIME
• 把内嵌时间换算成 ISO 8601 日期，并给出位布局的说明
• ⚠️ UUID v1 的时间戳在字符串里是乱序的（低 32 位在前、高 12 位在后），按顺序读会得到一个完全错的数 —— 这一处单独处理
• ⚠️ Snowflake 用 BigInt 解析：64 位整数超过 2^53 之后 Number 会丢掉低位的序号，而时间戳（高位）看着没事，错误不会暴露
• ⚠️ Snowflake 的起算点显式可选（Twitter / Discord / Instagram / Unix 纪元），并在结果里说明它的影响
• ⚠️ ULID 会查那条最常被漏掉的合法性规则：首字符只能在 0–7 之间（130 位编码里多出的 2 位必须是 0，超过就溢出 128 位）。只查长度与字符集的校验器会放它过去，解出一个几十年后的年份
• 小写或含 I / L / O 的 ULID 按 Crockford 的歧义规则收回来（I、L 当 1，O 当 0），并标明这不是规范写法
• ObjectId 的三个字段分开列出：4 字节秒、5 字节进程随机值、3 字节计数器 —— 同一秒内的先后要看计数器那 6 个字符
• v4 这类不含时间的类型明确说「不带时间」，而不是留空
• 一次贴多行，按行分组

使用方法

1. 把一个或多个 ID 粘进去，一行一个
2. 如果是 Snowflake，先在选项里对准它的起算点
3. 结果给出识别到的类型、内嵌时间与位布局说明

常见问题

Snowflake 的起算点为什么不是统一的？

因为 Snowflake 是一套位布局（时间戳左移 22 位、低 10 位做机器号与序号），而不是一个标准格式 —— 各家自己选了起点。Twitter 用 2010-11-04，Discord 用 2015-01-01，Instagram 用 2011-08-24。同一个数字在这些假设下都能算出一个「看起来完全合理」的日期，而且不会报错，所以这里要求你显式选，并把选的是哪个写在结果里。

UUID v7 和 v4 有什么区别？

v4 完全是随机的，没有任何结构；v7 的前 48 位是 Unix 毫秒，所以它按生成时间有序。这个差别在数据库里很实在：v4 做主键会让 B 树的插入点散布在整个索引上，而 v7 是近似顺序写入。代价是 v7 会泄露创建时间 —— 如果那属于隐私，就不该用 v7。

UUID v1 的时间戳为什么不能按顺序读？

因为规范把 60 位的时间戳拆成了三段，而低 32 位放在了最前面：字符串里依次是 `time_low`（32 位）、`time_mid`（16 位）、然后是挤着版本号的 `time_hi`（12 位）。按顺序当整数读会得到一个完全错的值 —— 而它看起来依然像个合理的时间，不会报错。v6 存在的意义就是把这三段重排成「高位在前」。

ObjectId 和 Snowflake 都带时间，有什么区别？

ObjectId 是 MongoDB 的 12 字节值：前 4 字节是秒、接着 5 字节是进程随机值、最后 3 字节是计数器 —— 精度是秒。Snowflake 是 64 位整数，时间戳精确到毫秒，剩下的位分成机器号与序号。所以同一个毫秒内产生的两条 ObjectId 无法从 ID 本身区分先后，而 Snowflake 可以。