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 金鑰與帳號
• 每個結果列皆可一鍵複製

常見問題