01
発行方式を先に確認
Twitter原版はsnowflake-2010の保存コードに対応します。Discordには符号なしの公式形式を使います。独自方式ならカスタムを選び、サービス側の仕様からエポックと各ビット数を転記してください。
IDと生成時刻
Snowflake IDデコード
数字を読む前に、発行元のレイアウトを選んでください。
Snowflake IDデコード
十進Snowflake ID
結果レポート
IDの計算はブラウザ内で行い、入力は送信しません。
設定
十進IDを一つ、256文字以内で入力。URLや一覧は使えません。
Twitter snowflake-2010：41/5/5/12。ノードの上位はデータセンター、下位はworker。予約符号ビットは0。 出典を見る
IDを入力するか例を読み込んでください。
ログにIDしか残っていないとき、Snowflake IDデコードで埋め込まれた時刻を調べられます。ただし数字だけでは発行元のエポックは分かりません。もっともらしい日付が出ても形式が正しい証拠にはならないため、まず生成サービスの設定と照合してください。
Snowflake IDデコードを使う理由
エポックだけでなくビット幅も区別
Snowflake IDデコードではTwitterの保存版とDiscordを別の形式として扱います。時刻はそれぞれ41ビットと42ビットで、ノードを構成する二つの部分の名前も異なります。プリセットの出典を開いて、解釈の根拠まで確認できます。
同じテストケースを再現
時刻、ノード、連番を固定すると同じIDになります。ビットをまとめて表示するので、アプリのシフト量やマスクとの比較に便利です。独自の割り当てに切り替えれば、境界を変えた際に各フィールドがどう読まれるかも調べられます。
見落としやすい三つの前提
02
ミリ秒とノードの合成値を使う
エポックも生成時刻もUnixミリ秒です。プリセットのノード値は上位部分×32＋下位部分。Twitterではデータセンターとworker、Discordではworkerとprocessに相当します。
03
更新完了を待って保存
自動デコードは編集が止まってから350ミリ秒後に実行します。オフにするとボタンまたはCtrl/Cmd + Enterで実行できます。変更直後は古い結果のコピーを無効にし、テスト生成は常に手動で行います。
時刻と各フィールドを確認
末尾の連番も正確に読む
Snowflakeデコーダーは十進文字列をBigIntとして処理します。Discordの175928847299117063は2016-04-30T11:18:25.796Z、ノード32、連番7です。通常の浮動小数点で同じ値に丸められる隣接IDも区別できます。
時刻とビットを並べて確認
タイムスタンプはUTC、Unixミリ秒、エポックからの経過時間を表示します。二進表現は先頭のゼロを保持し、時刻・ノード・連番ごとに区切ります。Twitterの予約符号ビットはゼロ、Discordは64ビット全体を使用します。
カスタムエポックと幅を指定
独自設定は上位から時刻、ノード、連番の連続配置です。ノードや連番を0ビットにすると、そのフィールドには0だけを指定できます。存在しないビットに値を詰め込んで隣の欄を壊すことはありません。
固定パラメーターでテスト生成
生成時刻を指定すると再現可能なテストIDを作れます。空欄なら実行時の時計を使用します。生成直後に同じ設定で解析し、IDのコピーとレイアウトを含むJSONレポートの保存に対応します。
解析で分かること・分からないこと
- 形式の自動判定はしない
- IDにはプラットフォーム名が入っていません。誤ったエポックでも正常そうな日付になる場合があります。Twitter原版のプリセットは現在のXの全実装を保証するものではありません。
- 連続する最大64ビットが対象
- 時刻は1ビット以上、合計は64ビット以下です。秒やマイクロ秒、離れた位置のビット、順序の異なるフィールドには対応しません。自社方式の単位と並びを先に確認してください。
- 一度に十進整数を一つ
- 前後の空白と先頭のゼロは許可します。負のID、小数、指数表記、16進数、URL、複数の値は受け付けません。各数値入力は256文字までで、レポート内の整数も文字列として保存します。
- 一意なIDの発行サービスではない
- 同じ条件からは同じIDが生成されます。ノードの割り当て、永続カウンター、時計の巻き戻り対策は行いません。範囲内なら未来の時刻やゼロもテストに利用でき、実在する投稿を意味しません。
- アカウントの照会はしない
- 復元するのはフィールドの数値と時刻です。ユーザー名、本文、ノードの所在地は分かりません。APIによる実在確認はなく、Dateの表現範囲を超える時刻は切り詰めずエラーにします。
Snowflake IDデコードのよくある質問
DiscordのIDから作成日時を調べるには？
Discordを選び、元のID文字列を入力します。Snowflake IDデコードは下位22ビットを取り除いて1420070400000ミリ秒を加えます。結果はID内の時刻を示し、メッセージの存在を別途確認するものではありません。
TwitterとDiscordのエポックはどう違いますか？
Twitter原版は1288834974657ミリ秒、Discordは1420070400000ミリ秒を起点にします。時刻の幅も41ビットと42ビットで異なるため、エポックだけを入れ替えると境界の扱いを間違える場合があります。
ノードの各部分は31、連番は4095までなのはなぜ？
プリセットの各ノード部分は5ビットで0～31、合成値は10ビットで0～1023です。連番は12ビットで0～4095。上限を超える値は次のフィールドにあふれるため生成時に拒否します。
自分のサービスのエポックを使えますか？
はい。カスタムを選び、符号付きUnixミリ秒のエポックと三つのビット幅を設定します。生成時刻はエポック以降で、その差が時刻フィールドに収まる必要があります。
貼り付けたIDの末尾が変わるのはなぜ？
表計算や数値パーサーが大きな整数を丸めた可能性があります。このツールはBigIntを使いますが、入力前に失われた桁は復元できません。IDを数値化する前の文字列から取り直してください。
別のレイアウトで困っていますか？