開発者ツール · UUID ジェネレーター
RFC 4122 と RFC 9562: 2024 UUID 標準の変更点
· 背景
uuid 暗号化 ブラウザ API
UUID に関して 2 つの RFC が引用されていますが、まったく同じことを述べているわけではありません。この投稿では、RFC 4122 に対して RFC 9562 で追加、明確化、非推奨になった内容について説明します。
どの RFC を引用すればよいですか? — ドキュメントとライブラリが異なる標準を参照する場合の混乱
UUID ドキュメントでは 2 つの RFC が定期的に引用されていますが、それらは同じことを述べているわけではありません。 2005 で公開された RFC 4122 では、UUID とその 5 つのバージョン (v1 から v5) が定義されています。 2024 で公開された RFC 9562 は、RFC 4122 を完全に廃止し、実務者が回避したあいまいさを明確にし、3 つの新しいバージョン (v6、v7、v8) を追加し、ランダム性の実装に関するガイダンスを更新します。ライブラリが RFC 4122 を引用する場合、それは間違いではありません。そのライブラリは RFC 9562 が公開される前にリリースされているか、保守者がドキュメントを更新していない可能性があります。 RFC 引用をチェックすると、ライブラリが最後に大幅に更新された時期がわかります。新しい仕様を作成したり実装を評価したりする場合、RFC 9562 が規範的な参照となります。
形式を置き換えるのではなく、廃止します。RFC 4122 で有効なものはすべて引き続き有効です。レイアウトとバリアントビットは変更されません
RFC 9562 は、現在の参照文書として RFC 4122 を正式に廃止しますが、使い慣れた 128 ビット表現、16 進グループ、バージョン位置、および主要なバリアント レイアウトは維持します。新しい RFC が存在するという理由だけで、保存されている既存の UUID 文字列を再発行する必要はありません。実際の移行はドキュメント、ジェネレーター、検証ポリシーにあります。現在の標準を引用し、追加されたバージョンを理解し、リビジョンで明確になったあいまいさに古いコードが依存していないかを確認します。互換性は、特にライブラリが Microsoft GUID 構造をシリアル化する場合や、標準で説明されているよりも狭いバージョンのセットを適用する場合には、システム境界でテストする必要があります。
3 つの新しいバージョン — v6 (再順序付けされた時間)、v7 (Unix エポック時間順序)、および v8 (実装定義)
RFC 9562 は、標準に 3 つの新しいバージョンを追加します。バージョン 6 は、v1 タイムスタンプ ビットを並べ替えて、データベースのパフォーマンスを向上させるために辞書順に並べ替え可能な識別子を生成します。バージョン 7 は、48 ビットの Unix ミリ秒タイムスタンプとその後に続くランダム ビットを使用し、v1 のプライバシーを考慮せずに時間順に生成します。バージョン 8 は、実装定義のレイアウトのエスケープ ハッチです。これらのバージョンは、v1 ～ v5 の動作方法やその意味を変更するものではありません。 2005 の v1 UUID と 2024 の v7 UUID は、それぞれの生成方法を識別するバージョン ビットを使用して同じデータベース内に共存できます。 3 つの新しいバージョンは、実際に発生した一般的なパターンに対応しています。
最大 UUID は Nil と結合します — すべてゼロの値と一緒に定義されたすべて F の値
RFC 4122 は、例とドキュメントの特別な参照値として Nil UUID (すべてゼロ ビット) を文書化しました。 RFC 9562 には同じ Nil 定義が含まれていますが、範囲境界の最大 UUID (すべてのビットが 1 に設定される) を正式に定義しています。 Nil も Max も、正しいバージョンおよびバリアント ビットを持たないため、バージョン 4 ランダム UUID ではありません。 Max UUID は、データベース クエリの上限範囲境界として役立ちます。 WHERE uuid_column <= MAX_UUID は、可能なすべての UUID と一致します。 Nil は、null 許容の UUID 列で未割り当ての監視として役立ちます。 RFC 9562 では、アプリケーション データでの使用を義務付けることなく、両方について文書化しています。
ガイダンスの明確化 — ランダム フィールド、ミリ秒以内の単調カウンター、およびデータベースの局所性のために時間順バージョンを優先する場合に CSPRNG を使用するという明示的なアドバイス
RFC 9562 のベスト プラクティス ガイダンスでは、衝突耐性と推測不可能性を区別しています。ランダム フィールドでは、アプリケーションの脅威モデルに適したソースを使用する必要があり、セキュリティに敏感な不透明度では CSPRNG が必要です。複数の識別子が 1 つのタイムスタンプ ティックを共有する場合、時間ベースのジェネレーターには別の単調性の問題が発生します。標準では、可能な方法としてカウンターと追加のタイムスタンプ精度が説明されており、それぞれに状態とロールオーバーのルールが含まれています。名前ベースのバージョンは、信頼性の証明ではなく、決定的な識別子のままです。 1 つの UUID パーサーは、たとえレイアウトの生成要件や情報開示プロパティが異なっていても、すべてのレイアウトを受け入れることができるため、これらの明確化は重要です。
ULID のアイデアが現れる場所 — コミュニティ形式が v7 の設計にどのような影響を与えたか
RFC 9562 には、その作成者が新しいレイアウトを開発する際に、ULID、Snowflake、KSUID などのいくつかの既存の並べ替え可能な識別子スキームを分析したと記載されています。これは控えめな結論を裏付けています。時間順に分散された識別子に対する運用上の需要がこの改訂に影響を与えたということです。あるコミュニティ フォーマットが正確なフィールド レイアウトをバージョン 7 に提供したことを証明するものではありません。実質的な類似性は、アーキテクチャの作業には十分です。これらのファミリは時間情報を先頭近くに配置するため、通常の順序付けにより大まかな作成順序が維持され、エンコード、調整、およびティック内動作が異なります。直接の祖先を主張するのではなく、エコシステムの互換性と文書化された保証によってどちらかを選択してください。
これでカバーされないもの — 行ごとの差分。この投稿は実装者にとっての実際的な結果に従っています
この包括的な投稿は、RFC 4122 との行ごとの差分ではなく、実装者とユーザー向けの RFC 9562 の実際的な結果と実装に従っています。完全な仕様は標準化団体から入手でき、言語またはプラットフォームで UUID 処理を実装する場合に読む価値があります。テキストには、概要でカバーできる範囲を超えた信頼できる詳細が記載されています。この投稿では、v6 が v1 バイトを並べ替える方法や、v7 が Unix ミリ秒をエンコードする方法についてのビットレベルの仕組みについては説明しません。標準と実装ガイドの両方が、ビット レイアウト、エンコーディング、またはコンプライアンス検証に関する実装に関する質問に対する主要な信頼できるリファレンスであり続けます。
要点: 引用とデフォルトを更新します。ToolAcre ジェネレーターは、両方の RFC が共有する CSPRNG ガイダンスに従います。
新しい作業については、RFC 9562 を引用するようにドキュメントと仕様を更新してください。 RFC 4122 のすべての UUID は、RFC 9562 のもとでも引き続き有効です。移行は純粋に将来を見据えた管理的な性質のものです。暗号のランダム性に関する明確なガイダンスは、識別子が実稼働システムの暗号的に安全なソースから取得される必要があることを強化します。 ToolAcre は、ブラウザーの Web Crypto API のみを使用して、両方の RFC の暗号化ランダム性ガイダンスに従います。ログ、データベース エクスポート、または API 応答から UUID が発生した場合、ToolAcre の整形式チェックは、RFC 9562 に対してそのバージョンとバリアントを報告します。 RFC 9562 は、すでに安定した標準を明確にし、最新化したものです。