開発者ツール · UUID ジェネレーター
UUID を手動で読み取る: バージョンとバリアント ビットが存在する場所
· 仕組み
uuid 暗号化 ブラウザ API
各 UUID 内の 2 つの 16 進数文字は、どのバージョンで生成されたか、どのバリアント レイアウトに従っているかを示します。一目でそれらを読んで、何が伝えられないのかを知る方法を学びましょう。
この ID を作成したのはどのシステムですか? — バージョンニブルが答えることができるログフォレンジックの質問
UUID 文字列には 36 文字が含まれます。つまり、8-4-4-4-12 の位置に 32 桁の 16 進数字と 4 つのハイフンが含まれています。各 UUID 内の 2 文字 (14 および 19 の位置に表示されます) は、メタデータをエンコードします。バージョン フィールドは、ID を生成したアルゴリズムを示し、バリアント フィールドは、どの標準レイアウトに従っているかを示します。ツールを使わずにこれら 2 つの文字を読み取ることは、ログ フォレンジックのスキルです。つまり、データベース ダンプまたはエラー メッセージで UUID を見つけ、それが v1 タイムスタンプ (作成時間の漏洩) なのか、v4 ランダム値 (CSPRNG から生成されたもの) なのか、あるいはその他のものなのかを即座に知ることができます。バージョン番号は、UUID のビット 48 ～ 51 を占め、3 番目のグループの最初の 16 進文字にマップされます。
5 つのグループの 128 ビット レイアウト - 8-4-4-4-12 がバイトにどのようにマッピングされるか、およびグループが機能的ではなく履歴的なものである理由
文字列 xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx の場合、14 の位置にある文字がバージョンです。 RFC 9562 では、バージョン 1 から 8 までを定義しています。v1 はグレゴリオ時間ベースであり、作成時間がリークします。 v4 はランダムです。 v7 は Unix 時間ベースであり、ソート可能です。バージョン 0、9 以降は予約または未使用です。 v1 UUID が表示されている場合は、時刻とハードウェア アドレスが混在していることがわかります。 v4 が表示される場合、ID はバージョン ビットが設定されたランダムなバイトです。 v7 が表示される場合は、作成時間順に並べ替えられます。バージョンはオプションではありません。正しく形成されたすべての UUID には 1 つがあります。バリアント フィールドは、UUID のビット 64 ～ 65 (オクテット 8 の最上位 2 ビット) を占めます。
バージョン ニブル — 3 番目のグループの最初の文字、1 ～ 8 の意味、およびそこにある 0 または 9 が何を示すか
テキスト表現 xxxxxxxx-xxxx-xxxx-Nxxx-xxxxxxxxxxxx では、4 番目のグループの最初の文字 (19 位置) がバリアントをエンコードします。 RFC 9562 バリアント (最近使用されている標準) の場合、この文字は 8、9、a、または b (バイナリでの 1000、1001、1010、および 1011 の 16 進表現) である必要があります。他の文字 (0 ～ 7、c ～ f) は、別のバリアントを示します。 0 ～ 7 は NCS 下位互換性があります。 c ～ d は、リトルエンディアンのバイトオーダーを持つ Microsoft のレガシー GUID です。 e～fは予約済みです。位置 19 を読んで 8、9、a、または b が表示される場合は、RFC 9562 UUID を見ていることになります。他の値は、バイトが異なる解釈に従うことを意味します。 128 ビット レイアウトは、オクテット 0 ～ 15 に分割されますが、テキスト形式では、機能ではなく読みやすさのためにグループごとに分割されています。
バリアント フィールド - 4 番目のグループの最初の文字が 8、9、RFC UUID の場合は a または b である理由、および c/d (Microsoft レガシー) または 0–7 (NCS) シグナル
5 つのグループは履歴フィールド境界を表します。最初の 3 つのフィールドには v1 UUID のタイムスタンプとバージョンが含まれ、4 番目のフィールドはクロック シーケンスとバリアントを保持し、5 番目のフィールドはノード識別子を保持します。バージョン 4 以降の UUID バージョンではこれらのフィールド名は使用されませんが、同じビット位置にバージョンとバリアントが含まれています。 v4 UUID を読み取ることは、128 ビットの大部分がランダム ペイロードであることを受け入れることを意味しますが、そのうちの 2 つ (テキスト内の 14 と 19 の位置) は標準で固定されています。これらの固定ビットは、ID が v4 および RFC バリアントであることを証明します。 nil UUID は 00000000-0000-0000-0000-000000000000 で、すべてゼロであり、バージョンはまったく保持されません。最大 UUID は ffffffff-ffff-ffff-ffff-ffffffffffff (すべて f 文字) であり、予約されておりバージョン管理されていません。
実用的な例 — v4 と v7 を含む 3 つのサンプル識別子を 1 文字ずつデコードする
整形式の UUID には、3 番目のグループにバージョンがあり、4 番目のグループにバリアントがあります。 3 つのサンプル ID を使用して自分自身をテストしてください: 123e4567-e89b-12d3-a456-426614174000 (v1、位置 19 が a であるためバリアント RFC)。 9b2e4f1a-4f3e-4c1a-8a7d-1b2c3d4e5f60 (v4、位置 19 が 8 であるため、バリアント RFC); 018f0c2e-1b5a-7c3d-9e4f-5a6b7c8d9e0f (v7、位置 19 が 9 であるため、バリアント RFC)。 ToolAcre インスペクターが読み取り値を確認します。形式チェックでは、ID が一意であるか、データベースに存在するか、安全に生成されたかを判断できません。バージョン v1 は時間とハードウェアを入力として使用するため、異なるマシンからの同一の v1 UUID はクロック スキューまたは同期の問題を意味します。バージョン v4 はランダムであるため、重複した v4 UUID は、ランダム性が壊れているか、天文学的に起こりそうもない衝突を意味します (およそ 2 ごとに 1 つ。健全なランダム性を持つ 7 兆個の UUID)。
Nil と Max — バージョンをまったく持たない、すべて 0 とすべて F の 2 つの値
バージョン 0 または 9 は、文字列が有効な UUID ではないことを意味します。バージョンとバリアントを読むことは、ID が何であるかを理解するための第一歩です。存在するか一意であるかを確認するのは 2 番目と 3 番目のステップで、データベースとビジネス ロジックによって実行されます。ビット位置を理解すると、データ移行のデバッグに役立ちます。レガシー システムから UUID をインポートする場合、一部のツールは、RFC 9562 標準に一致しないバリアント フィールドをエクスポートします。 c または d のバリアント フィールドは、リトル エンディアン バイト オーダーの Microsoft GUID を示します。これらの GUID は Microsoft システム内で有効な識別子ですが、バイトオーダー変換を行わないと RFC 9562 UUID と相互運用できません。位置 19 を読み取ると、どのシステムが ID を生成したかがすぐにわかります。 8、9、a、または b が表示される場合は、RFC 標準 UUID が適用されています。
形式チェックでは分からないこと — ID がデータベースに存在するか、ID が安全に生成されたか、または固有であるか
c または d が表示される場合は、Microsoft GUID を持っています。他の文字が表示された場合、識別子の形式が間違っているか、不明瞭なシステムからのものです。 ToolAcre ジェネレーターは常に、8、9、a、または b のいずれかとして位置 19 を持つ RFC 9562 UUID を生成します。 3 ビットのバージョン フィールドは、7 つの可能な値をエンコードします (1 ～ 7、バージョン 0 と 8 には特別な意味があります)。バージョン 1 はグレゴリオ暦タイムスタンプ、バージョン 3 は MD5 ベースの名前空間、バージョン 4 はランダム、バージョン 5 は SHA-1 ベースの名前空間、バージョン 6 は Unix タイムスタンプ ベース (提案)、バージョン7 は Unix タイムスタンプ ベースの並べ替え可能 (RFC 9562 で標準化)、バージョン 8 はカスタム形式用に予約されています。 Position-14 文字を読み取ると、どのアルゴリズムが使用されたかがすぐにわかります。 UUID の衝突や予期しない並べ替えをデバッグしている場合は、バージョン番号が最初の手掛かりになります。 ToolAcre は、暗号化からのみ v4 UUID を生成します。
要点: 2 つの文字、多くのコンテキスト — ToolAcre の整形式チェックを使用して文字列が解析されることを確認し、バージョン ニブルを自分で読み取ります。
getRandomValues;生成されるすべての UUID には、14 の位置に 4 があります。 UUID 構造体を手動で解析することは、ツールが利用できない複雑なシステムをデバッグする場合に便利なスキルです。運用インシデントでは、特別なツールを実行せずに、データベース ダンプ、エラー ログ、またはキャッシュから UUID を読み取ることが必要になる場合があります。バージョンを識別するには、位置 14 を探します (リーク時間はありますか? ランダムですか? ソート可能ですか?)。バリアントを識別するには、位置 19 を探します (RFC 標準ですか? Microsoft GUID ですか? 予約されていますか?)。合計 36 個のうち、これら 2 つの文字がメタデータを運びます。残りの 34 文字はペイロード、つまりタイムスタンプ、ランダム バイト、またはその他のアルゴリズム固有のデータです。ペイロードが何を表しているのかを知ることは、システムにおける ID の役割を理解するのに役立ちます。