X（Twitter）雪花 ID 解码器

介绍

X 上的每一则推文都带着一个数值 ID，而这个数字并非随机。自 2010 年 11 月起，X 以雪花格式构建推文 ID — 一个 64 比特整数，把精确的发文时间、生成机器的识别码与序号计数器打包成一个可排序的数字。Toollect 的 X（Twitter）雪花 ID 解码器负责拆开这个数字：粘贴推文 ID 2089759704335482961，它就回传精确的发文时刻 — 2026 年 8 月 18 日 17:01:54.028 UTC — 连同机器编号、序号，以及该 ID 完整的二进制结构。

改贴完整的推文链接也一样好用 — 解码器会先从 URL 抽出 ID，所以 https://x.com/jack/status/2089759704335482961 与裸数字产出完全相同的结果。无论哪种方式，输入的同时就会浮现八个结果列 — 四列说明何时（当地时间、UTC、ISO 8601 与 Unix 毫秒，另附简洁的相对时间），三列说明比特说了什么（机器 ID、序号与完整 64 比特二进制）。

解码是纯粹的比特运算，不是查表。不向 X 送出任何数据、不需 API 密钥、没有速率限制 — 运算在你输入的同时于浏览器内完成，同一个 ID 在世界任何角落、永远解码到同一个瞬间。

使用场景

一个偷偷记下自己出生时刻的数字，派得上用场的场合比想像中多。

新闻查证与事实核查

截屏、转贴与引用都会把推文从原本的时间脉络里剥离。解码 ID 就能把脉络还原 — 创建的精确毫秒写在数字里面，不受周围页面说法的影响。查证人员用它判定推文早于或晚于其所谈论的事件 — 不同于周围的文字，ID 事后无法修改。

数据分析与文件库

按数值排序 ID 就等于按时间排序推文 — 根本不需要时间戳字段。从 API 或数据集导出推文 ID 的分析师，用解码器把这些 ID 锚定到日历日期、揪出收集缺口，并为「同一条推文经由多种 URL 形状抵达、却始终带着同一个数字」的文件库去重。

审核与研究

巡查一波活动时，相对时间列立刻给出规模感 — 是几分钟前还是几个月前 — 不必逐条朗读时间戳。研究删除模式或转发行为的研究员，靠解码 ID 区间重建已不再公开存在的时间轴。

开发者与集成

保存推文 ID 的代码在开发阶段常需要健全性检查 — 这个常数真的是合理的推文 ID 吗？它宣称的又是哪个时刻？把值贴进这里，一次按键就有答案；拷贝 ISO 输出，直接落进日志、测试夹具或数据库种子。

工作原理

工具随输入实时运行 — 没有按钮可按。每一次击键都走过同样的四个步骤：

1. 分类输入 — 文字与两种形状比对：15 到 19 位数的裸雪花，或携带雪花的 x.com／twitter.com 推文链接。其他一切显示无效输入消息。
2. 抽取 ID — 对 URL 而言，除了 status 路由与数字以外的一切都被忽略：子网域、/photo/1 之类的查看变体、查找参数永远碰不到表达式。
3. 解码比特 — BigInt 位移把时间戳、机器与序号从 64 比特整数中拉出来，再加上 Twitter 纪元把原始偏移换算成真正的日期（算式详见「解码的原理」一章）。
4. 验证时间窗 — 解码结果落在未来超过一分钟的 ID 会被拒绝而非显示，让手滑或凭空捏造的数字轰然失败，而不是自信满满地端出一个荒谬的日期。

一切都以远低于一毫秒的速度在本地发生。验证时间窗是整条管线唯一的判断，而且倾向拒绝 — 一个声称明天才发文的数字，不是推文。

支持的输入格式

只有两族输入会被解码，其余一律以清楚的消息拒绝。契约刻意收窄 — 本工具只对一种数字做一件事。

接受的格式

两个网域 — x.com 与 twitter.com — 在所有主机形式下行为完全一致，https:// 前缀可有可无，尾随斜线、照片或视频变体与查找字符串一律容忍后丢弃。无论以什么形状抵达，抽出的都是同一个 ID — 因此解码输出在表格七列之间逐字节一致。

拒绝的格式

有两个拒绝值得解释。网页版路由 x.com/i/web/status/… 出现在单页客户端内部改写网址的时候，但它省略了用户名段落，不符合上面的文法 — 改贴正准形式，同一个 ID 即可正常解码。另外请留意最后一列 — Discord 的 ID 能通过长度检查、并解码成看似合理的日期。解码器无法侦测它，这个极限是被诚实记载的，不是被粉饰掉的。

雪花 ID 的解剖

雪花是一个切成四个字段的 64 比特整数。从最高有效比特读起：

纪元

时间戳不是从 1970 年起算 — 而是从 2010 年 11 月 4 日 01:42:54.657 UTC 起算，雪花服务正是在那一刻取代了连续编号。选一个新鲜的纪元让时间戳字段保持娇小 — 41 比特容得下约 2.2 兆毫秒，约 69.7 年的余裕。因此格式要到 2080 年 7 月才会用尽 — 遥远得令人安心，也是「不能在不弄坏所有既有客户端的前提下拓宽该字段」的原因之一。

一个完整演算的范例

拿本站所有 X 工具通用的那个 ID — 2089759704335482961。沿字段边界切开，解码器印出的每个值一眼就能读出：

时间戳列开头的那颗零，是恒为零的符号比特。所有输出列都导自这唯一的一次切分 — 时间戳比特化为发文瞬间，机器字段指名第 376 号机器，序号则显示这是那台机器在那个毫秒里铸出的第 81 个 ID。

装得下多少 ID

12 比特的序号允许每台机器每毫秒最多 4,096 个 ID，10 比特的机器字段最多指名 1,024 台机器。实务上序号很少逼近天花板 — 它的存在是为了让爆量请求永不碰撞，而不是为了总量。同一台机器在同一毫秒产生的两个 ID，只差在这十二个低比特。

位数年表

因为时间戳占据高位比特，总值稳定增长 — 十进位位数大致能告诉你一个 ID 是何时铸造的：

这正是解码器只接受 15 到 19 位数的原因 — 15 位涵盖雪花时代最早期的一批推文，19 位涵盖 2018 年以来铸造的一切，而合法的推文 ID 从未落在这个区间之外。

解码的原理

整套数学是三个操作 — 一次位移、两次遮罩、一次加法：

const TWEET_EPOCH = 1288834974657n;           // 2010-11-04T01:42:54.657Z，以 Unix ms 表示

timestampMs = Number((id >> 22n) + TWEET_EPOCH);
workerId    = Number((id >> 12n) & 1023n);    // 中段字段的低 10 比特
sequence    = Number(id & 4095n);             // 低 12 比特

右移 22 比特丢掉机器与序号字段，留下自专属纪元起的时间戳偏移；加上纪元便化为普通的 Unix 毫秒。遮罩接着分离两个低位字段 — & 1023 保留十个比特，& 4095 保留十二个。把范例再算一遍：2089759704335482961 位移后得到 498237539371 毫秒的偏移，加纪元等于 1787072514028，即 2026-08-18T17:01:54.028Z；遮罩后的机器为 376，序号为 81。

两个精度细节很重要。第一，工具全程使用 BigInt 运算 — 19 位数的 ID 超出 JavaScript 的安全整数范围（9,007,199,254,740,991），普通数字会悄悄舍入低比特，坏掉的恰恰是工具所报告的机器与序号值。第二，转换之后的时间戳绰绰有余地落在安全范围内，因此以普通数字交给 Date 显示毫无损失。

还有一件值得知道的事 — 其他平台对同样的低 22 比特有不同的切法，通用型解码工具常用别家系统的字段名来标注：

如果有工具把你的推文 ID 分成 workerOrShard 和 processId 展示，那是把 Discord 的标签套在 X 的比特上 — 数字算得出来，但推文没有进程字段，低十二位是序号计数器，不是进程识别码。本解码器坚守 X 实际定义的字段。

使用方法

四个步骤，不用按任何按钮：

1. 粘贴输入 — 裸推文 ID，或上述任一形状的 x.com／twitter.com 推文链接。
2. 阅读时间组 — 当地时间、UTC、ISO 8601 与 Unix 毫秒即刻填满，相对时间列一眼给出年代感。
3. 阅读结构组 — 机器 ID、序号与分组二进制展示这个数字的建造方式。
4. 拷贝所需内容 — 每列都有专属拷贝按钮；ISO 列干净地落进试算表与日志。

无效输入清空各列并显示一行错误；修正输入后错误同样自动消失。

教程

跟着一则解码从头走到尾。

步骤 1 — 解码裸 ID。 把 2089759704335482961 贴进输入框。时间组立即填满 — ISO 列 2026-08-18T17:01:54.028Z、Unix 列 1787072514028 — 结构组报告机器 376、序号 81，二进制分成 42/10/12 三组。

步骤 2 — 从完整链接解码。 清空输入，粘贴 https://x.com/jack/status/2089759704335482961?s=20&t=abc。追踪参数什么也改变不了 — 只有 status 路由和 ID 存活于抽取，每一列读起来都与步骤 1 相同。

步骤 3 — 确认网域独立性。 粘贴 https://www.twitter.com/someone/status/2089759704335482961/ — 旧网域加用户名前缀加尾随斜线。同一个 ID、同一个时间戳。无论链接怎么到你手上，藏在其中的数字才是唯一的真相来源。

步骤 4 — 看不可能的 ID 失败。 粘贴 20 — 史上第一条推文的 ID，来自雪花格式之前的时代。解码器拒绝它 — 两位数载不动编码时间戳，因为这个 ID 的发行比格式的诞生早了好几年。这个拒绝是正确行为，不是 bug。

步骤 5 — 把输出带到有用的地方。 点 ISO 列的拷贝钮，贴进试算表保存格 — 2026-08-18T17:01:54.028Z 作为文字即可按时间排序，经得起 CSV 反复进出，解读时不需要任何时区背景。

专业提示

• 按 ID 排序就是按时间排序。 无论推文 ID 住在哪一栏 — 导出档、数据库、日志 — 按 ID 排序即是按年代排序。解码器帮你替这个顺序粘贴真实日期的标签。
• 存盘优先选 ISO 列。 当地时间取决于读者的设备设置；带 Z 尾码的 ISO 8601 在任何地方都无歧义，且作为纯文字即可正确排序。
• 跨时区团队用 UTC。 当文件库横跨各大洲，约定好以 UTC 列为准，就不会有人争论推文是否跨过了午夜。
• 快速分诊看相对时间列。 巡一批 ID 时，紧凑的年代感 — 3h、2d、5mo — 比读完整日期更快把新鲜货与老古董分开。
• 二进制列是教材。 让同事亲眼看到哪些比特正是时间戳，比任何图解都快点通整个格式。
• 与链接解析器配对。 解析器清理并正准化链接；解码器为它们定年。同一条推文链接跑过两个工具，你会带着整齐的 URL 和一枚经过验证的时间戳离场。

替代方案

推文 ID 还有哪些途径可以变成日期？

手动解码意味着二的幂次与冗长的二进制链 — 做一次可以，永远做很折磨，滑掉一个比特日期就完蛋。通用在线解码器往往以 Discord 为首要目标，把 X 的字段标错、有时连纪元都用错，而且常把 ID 送上一台服务器。本工具在本地运行精确运算、按 X 的定义标注字段，并拒绝不可能的输入 — 而非自信满满地秀出一个错误年份。

与官方 API 对比

读取创建时间属于少数官方途径反而严格更差的任务：

2026 年 2 月起，X 的 API 改为按用量付费且无免费额度 — 取得哪怕一条推文的 created_at 都要花钱，还需要注册的凭证。oEmbed 回传的是嵌入用的渲染 HTML，没有可靠解析的结构化时间戳字段。雪花运算免费、脱机、永久地交付同一个毫秒 — 代价是它对数字之外的一切保持沉默，而这正是下方记载的界线。

解码器 vs. 链接解析器

Toollect 有两款都读推文链接、都认得雪花 ID 的 X 工具。它们回答的是不同的问题：

解析器是链接的通才；解码器是数字的专家。它接受完整 URL 是一种便利 — 一旦某条链接需要清理、誊写或解释，那就是解析器的领地，两个工具在 ID 这一站干净地交接棒。

它不做的事

这些极限值得一一点名，免得解码器被过度信任：

• 它不抓取任何东西。 零请求 — 工具看不到推文是否还存在、谁写的、写了什么。ID 只能给出出生那一刻烤进去的东西。
• 它无法反转换。 把日期转回 ID 会捏造出一个从未被任何推文领走的数字 — 打开 x.com/i/status/{捏造}，X 会回答页面不存在。合成 ID 只在旧免费 API 的分页阈值里有用武之地；在今天的网页上，日期搜索操作符直接就把这件事做了。
• 它无法区分平台。 Discord 的雪花共用同一套结构、在此无错解码 — 但落在早了约四年的日期上，因为 Discord 从 2015 年起算。如果输入来自其他平台，请把输出当作天生就是错的。
• 它不解码 2010 年以前的 ID。 比雪花服务更老的推文，携带的是没有内嵌时钟的小连续编号 — 字面上就没有任何东西可供解码。
• 它不猜。 与所有接受形状都不相符的输入，会显示错误消息而非部分结果。

故障排除

隐私与数据处理

本解码器采用全站最严格的隐私模型 — 完全不发出任何网络请求。

• 不上传任何东西。 解码是你浏览器里的比特运算。你粘贴的 ID 或链接永远不会抵达任何服务器。
• 无账号、无分析追踪、无第三方脚本。 页面只运行自己的代码。
• 不保存任何东西。 没有 Cookie、没有跨浏览的状态 — 关掉标签页，本次作业就此消失。

对涉及私人文件库、研究数据集或审核队列 ID 的工作流程而言，解码完全在你的设备上完成。

技术规格

细节：

• 格式 — 64 比特雪花 — 符号（1 比特）+ 时间戳（41 比特，自 2010-11-04T01:42:54.657Z 起的毫秒）+ 机器（10 比特）+ 序号（12 比特）
• 精度 — 全程 BigInt 运算；对超出 JavaScript 安全整数范围的所有 19 位 ID 皆精确
• 验证时间窗 — 解码结果最多只能超前目前时间 60 秒；早于纪元的值在 15 位以上根本不可达
• 输入格式 — 裸 \d{15,19}，或带任意协定、www.／mobile.／m. 子网域、查看变体与查找字符串的 x.com／twitter.com 推文 URL
• 输出 — 当地时间、UTC 字符串、ISO 8601、Unix 毫秒、相对时间、机器 ID、序号、分组 64 比特二进制 — 每列皆可个别拷贝
• 处理 — 100% 客户端 JavaScript、零网络请求、无 API 密钥、无服务器组件
• 浏览器支持 — 所有现代浏览器（BigInt 与 Clipboard API）

功能特色

• 将任何 X 或 Twitter 雪花 ID 解码为精确到毫秒的发文时间
• 同时接受裸推文 ID 与完整的 x.com／twitter.com 推文链接 — ID 自动抽取
• 以四种形式呈现解码后的时刻 — 当地时间、UTC、ISO 8601 与 Unix 毫秒
• 将 ID 拆解为组成部分 — 机器 ID、序号计数器与完整 64 比特二进制
• 拒绝不可能的值 — 落在未来的 ID 显示错误而非瞎猜
• 完全在浏览器内运行，零网络请求 — 不需 API 密钥与账号
• 每个结果列皆可一键拷贝

常见问题