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 ビットを超えます）。長さと文字種しか見ない検証器はこれを通してしまい、数十年後の日付を返します
• 小文字を含む ULID、または I / L / O を含む ULID は Crockford の曖昧さの規則（I・L は 1、O は 0）で復元し、正規の表記ではないことを明示します
• ObjectId は 3 つのフィールドに分けて表示します —— 4 バイトの秒、5 バイトのプロセス乱数、3 バイトのカウンタ。同じ秒の中での前後は末尾 6 文字のカウンタで判断します
• v4 など時刻を含まない形式は、空欄ではなく「時刻を含まない」と明示
• 複数行に対応し、行ごとにまとめます

使い方

1. ID を 1 行に 1 つ貼り付けます
2. Snowflake の場合は、生成時の起点をオプションで合わせます
3. 結果に判別した形式・埋め込まれた時刻・ビット配置の説明が出ます

よくある質問

Snowflake の起点が統一されていないのはなぜですか？

Snowflake はビット配置（タイムスタンプを 22 ビット左シフトし、下位ビットにマシン番号とシーケンスを置く）であって標準形式ではなく、起点は各実装が独自に決めたためです。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 ビットのタイムスタンプを 3 つに分け、下位 32 ビットを先頭に置いているためです：文字列は `time_low`（32 ビット）、`time_mid`（16 ビット）、そしてバージョン番号と同じ欄を共有する `time_hi`（12 ビット）の順です。順に整数として読むと完全に誤った値になりますが、もっともらしい時刻に見えるためエラーになりません。v6 はこの 3 つを上位ビット先行に並べ直すために存在します。

ObjectId と Snowflake はどちらも時刻を持ちますが、何が違いますか？

ObjectId は MongoDB の 12 バイト値で、先頭 4 バイトが秒、続く 5 バイトがプロセスごとの乱数、最後の 3 バイトがカウンタです —— 精度は秒です。Snowflake は 64 ビット整数で、タイムスタンプはミリ秒精度、残りのビットがマシン ID とシーケンスに分かれます。同じ秒に発行された 2 つの ObjectId は ID 自体から前後を判別できませんが、Snowflake は判別できます。