開発者ツール · UUID ジェネレーター
UUID バージョン 1 ～ 8 の説明: どちらを生成する必要がありますか?
· 背景
uuid 暗号化 ブラウザ API
8 つのバージョンは 1 つの形式を共有していますが、時間順序、再現性、ランダム性、カスタム レイアウトなどのさまざまな問題を解決します。この投稿ではそれぞれを説明し、決定経路を示します。
1 つのフォーマット、8 つのレシピ — ライブラリ関数を選択するときにバージョン ニブルが重要な理由
UUID 標準では、128 ビット形式をハイフンを含む 36 個の 16 進文字として定義しています。 RFC 9562 は、これらのビットを異なるパターンと意味で埋めるための 8 つの異なるレシピ (バージョン 1 から 8) を定義しています。バージョン ニブル (3 番目のグループの最初の文字) は、どのメソッドが値を生成したかを識別し、ラベルとして機能します。間違ったバージョンを選択すると、不要な一時情報が保存されたり、データベース パフォーマンスの順序保証が欠落したり、識別子のセキュリティ ロールが誤解されたりすることになります。この投稿では、各バージョンを説明し、開発者が実際にそのバージョンに遭遇したときにどのような具体的な問題を解決するのかを説明し、特定のシステム要件に適したバージョンを選択するための意思決定の枠組みを提供します。
v1 および v6: 時間プラスノード — 元の時間ベースのレイアウトと正しく並べ替えられた再順序付けされたバージョン
バージョン 1 では、60 ビットのタイムスタンプとノード識別子 (元は MAC アドレスですが、最新の実装ではハードウェア情報の漏洩を避けるためにランダムな値が使用されています) が結合されます。タイムスタンプは、10 月 15、1582 以降の 100 ナノ秒間隔を記録します。ノード フィールドは、識別子がいつ生成されたか、地理的にどこで生成されたかを明らかにすることができるため、最新の実装では MAC アドレスが回避されます。バージョン 6 は、同じタイムスタンプとノード情報を再配置して、上位の時間ビットを前に移動することで並べ替え可能性を向上させ、v6 UUID が辞書編集順に正しく並べ替えられるようにします。アプリケーションが、優れたインデックス局所性を備えて作成時間によって自然にソートされる UUID を必要とする場合、v6 が最新の選択肢となります。
v2: DCE セキュリティ — POSIX 識別子を埋め込む、めったに使用されないバリアント
バージョン 2 は、新しいシステムではほとんど使用されません。 POSIX ユーザーまたはグループの識別子を UUID レイアウトに埋め込むため、これらの識別子が組織的な意味を持つ従来の環境でのみ役立ちます。 v2 の設計は、最新の分散システムでは珍しい特定のコンピューティング モデル (DCE セキュリティ) を前提としています。ほとんどの組織は、ユーザー ID を識別子自体にエンコードするのではなく、データベース結合またはルックアップ テーブルを通じてアプリケーション層で UUID をユーザーまたはグループに関連付けます。この懸念の分離により、承認モデルの変更、ユーザー データの移行、監査証跡の維持が容易になります。資格情報を UUID に直接エンコードすると密結合が生じ、システムの進化が困難になります。
v3 および v5: 名前ベース — 名前空間と MD5 または SHA-1 を使用した名前からハッシュされた決定的な ID
バージョン 3 および 5 UUID は決定的です。同じ名前空間と名前は常に同じ識別子を生成するため、外部データからの安定したマッピングを表すのに最適です。バージョン 3 は MD5 を使用し、バージョン 5 はハッシュ アルゴリズムとして SHA-1 を使用し、それぞれの年齢と採用状況を反映しています。顧客レコードがインポートのために到着すると、固定名前空間から派生した v5 UUID は複数のインポート実行にわたって同一となり、レコードの重複を防ぎます。この決定論は、UUID が再現可能であり、名前空間と入力を知っている人であれば誰でも予測できることを意味します。実用的な価値は、複数のシステムからの顧客レコードの照合、定期的なインポートでの重複の防止、アイテムへの安定した ID の割り当てなどのデータ統合シナリオで発揮されます。
v4: ランダム — CSPRNG からの 122 ビット、および注文時のデフォルトの選択は重要ではありません
バージョン 4 は、順序付けが必要なく、中央調整なしで独立した生成が必要な場合のデフォルトの選択です。 v4 UUID は、暗号的に安全なランダム ソースからの 122 ビットで構成され、6 ビットが固定値に設定されています (バージョン ニブル 4 および RFC 9562 バリアント ビット 10)。重要なのはランダム性です。呼び出しごとに異なる値が生成され、衝突の可能性はほとんどなく、外部の状態や調整は必要ありません。これは、ToolAcre が crypto.randomUUID() または crypto.getRandomValues() を使用して生成するバージョンです。このバージョンは、オブジェクト参照、非構造化データ、および主キーや並べ替えコンテキスト以外のほとんどのロールに適しています。
v7 および v8: Unix 時間およびカスタム — データベース キーの最新の時間順バージョンと特注レイアウトのエスケープ ハッチ
バージョン 7 は、RFC 9562 で標準化されており、最新の時間順プロパティを UUID 形式に取り込みます。これは、48 ビットの Unix ミリ秒タイムスタンプ、ミリ秒未満の精度の 12 ビット、および 62 ランダム ビットの組み合わせを使用します。 Unix ミリ秒タイムスタンプは 10889 年まで有効であるため、システムに適しています。結果は辞書編集順に正しく並べ替えられ、特別な処理やエンコード変換を行わなくても、標準の 128 ビット UUID 列に収まります。アプリケーションで、標準の UUID 形式内で作成時間によって並べ替える識別子が必要な場合は、v7 が現在のベスト プラクティスです。バージョン 8 は実装定義フォーマットの標準化された包括的なもので、v1 ～ v7 でカバーされていない特定のビット レイアウトが必要な場合にのみ役立ちます。
実用的な例 — パブリック API リファレンス、主キー、インポートされたレコードの安定した ID の 3 つのシナリオに適用される意思決定パス
3 つの現実世界のシナリオは、バージョンの選択を示しています。まず、パブリック API 参照は API インスタンス間で安定している必要があり、作成時間の漏洩があってはならず、サーバーの再起動後も同じである必要があるため、異なるインスタンスが同じドキュメントに対して同じ参照を生成します。安定した名前空間とドキュメント名を持つ v5 を使用してください。次に、継続的に増加するテーブルの主キーは一意である必要があり、インデックスの断片化を引き起こしてはならず、中央調整なしでどのアプリケーション インスタンスでも生成可能である必要があります。標準の UUID エコシステム サポートを備えた並べ替え可能な識別子には v7 を使用します。第三に、安定した検索を必要とするアーカイブされたレコードには不変の識別子が必要です。
要点: 習慣ではなくプロパティで選択する — ToolAcre ジェネレーターは、v4 を必要とする場合にブラウザの CSPRNG からランダムな UUID を生成します
バージョンの選択は、慣例や慣れではなく、スキーマ設計とシステム要件に基づいて行われます。ランダム UUID (v4) は、状態や調整を必要とせず、ほとんどの役割に適した独立した識別子を生成するため、デフォルトです。時間順バージョン (v6、v7) は、一時的な情報漏洩またはクロック同期要件を犠牲にして、インデックスの局所性の問題を解決します。確定的バージョン (v3、v5) では、インポートの重複を防ぎ、予測可能性を犠牲にして安定した外部マッピングを有効にします。名前空間を知っている人なら誰でもマッピングを再計算できます。 ToolAcre は、ブラウザーの暗号的に安全なジェネレーターからランダムな v4 UUID を生成します。別のバージョンが必要な場合は、整形式のチェックによって識別子が有効なものとして解析されることが確認されます。