布局（高位→低位）：时间戳 | 机器 | 序列号，总位数需 ≤ 63。
⚠️ 解析出的时间不太合理，可能选错了平台预设。
Snowflake ID 解析器 把一个 64 位雪花 ID 反解为生成时间、机器/数据中心 ID、序列号三部分，内置 Twitter、Discord、Mastodon、Sonyflake 预设，也支持自定义纪元与位布局，并用二进制分段图直观展示每一位的归属。全程 BigInt 精确运算、本地完成、不上传。
| 平台 | 起始纪元 | 时间戳 | 机器/其他 | 序列 |
|---|---|---|---|---|
| Twitter / 通用 | 2010-11-04 | 41 bit | 5+5 bit（数据中心+机器） | 12 bit |
| Discord | 2015-01-01 | 42 bit | 5+5 bit（worker+进程） | 12 bit |
| Mastodon | Unix 纪元 | 48 bit | — | 16 bit |
| Sonyflake | 2014-09-01 | 39 bit（×10ms） | 16 bit（机器） | 8 bit |
小贴士：雪花 ID 大致按时间递增，所以可以用「某时刻对应的最小 ID」做按时间分页（如 Discord 的 before/after 游标）。
一种分布式唯一 ID 生成方案，最早由 Twitter 开源。它把一个 64 位整数切成几段：最高位固定为 0，接着是毫秒级时间戳，再是机器/数据中心标识，最后是同一毫秒内的自增序列号。这样既能保证全局唯一、又大致按时间递增，且不依赖中心化发号。
因为各家的「起始纪元」和「位分配」不同。Twitter 纪元是 2010-11-04、Discord 是 2015-01-01、Mastodon 直接用 Unix 纪元；时间戳/机器/序列各占多少位也不一致。选错预设，解析出的时间和机器位就会是错的——如果时间明显不合理（比如 1970 年或几百年后），多半是预设选错了。
雪花 ID 是 64 位整数，远超 JavaScript Number 能精确表示的范围（2^53）。直接当普通数字会丢精度、算错时间戳和序列号。本工具全程用 BigInt 做位运算，保证每一位都准确。
当你的发号器不是标准布局时使用：填入起始纪元（Unix 毫秒）、时间单位（多数为 1ms，Sonyflake 为 10ms）、以及时间戳/机器/序列各自的位数。布局按「高位→低位 = 时间戳 | 机器 | 序列号」解析，三段位数之和需 ≤ 63。
雪花 ID 里存的是 UTC 毫秒时间戳，与时区无关。工具顶部"生成时间"按你浏览器所在时区显示，同时给出 UTC、ISO 8601 和原始 Unix 毫秒/秒，方便你按需取用。
不会。ID 解析、位运算、时间换算全部在浏览器本地完成，不发起任何网络请求，贴敏感业务 ID 也放心。