Internet Engineering Task Force (IETF) K. Davis
Request for Comments: 9562 Cisco Systems
Obsoletes: 4122 B. Peabody
Category: Standards Track Uncloud
ISSN: 2070-1721 P. Leach
University of Washington
May 2024
This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.
この仕様では、UUID（GUIDS（グローバルに一意の識別子）とも呼ばれるUUID（普遍的に一意の識別子）と、UUIDの均一なリソース名名空間を定義します。UUIDの長さは128ビットで、空間と時間にわたって独自性を保証することを目的としています。UUIDはもともと、Apollo Network Computing System（NCS）で使用され、後にOpen Software Foundation（OSF）分散コンピューティング環境（DCE）で使用され、その後Microsoft Windowsプラットフォームで使用されていました。
This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122.
この仕様は、OSF（現在は「オープングループ」と呼ばれている）の親切な許可を得て、OSF DCE仕様から派生しています。OSF DCE仕様の以前のバージョンからの情報は、このドキュメントに組み込まれています。このドキュメントは、RFC 4122を廃止します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9562.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9562で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Motivation
2.1. Update Motivation
3. Terminology
3.1. Requirements Language
3.2. Abbreviations
4. UUID Format
4.1. Variant Field
4.2. Version Field
5. UUID Layouts
5.1. UUID Version 1
5.2. UUID Version 2
5.3. UUID Version 3
5.4. UUID Version 4
5.5. UUID Version 5
5.6. UUID Version 6
5.7. UUID Version 7
5.8. UUID Version 8
5.9. Nil UUID
5.10. Max UUID
6. UUID Best Practices
6.1. Timestamp Considerations
6.2. Monotonicity and Counters
6.3. UUID Generator States
6.4. Distributed UUID Generation
6.5. Name-Based UUID Generation
6.6. Namespace ID Usage and Allocation
6.7. Collision Resistance
6.8. Global and Local Uniqueness
6.9. Unguessability
6.10. UUIDs That Do Not Identify the Host
6.11. Sorting
6.12. Opacity
6.13. DBMS and Database Considerations
7. IANA Considerations
7.1. IANA UUID Subtype Registry and Registration
7.2. IANA UUID Namespace ID Registry and Registration
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Test Vectors
A.1. Example of a UUIDv1 Value
A.2. Example of a UUIDv3 Value
A.3. Example of a UUIDv4 Value
A.4. Example of a UUIDv5 Value
A.5. Example of a UUIDv6 Value
A.6. Example of a UUIDv7 Value
Appendix B. Illustrative Examples
B.1. Example of a UUIDv8 Value (Time-Based)
B.2. Example of a UUIDv8 Value (Name-Based)
Acknowledgements
Authors' Addresses
This specification defines a Uniform Resource Name namespace for Universally Unique IDentifiers (UUIDs), also known as Globally Unique IDentifiers (GUIDs). A UUID is 128 bits long and requires no central registration process.
この仕様では、グローバルに一意の識別子（GUIDS）とも呼ばれる、普遍的に一意の識別子（UUIDS）の均一なリソース名名空間を定義します。UUIDの長さは128ビットで、中央登録プロセスは必要ありません。
The use of UUIDs is extremely pervasive in computing. They comprise the core identifier infrastructure for many operating systems such as Microsoft Windows and applications such as the Mozilla Web browser; in many cases, they can become exposed in many non-standard ways.
UUIDの使用は、コンピューティングに非常に広範です。それらは、Microsoft WindowsやMozilla Webブラウザなどのアプリケーションなどの多くのオペレーティングシステムのコア識別子インフラストラクチャを構成しています。多くの場合、それらは多くの標準的な方法で露出する可能性があります。
This specification attempts to standardize that practice as openly as possible and in a way that attempts to benefit the entire Internet. The information here is meant to be a concise guide for those wishing to implement services using UUIDs either in combination with URNs [RFC8141] or otherwise.
この仕様は、その実践を可能な限り、インターネット全体に利益をもたらす方法で、その実践を可能な限り標準化しようとします。ここでの情報は、UUID [RFC8141]またはその他のいずれかでUUIDを使用してサービスを実装したい人のための簡潔なガイドであることを意図しています。
There is an ITU-T Recommendation and an ISO/IEC Standard [X667] that are derived from [RFC4122]. Both sets of specifications have been aligned and are fully technically compatible. Nothing in this document should be construed to override the DCE standards that defined UUIDs.
[RFC4122]に由来するITU-Tの推奨とISO/IEC標準[x667]があります。どちらの仕様のセットも調整されており、完全に技術的に互換性があります。このドキュメントには、UUIDを定義したDCE標準をオーバーライドすると解釈されるべきではありません。
One of the main reasons for using UUIDs is that no centralized authority is required to administer them (although two formats may leverage optional IEEE 802 Node IDs, others do not). As a result, generation on demand can be completely automated and used for a variety of purposes. The UUID generation algorithm described here supports very high allocation rates of 10 million per second per machine or more, if necessary, so that they could even be used as transaction IDs.
UUIDを使用する主な理由の1つは、それらを管理するために集中化された権限が必要ではないことです（ただし、2つの形式はオプションのIEEE 802ノードIDを活用できますが、他の形式はそうではありません）。その結果、オンデマンドの世代は完全に自動化され、さまざまな目的に使用できます。ここで説明するUUID生成アルゴリズムは、必要に応じて、必要に応じて、マシンあたり1秒あたり1000万以上の非常に高い割り当て率をサポートしているため、トランザクションIDとして使用できるようにします。
UUIDs are of a fixed size (128 bits), which is reasonably small compared to other alternatives. This lends itself well to sorting, ordering, and hashing of all sorts; storing in databases; simple allocation; and ease of programming in general.
UUIDは固定サイズ（128ビット）で、他の代替品と比較してかなり小さいです。これは、あらゆる種類の並べ替え、順序、ハッシュに適しています。データベースに保存。単純な割り当て;一般的にプログラミングの容易さ。
Since UUIDs are unique and persistent, they make excellent URNs. The unique ability to generate a new UUID without a registration process allows for UUIDs to be one of the URNs with the lowest minting cost.
UUIDはユニークで永続的であるため、優れたurを作ります。登録プロセスなしで新しいUUIDを生成するユニークな機能により、UUIDは最低のミントコストを持つURNの1つになります。
Many things have changed in the time since UUIDs were originally created. Modern applications have a need to create and utilize UUIDs as the primary identifier for a variety of different items in complex computational systems, including but not limited to database keys, file names, machine or system names, and identifiers for event-driven transactions.
UUIDが最初に作成されて以来、多くのことが変化しました。最新のアプリケーションには、データベースキー、ファイル名、マシンまたはシステム名、およびイベント駆動型トランザクションの識別子など、複雑な計算システムのさまざまな異なるアイテムの主要な識別子としてUUIDを作成および利用する必要があります。
One area in which UUIDs have gained popularity is database keys. This stems from the increasingly distributed nature of modern applications. In such cases, "auto-increment" schemes that are often used by databases do not work well: the effort required to coordinate sequential numeric identifiers across a network can easily become a burden. The fact that UUIDs can be used to create unique, reasonably short values in distributed systems without requiring coordination makes them a good alternative, but UUID versions 1-5, which were originally defined by [RFC4122], lack certain other desirable characteristics, such as:
UUIDが人気を獲得した領域の1つは、データベースキーです。これは、近代的なアプリケーションのますます分散されている性質に由来しています。このような場合、データベースでよく使用される「自動インクリメント」スキームはうまく機能しません。ネットワーク全体のシーケンシャル数値識別子を調整するために必要な努力は、簡単に負担になる可能性があります。UUIDを使用して、調整を必要とせずに分散システムに一意で合理的に短い値を作成できるという事実は、それらを優れた代替手段にしますが、元々[RFC4122]によって定義されていたUUIDバージョン1-5には、他の特定の望ましい特性がありません。：
1. UUID versions that are not time ordered, such as UUIDv4 (described in Section 5.4), have poor database-index locality. This means that new values created in succession are not close to each other in the index; thus, they require inserts to be performed at random locations. The resulting negative performance effects on the common structures used for this (B-tree and its variants) can be dramatic.
1. UUIDV4（セクション5.4で説明）など、時間順になっていないUUIDバージョンは、データベースインデックスのローカリティが不十分です。これは、連続して作成された新しい値がインデックスで互いに近づいていないことを意味します。したがって、ランダムな場所でインサートを実行する必要があります。結果として生じるこのパフォーマンス効果は、このために使用される共通構造（Bツリーとその変異体）に劇的になる可能性があります。
2. The 100-nanosecond Gregorian Epoch used in UUIDv1 timestamps (described in Section 5.1) is uncommon and difficult to represent accurately using a standard number format such as that described in [IEEE754].
2. UUIDV1タイムスタンプ（セクション5.1で説明）で使用される100ナノ秒グレゴリアンエポックは、[IEEE754]に記載されているような標準の数値形式を使用して正確に表現することはまれであり、困難です。
3. Introspection/parsing is required to order by time sequence, as opposed to being able to perform a simple byte-by-byte comparison.
3. 単純なバイトごとの比較を実行できるのではなく、時間シーケンスごとに注文するには、内省/解析が必要です。
4. Privacy and network security issues arise from using a Media Access Control (MAC) address in the node field of UUIDv1. Exposed MAC addresses can be used as an attack surface to locate network interfaces and reveal various other information about such machines (minimally, the manufacturer and, potentially, other details). Additionally, with the advent of virtual machines and containers, uniqueness of the MAC address is no longer guaranteed.
4. プライバシーとネットワークのセキュリティの問題は、UUIDV1のノードフィールドでメディアアクセスコントロール（MAC）アドレスを使用することから生じます。露出したMACアドレスを攻撃面として使用して、ネットワークインターフェイスを見つけ、そのようなマシンに関する他のさまざまな情報を明らかにすることができます（最終的には、メーカー、および潜在的に他の詳細）。さらに、仮想マシンとコンテナの出現により、Macアドレスの一意性は保証されなくなりました。
5. Many of the implementation details specified in [RFC4122] involved trade-offs that are neither possible to specify for all applications nor necessary to produce interoperable implementations.
5. [RFC4122]で指定された実装の詳細の多くには、すべてのアプリケーションを指定することも不可能でも、相互運用可能な実装を作成するために必要でもありませんでした。
6. [RFC4122] did not distinguish between the requirements for generating a UUID and those for simply storing one, although they are often different.
6. [RFC4122]は、UUIDを生成するための要件と単に保存するための要件を区別しませんでしたが、それらはしばしば異なります。
Due to the aforementioned issues, many widely distributed database applications and large application vendors have sought to solve the problem of creating a better time-based, sortable unique identifier for use as a database key. This has led to numerous implementations over the past 10+ years solving the same problem in slightly different ways.
前述の問題により、多くの広く分散されたデータベースアプリケーションと大規模なアプリケーションベンダーが、データベースキーとして使用するためのより良い時間ベースのソート可能な一意の識別子を作成する問題を解決しようとしています。これにより、過去10年以上にわたって数多くの実装が、わずかに異なる方法で同じ問題を解決しました。
While preparing this specification, the following 16 different implementations were analyzed for trends in total ID length, bit layout, lexical formatting and encoding, timestamp type, timestamp format, timestamp accuracy, node format and components, collision handling, and multi-timestamp tick generation sequencing:
この仕様の準備中、総IDの長さ、ビットレイアウト、語彙書式設定とエンコード、タイムスタンプタイプ、タイムスタンプ形式、タイムスタンプの精度、ノード形式とコンポーネント、衝突処理、マルチチメスタンプティックティック生成の傾向について、次の16の異なる実装が分析されました。シーケンス：
1. [ULID]
1. [ulid]
2. [LexicalUUID]
2. [lexicaluuid]
3. [Snowflake]
3. [スノーフレーク]
4. [Flake]
4. [フレーク]
5. [ShardingID]
5. [Shardingid]
6. [KSUID]
6. [ksuid]
7. [Elasticflake]
7. [ElasticFlake]
8. [FlakeID]
8. [flakeid]
9. [Sonyflake]
9. [Sonyflake]
10. [orderedUuid]
10. [Ordereduuid]
11. [COMBGUID]
11. [combguid]
12. [SID]
12. [sid]
13. [pushID]
13. [Pushid]
14. [XID]
14. [xid]
15. [ObjectID]
15. [ObjectId]
16. [CUID]
16. [cuid]
An inspection of these implementations and the issues described above has led to this document, in which new UUIDs are adapted to address these issues.
これらの実装と上記の問題の検査により、これらの問題に対処するために新しいUUIDが適応されているこの文書につながりました。
Further, [RFC4122] itself was in need of an overhaul to address a number of topics such as, but not limited to, the following:
さらに、[RFC4122]自体は、以下などの多くのトピックに対処するためのオーバーホールが必要でした。
1. Implementation of miscellaneous errata reports. Mostly around bit-layout clarifications, which lead to inconsistent implementations [Err1957], [Err3546], [Err4975], [Err4976], [Err5560], etc.
1. その他のerrataレポートの実装。ほとんどの場合、ビットレイアウトの明確化については、一貫性のない実装[ERR1957]、[ERR3546]、[err4975]、[err4976]、[err5560]などにつながります。
2. Decoupling other UUID versions from the UUIDv1 bit layout so that fields like "time_hi_and_version" do not need to be referenced within a UUID that is not time based while also providing definition sections similar to that for UUIDv1 for UUIDv3, UUIDv4, and UUIDv5.
2. uuidv1ビットレイアウトから他のuuidバージョンをデカップするため、「time_hi_and_version」のようなフィールドは、uuidv3、uuidv4、およびuuidv5のuuidv1と同様の定義セクションを提供すると同時に、時間ベースではないuuid内で参照する必要はありません。
3. Providing implementation best practices around many real-world scenarios and corner cases observed by existing and prototype implementations.
3. 既存およびプロトタイプの実装によって観察される多くの現実世界のシナリオとコーナーケースに関する実装ベストプラクティスを提供します。
4. Addressing security best practices and considerations for the modern age as it pertains to MAC addresses, hashing algorithms, secure randomness, and other topics.
4. MACアドレス、ハッシュアルゴリズム、安全なランダム性、およびその他のトピックに関連する現代のセキュリティのベストプラクティスと考慮事項への対処。
5. Providing implementations a standard-based option for implementation-specific and/or experimental UUID designs.
5. 実装に基づいた実装固有および/または実験的なUUIDデザインの標準ベースのオプションを提供します。
6. Providing more test vectors that illustrate real UUIDs created as per the specification.
6. 仕様に従って作成された実際のUUIDを示すより多くのテストベクトルを提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「必須」、「必要」、「必須」、「shall」、「shall」、「shill "of"、 "nove"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The following abbreviations are used in this document:
このドキュメントでは、次の略語が使用されています。
ABNF
abnf
Augmented Backus-Naur Form
拡張バックスノールフォーム
CSPRNG
csprng
Cryptographically Secure Pseudorandom Number Generator
暗号化的に保護されている擬似ランダム数ジェネレーター
DBMS
DBMS
Database Management System
データベースマネージメントシステム
IEEE
IEEE
Institute of Electrical and Electronics Engineers
電気電子技術者協会
ITU
itu
International Telecommunication Union
国際電気通信連合
MAC
マック
Media Access Control
報道規制
MD5
MD5
Message Digest 5
メッセージダイジェスト5
MSB
MSB
Most Significant Bit
上位ビット
OID
oid
Object Identifier
オブジェクト識別子
SHA
シャ
Secure Hash Algorithm
安全なハッシュアルゴリズム
SHA-1
SHA-1
Secure Hash Algorithm 1 (with message digest of 160 bits)
セキュアハッシュアルゴリズム1（メッセージダイジェストが160ビット）
SHA-3
SHA-3
Secure Hash Algorithm 3 (arbitrary size)
安全なハッシュアルゴリズム3（任意のサイズ）
SHA-224
SHA-224
Secure Hash Algorithm 2 with message digest size of 224 bits
224ビットのメッセージダイジェストサイズを備えたセキュアハッシュアルゴリズム2
SHA-256
SHA-256
Secure Hash Algorithm 2 with message digest size of 256 bits
256ビットのメッセージダイジェストサイズを備えたセキュアハッシュアルゴリズム2
SHA-512
SHA-512
Secure Hash Algorithm 2 with message digest size of 512 bits
512ビットのメッセージダイジェストサイズを備えたセキュアハッシュアルゴリズム2
SHAKE
振る
Secure Hash Algorithm 3 based on the KECCAK algorithm
Keccakアルゴリズムに基づいて、セキュアハッシュアルゴリズム3
URN
urn
Uniform Resource Names
ユニフォームのリソース名
UTC
UTC
Coordinated Universal Time
調整された普遍的な時間
UUID
uuid
Universally Unique Identifier
普遍的に一意の識別子
UUIDv1
uuidv1
Universally Unique Identifier version 1
普遍的にユニークな識別子バージョン1
UUIDv2
uuidv2
Universally Unique Identifier version 2
普遍的にユニークな識別子バージョン2
UUIDv3
uuidv3
Universally Unique Identifier version 3
普遍的にユニークな識別子バージョン3
UUIDv4
uuidv4
Universally Unique Identifier version 4
普遍的にユニークな識別子バージョン4
UUIDv5
uuidv5
Universally Unique Identifier version 5
普遍的にユニークな識別子バージョン5
UUIDv6
uuidv6
Universally Unique Identifier version 6
普遍的にユニークな識別子バージョン6
UUIDv7
uuidv7
Universally Unique Identifier version 7
普遍的にユニークな識別子バージョン7
UUIDv8
uuidv8
Universally Unique Identifier version 8
普遍的にユニークな識別子バージョン8
The UUID format is 16 octets (128 bits) in size; the variant bits in conjunction with the version bits described in the next sections determine finer structure. In terms of these UUID formats and layout, bit definitions start at 0 and end at 127, while octet definitions start at 0 and end at 15.
UUID形式のサイズは16オクテット（128ビット）です。次のセクションで説明されているバージョンビットと組み合わせたバリアントビットは、より細かい構造を決定します。これらのUUID形式とレイアウトに関しては、ビット定義は0から始まり、127で終了し、Octetの定義は0から始まり、15で終了します。
In the absence of explicit application or presentation protocol specification to the contrary, each field is encoded with the most significant byte first (known as "network byte order").
反対の明示的なアプリケーションまたはプレゼンテーションプロトコルの仕様がない場合、各フィールドは、最初の最も重要なバイト（「ネットワークバイト順」と呼ばれる）でエンコードされます。
Saving UUIDs to binary format is done by sequencing all fields in big-endian format. However, there is a known caveat that Microsoft's Component Object Model (COM) GUIDs leverage little-endian when saving GUIDs. The discussion of this (see [MS_COM_GUID]) is outside the scope of this specification.
UUIDをバイナリ形式に保存することは、すべてのフィールドをビッグエンディアン形式でシーケンスすることによって行われます。ただし、Microsoftのコンポーネントオブジェクトモデル（com）GuidsがGUIDを保存する際にLittle-Endianを活用するという既知の注意事項があります。この議論（[ms_com_guid]を参照）は、この仕様の範囲外です。
UUIDs MAY be represented as binary data or integers. When in use with URNs or as text in applications, any given UUID should be represented by the "hex-and-dash" string format consisting of multiple groups of uppercase or lowercase alphanumeric hexadecimal characters separated by single dashes/hyphens. When used with databases, please refer to Section 6.13.
UUIDは、バイナリデータまたは整数として表される場合があります。urnsまたはアプリケーションでテキストとして使用している場合、特定のuuidは、1つのダッシュ/ハイフンで分離された大文字または小文字のアルファニュメンシャルヘキサデシマル文字の複数のグループで構成される「六角形」文字列形式で表す必要があります。データベースで使用する場合は、セクション6.13を参照してください。
The formal definition of the UUID string representation is provided by the following ABNF [RFC5234]:
UUID文字列表現の正式な定義は、次のABNF [RFC5234]によって提供されます。
UUID = 4hexOctet "-"
2hexOctet "-"
2hexOctet "-"
2hexOctet "-"
6hexOctet
hexOctet = HEXDIG HEXDIG
DIGIT = %x30-39
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
Note that the alphabetic characters may be all uppercase, all lowercase, or mixed case, as per Section 2.3 of [RFC5234]. An example UUID using this textual representation from the above ABNF is shown in Figure 1.
アルファベット文字は、[RFC5234]のセクション2.3に従って、すべて大文字、すべて小文字、または混合ケースである可能性があることに注意してください。上記のABNFからこのテキスト表現を使用したUUIDの例を図1に示します。
f81d4fae-7dec-11d0-a765-00a0c91e6bf6
Figure 1: Example String UUID Format
図1：string uuid形式の例
The same UUID from Figure 1 is represented in binary (Figure 2), as an unsigned integer (Figure 3), and as a URN (Figure 4) defined by [RFC8141].
図1の同じUUIDは、バイナリ（図2）で、署名されていない整数（図3）として、および[RFC8141]で定義されたuRN（図4）として表されています。
111110000001110101001111101011100111110111101100000100011101000\
01010011101100101000000001010000011001001000111100110101111110110
Figure 2: Example Binary UUID
図2：バイナリUUIDの例
329800735698586629295641978511506172918
Figure 3: Example Unsigned Integer UUID (Shown as a Decimal Number)
図3：署名されていない整数UUIDの例（小数点以下として表示）
urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
Figure 4: Example URN Namespace for UUID
図4：uuidのurnネームスペースの例
There are many other ways to define a UUID format; some examples are detailed below. Please note that this is not an exhaustive list and is only provided for informational purposes.
UUID形式を定義する他の多くの方法があります。いくつかの例を以下に示します。これは網羅的なリストではなく、情報目的でのみ提供されることに注意してください。
* Some UUID implementations, such as those found in [Python] and [Microsoft], will output UUID with the string format, including dashes, enclosed in curly braces.
* [Python]や[Microsoft]で見つかったものなど、いくつかのUUID実装は、巻き装置に囲まれたダッシュを含む文字列形式でUUIDを出力します。
* [X667] provides UUID format definitions for use of UUID with an OID.
* [X667]は、OIDでUUIDを使用するためのUUID形式の定義を提供します。
* [IBM_NCS] is a legacy implementation that produces a unique UUID format compatible with Variant 0xx of Table 1.
* [IBM_NCS]は、表1のバリアント0xxと互換性のある一意のUUID形式を生成するレガシーの実装です。
The variant field determines the layout of the UUID. That is, the interpretation of all other bits in the UUID depends on the setting of the bits in the variant field. As such, it could more accurately be called a "type" field; we retain the original term for compatibility. The variant field consists of a variable number of the most significant bits of octet 8 of the UUID.
バリアントフィールドは、UUIDのレイアウトを決定します。つまり、UUID内の他のすべてのビットの解釈は、バリアントフィールドのビットの設定に依存します。そのため、より正確に「タイプ」フィールドと呼ばれる可能性があります。互換性のために元の用語を保持します。バリアントフィールドは、UUIDのオクテット8の最も重要なビットの変数数で構成されています。
Table 1 lists the contents of the variant field, where the letter "x" indicates a "don't-care" value.
表1に、バリアントフィールドの内容を示します。文字「x」は「介護しない」値を示します。
+======+======+======+======+=========+=========================+
| MSB0 | MSB1 | MSB2 | MSB3 | Variant | Description |
+======+======+======+======+=========+=========================+
| 0 | x | x | x | 1-7 | Reserved. Network |
| | | | | | Computing System (NCS) |
| | | | | | backward compatibility, |
| | | | | | and includes Nil UUID |
| | | | | | as per Section 5.9. |
+------+------+------+------+---------+-------------------------+
| 1 | 0 | x | x | 8-9,A-B | The variant specified |
| | | | | | in this document. |
+------+------+------+------+---------+-------------------------+
| 1 | 1 | 0 | x | C-D | Reserved. Microsoft |
| | | | | | Corporation backward |
| | | | | | compatibility. |
+------+------+------+------+---------+-------------------------+
| 1 | 1 | 1 | x | E-F | Reserved for future |
| | | | | | definition and includes |
| | | | | | Max UUID as per |
| | | | | | Section 5.10. |
+------+------+------+------+---------+-------------------------+
Table 1: UUID Variants
表1：UUIDバリアント
Interoperability, in any form, with variants other than the one defined here is not guaranteed but is not likely to be an issue in practice.
ここで定義されているもの以外のバリアントを備えたあらゆる形態の相互運用性は保証されていませんが、実際には問題になる可能性はありません。
Specifically for UUIDs in this document, bits 64 and 65 of the UUID (bits 0 and 1 of octet 8) MUST be set to 1 and 0 as specified in row 2 of Table 1. Accordingly, all bit and field layouts avoid the use of these bits.
特にこのドキュメントのUUIDの場合、UUIDのビット64および65（Octet 8のビット0および1）は、表1の行2で指定されているように1および0に設定する必要があります。これらのビット。
The version number is in the most significant 4 bits of octet 6 (bits 48 through 51 of the UUID).
バージョン番号は、Octet 6の最も重要な4ビット（UUIDの48〜51）です。
Table 2 lists all of the versions for this UUID variant 10xx specified in this document.
表2に、このドキュメントで指定されたこのUUIDバリアント10xxのすべてのバージョンを示します。
+======+======+======+======+=========+============================+
| MSB0 | MSB1 | MSB2 | MSB3 | Version | Description |
+======+======+======+======+=========+============================+
| 0 | 0 | 0 | 0 | 0 | Unused. |
+------+------+------+------+---------+----------------------------+
| 0 | 0 | 0 | 1 | 1 | The Gregorian time-based |
| | | | | | UUID specified in this |
| | | | | | document. |
+------+------+------+------+---------+----------------------------+
| 0 | 0 | 1 | 0 | 2 | Reserved for DCE Security |
| | | | | | version, with embedded |
| | | | | | POSIX UUIDs. |
+------+------+------+------+---------+----------------------------+
| 0 | 0 | 1 | 1 | 3 | The name-based version |
| | | | | | specified in this document |
| | | | | | that uses MD5 hashing. |
+------+------+------+------+---------+----------------------------+
| 0 | 1 | 0 | 0 | 4 | The randomly or |
| | | | | | pseudorandomly generated |
| | | | | | version specified in this |
| | | | | | document. |
+------+------+------+------+---------+----------------------------+
| 0 | 1 | 0 | 1 | 5 | The name-based version |
| | | | | | specified in this document |
| | | | | | that uses SHA-1 hashing. |
+------+------+------+------+---------+----------------------------+
| 0 | 1 | 1 | 0 | 6 | Reordered Gregorian time- |
| | | | | | based UUID specified in |
| | | | | | this document. |
+------+------+------+------+---------+----------------------------+
| 0 | 1 | 1 | 1 | 7 | Unix Epoch time-based UUID |
| | | | | | specified in this |
| | | | | | document. |
+------+------+------+------+---------+----------------------------+
| 1 | 0 | 0 | 0 | 8 | Reserved for custom UUID |
| | | | | | formats specified in this |
| | | | | | document. |
+------+------+------+------+---------+----------------------------+
| 1 | 0 | 0 | 1 | 9 | Reserved for future |
| | | | | | definition. |
+------+------+------+------+---------+----------------------------+
| 1 | 0 | 1 | 0 | 10 | Reserved for future |
| | | | | | definition. |
+------+------+------+------+---------+----------------------------+
| 1 | 0 | 1 | 1 | 11 | Reserved for future |
| | | | | | definition. |
+------+------+------+------+---------+----------------------------+
| 1 | 1 | 0 | 0 | 12 | Reserved for future |
| | | | | | definition. |
+------+------+------+------+---------+----------------------------+
| 1 | 1 | 0 | 1 | 13 | Reserved for future |
| | | | | | definition. |
+------+------+------+------+---------+----------------------------+
| 1 | 1 | 1 | 0 | 14 | Reserved for future |
| | | | | | definition. |
+------+------+------+------+---------+----------------------------+
| 1 | 1 | 1 | 1 | 15 | Reserved for future |
| | | | | | definition. |
+------+------+------+------+---------+----------------------------+
Table 2: UUID Variant 10xx Versions Defined by This Specification
表2：この仕様で定義されたUUIDバリアント10xxバージョン
An example version/variant layout for UUIDv4 follows the table where "M" represents the version placement for the hexadecimal representation of 0x4 (0b0100) and the "N" represents the variant placement for one of the four possible hexadecimal representation of variant 10xx: 0x8 (0b1000), 0x9 (0b1001), 0xA (0b1010), 0xB (0b1011).
UUIDV4の例のバージョン/バリアントレイアウトは、「M」が0x4（0B0100）の16進表現のバージョン配置を表すテーブルに続き、「n」は、バリアント10xx：0x8の4つの可能な六文学的表現の4つの1つのバリアント配置を表します。（0b1000）、0x9（0b1001）、0xa（0b1010）、0xb（0b1011）。
00000000-0000-4000-8000-000000000000
00000000-0000-4000-9000-000000000000
00000000-0000-4000-A000-000000000000
00000000-0000-4000-B000-000000000000
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
Figure 5: UUIDv4 Variant Examples
図5：UUIDV4バリアントの例
It should be noted that the other remaining UUID variants found in Table 1 leverage different sub-typing or versioning mechanisms. The recording and definition of the remaining UUID variant and sub-typing combinations are outside of the scope of this document.
表1にある他の残りのUUIDバリアントは、異なるサブタイピングまたはバージョン化メカニズムを活用することに注意する必要があります。残りのUUIDバリアントとサブタイピングの組み合わせの記録と定義は、このドキュメントの範囲外です。
To minimize confusion about bit assignments within octets and among differing versions, the UUID record definition is provided as a grouping of fields within a bit layout consisting of four octets per row. The fields are presented with the most significant one first.
オクテット内および異なるバージョン内のビット割り当てに関する混乱を最小限に抑えるために、UUIDレコード定義は、1行あたり4オクテットからなるビットレイアウト内のフィールドのグループとして提供されます。フィールドには、最初に最も重要なフィールドが表示されます。
UUIDv1 is a time-based UUID featuring a 60-bit timestamp represented by Coordinated Universal Time (UTC) as a count of 100-nanosecond intervals since 00:00:00.00, 15 October 1582 (the date of Gregorian reform to the Christian calendar).
UUIDV1は、1582年10月15日、00：00：00.00から100ナノ秒間隔として調整されたユニバーサル時間（UTC）によって表される60ビットのタイムスタンプを特徴とする時間ベースのUUIDです（キリスト教のカレンダーに対するグレゴリオ改革の日付）。
UUIDv1 also features a clock sequence field that is used to help avoid duplicates that could arise when the clock is set backwards in time or if the Node ID changes.
UUIDV1には、クロックが時間内に後方に設定されたときまたはノードIDが変更された場合に発生する可能性のある重複を避けるために使用されるクロックシーケンスフィールドも備えています。
The node field consists of an IEEE 802 MAC address, usually the host address or a randomly derived value per Sections 6.9 and 6.10.
ノードフィールドは、IEEE 802 Macアドレス、通常はホストアドレスまたはセクション6.9および6.10ごとにランダムに導出された値で構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time_mid | ver | time_high |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| clock_seq | node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: UUIDv1 Field and Bit Layout
図6：UUIDV1フィールドとビットレイアウト
time_low:
time_low：
The least significant 32 bits of the 60-bit starting timestamp. Occupies bits 0 through 31 (octets 0-3).
60ビットの開始タイムスタンプの最も重要な32ビット。0から31（オクテット0-3）を占有します。
time_mid:
time_mid：
The middle 16 bits of the 60-bit starting timestamp. Occupies bits 32 through 47 (octets 4-5).
60ビットの開始タイムスタンプの中央16ビット。32〜47（オクテット4-5）を占有します。
ver:
ver:
The 4-bit version field as defined by Section 4.2, set to 0b0001 (1). Occupies bits 48 through 51 of octet 6.
セクション4.2で定義されている4ビットバージョンフィールドは、0b0001（1）に設定されています。オクテット6のビット48〜51を占有します。
time_high:
time_high：
The least significant 12 bits from the 60-bit starting timestamp. Occupies bits 52 through 63 (octets 6-7).
60ビットの開始タイムスタンプから最も重要な12ビット。52〜63（オクテット6-7）を占有します。
var:
var:
The 2-bit variant field as defined by Section 4.1, set to 0b10. Occupies bits 64 and 65 of octet 8.
セクション4.1で定義された2ビットバリアントフィールド、0B10に設定されています。Octet 8のビット64および65を占有します。
clock_seq:
clock_seq：
The 14 bits containing the clock sequence. Occupies bits 66 through 79 (octets 8-9).
クロックシーケンスを含む14ビット。ビット66〜79（オクテット8-9）を占有します。
node:
ノード：
48-bit spatially unique identifier. Occupies bits 80 through 127 (octets 10-15).
48ビット空間的に一意の識別子。80〜127（オクテット10-15）を占有します。
For systems that do not have UTC available but do have the local time, they may use that instead of UTC as long as they do so consistently throughout the system. However, this is not recommended since generating the UTC from local time only needs a time-zone offset.
UTCを利用できないが現地時間があるシステムの場合、システム全体で一貫して行う限り、UTCの代わりにそれを使用する場合があります。ただし、現地時間からUTCを生成するには時間帯オフセットのみが必要なため、これは推奨されません。
If the clock is set backwards, or if it might have been set backwards (e.g., while the system was powered off), and the UUID generator cannot be sure that no UUIDs were generated with timestamps larger than the value to which the clock was set, then the clock sequence MUST be changed. If the previous value of the clock sequence is known, it MAY be incremented; otherwise it SHOULD be set to a random or high-quality pseudorandom value.
クロックが後方に設定されている場合、またはそれが後方に設定されている可能性がある場合（たとえば、システムが電源が切れている間）、UUIDジェネレーターは、クロックが設定された値よりも大きなタイムスタンプでUUIDが生成されないことを確認できません、次に、クロックシーケンスを変更する必要があります。クロックシーケンスの以前の値がわかっている場合、増加する可能性があります。それ以外の場合は、ランダムまたは高品質の疑似ランダム値に設定する必要があります。
Similarly, if the Node ID changes (e.g., because a network card has been moved between machines), setting the clock sequence to a random number minimizes the probability of a duplicate due to slight differences in the clock settings of the machines. If the value of the clock sequence associated with the changed Node ID were known, then the clock sequence MAY be incremented, but that is unlikely.
同様に、ノードIDが変更された場合（たとえば、マシン間でネットワークカードが移動されたため）、マシンのクロック設定のわずかな違いにより、クロックシーケンスを乱数に設定すると、重複の確率が最小限に抑えられます。変更されたノードIDに関連付けられたクロックシーケンスの値がわかっている場合、クロックシーケンスが増加する可能性がありますが、それはありそうにありません。
The clock sequence MUST be originally (i.e., once in the lifetime of a system) initialized to a random number to minimize the correlation across systems. This provides maximum protection against Node IDs that may move or switch from system to system rapidly. The initial value MUST NOT be correlated to the Node ID.
クロックシーケンスは、システム間の相関を最小限に抑えるために、元々（つまり、システムの寿命に1回）乱数に初期化されている必要があります。これにより、システムからシステムへと迅速に移動または切り替える可能性のあるノードIDに対する最大の保護が提供されます。初期値をノードIDと相関させてはなりません。
Notes about nodes derived from IEEE 802:
IEEE 802から派生したノードに関するメモ：
* On systems with multiple IEEE 802 addresses, any available one MAY be used.
* 複数のIEEE 802アドレスを持つシステムでは、利用可能なものを使用できます。
* On systems with no IEEE address, a randomly or pseudorandomly generated value MUST be used; see Sections 6.9 and 6.10.
* IEEEアドレスのないシステムでは、ランダムまたは擬似ランダムに生成された値を使用する必要があります。セクション6.9および6.10を参照してください。
* On systems utilizing a 64-bit MAC address, the least significant, rightmost 48 bits MAY be used.
* 64ビットMACアドレスを使用しているシステムでは、最も重要でない右端の48ビットを使用できます。
* Systems utilizing an IEEE 802.15.4 16-bit address SHOULD instead utilize their 64-bit MAC address where the least significant, rightmost 48 bits MAY be used. An alternative is to generate 32 bits of random data and postfix at the end of the 16-bit MAC address to create a 48-bit value.
* IEEE 802.15.4 16ビットアドレスを使用しているシステムは、代わりに64ビットのMACアドレスを利用する必要があります。別の方法は、16ビットMACアドレスの最後に32ビットのランダムデータとポストフィックスを生成して、48ビット値を作成することです。
UUIDv2 is for DCE Security UUIDs (see [C309] and [C311]). As such, the definition of these UUIDs is outside the scope of this specification.
UUIDV2はDCEセキュリティUUIDS用です（[C309]および[C311]を参照）。そのため、これらのUUIDの定義は、この仕様の範囲外です。
UUIDv3 is meant for generating UUIDs from names that are drawn from, and unique within, some namespace as per Section 6.5.
UUIDV3は、セクション6.5に従って、いくつかの名前空間から描かれた名前から一意の名前からUUIDを生成することを目的としています。
UUIDv3 values are created by computing an MD5 hash [RFC1321] over a given Namespace ID value (Section 6.6) concatenated with the desired name value after both have been converted to a canonical sequence of octets, as defined by the standards or conventions of its namespace, in network byte order. This MD5 value is then used to populate all 128 bits of the UUID layout. The UUID version and variant then replace the respective bits as defined by Sections 4.2 and 4.1. An example of this bit substitution can be found in Appendix A.2.
UUIDV3値は、NameSpaceの標準または慣習によって定義されているように、両方がオクテットの標準的なシーケンスに変換された後、目的の名前値と連結された特定の名前空間ID値（セクション6.6）でMD5ハッシュ[RFC1321]を計算することにより作成されます。、ネットワークバイトの順序で。次に、このMD5値を使用して、UUIDレイアウトの128ビットすべてに入力します。UUIDバージョンとバリアントは、セクション4.2および4.1で定義されているそれぞれのビットを置き換えます。このビット置換の例は、付録A.2に記載されています。
Information around selecting a desired name's canonical format within a given namespace can be found in Section 6.5 under the heading "A note on names".
指定された名前空間内の目的の名前の正規形式の選択に関する情報は、「名前のメモ」という見出しのセクション6.5にあります。
Where possible, UUIDv5 SHOULD be used in lieu of UUIDv3. For more information on MD5 security considerations, see [RFC6151].
可能であれば、uuidv3の代わりにuuidv5を使用する必要があります。MD5セキュリティに関する考慮事項の詳細については、[RFC6151]を参照してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| md5_high |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| md5_high | ver | md5_mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| md5_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| md5_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: UUIDv3 Field and Bit Layout
図7：UUIDV3フィールドとビットレイアウト
md5_high:
md5_high：
The first 48 bits of the layout are filled with the most significant, leftmost 48 bits from the computed MD5 value. Occupies bits 0 through 47 (octets 0-5).
レイアウトの最初の48ビットは、計算されたMD5値から最も重要な左端の48ビットで満たされています。0〜47（オクテット0-5）を占有します。
ver:
ver:
The 4-bit version field as defined by Section 4.2, set to 0b0011 (3). Occupies bits 48 through 51 of octet 6.
セクション4.2で定義されている4ビットバージョンフィールドは、0B0011（3）に設定されています。オクテット6のビット48〜51を占有します。
md5_mid:
MD5_MID：
12 more bits of the layout consisting of the least significant, rightmost 12 bits of 16 bits immediately following md5_high from the computed MD5 value. Occupies bits 52 through 63 (octets 6-7).
計算されたMD5値からMD5_Highの直後に、最も重要ではない右端の12ビットの16ビットからなるレイアウトの12ビット。52〜63（オクテット6-7）を占有します。
var:
var:
The 2-bit variant field as defined by Section 4.1, set to 0b10. Occupies bits 64 and 65 of octet 8.
セクション4.1で定義された2ビットバリアントフィールド、0B10に設定されています。Octet 8のビット64および65を占有します。
md5_low:
MD5_LOW：
The final 62 bits of the layout immediately following the var field to be filled with the least significant, rightmost bits of the final 64 bits from the computed MD5 value. Occupies bits 66 through 127 (octets 8-15)
VARフィールドの直後のレイアウトの最後の62ビットは、計算されたMD5値から最終64ビットの最も重要でない右端のビットで満たされます。66〜127を占める（オクテット8-15）
UUIDv4 is meant for generating UUIDs from truly random or pseudorandom numbers.
UUIDV4は、真にランダムまたは擬似ランダム数からUUIDを生成するためのものです。
An implementation may generate 128 bits of random data that is used to fill out the UUID fields in Figure 8. The UUID version and variant then replace the respective bits as defined by Sections 4.1 and 4.2.
実装により、図8のUUIDフィールドに記入するために使用される128ビットのランダムデータが生成される場合があります。UUIDバージョンとバリアントは、セクション4.1および4.2で定義されたそれぞれのビットを置き換えます。
Alternatively, an implementation MAY choose to randomly generate the exact required number of bits for random_a, random_b, and random_c (122 bits total) and then concatenate the version and variant in the required position.
あるいは、実装では、RANDOM_A、RANDOM_B、およびRANDOM_C（合計122ビット）に必要なビットの正確な数をランダムに生成し、必要な位置でバージョンとバリアントを連結することを選択できます。
For guidelines on random data generation, see Section 6.9.
ランダムデータ生成に関するガイドラインについては、セクション6.9を参照してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| random_a |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| random_a | ver | random_b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| random_c |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| random_c |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: UUIDv4 Field and Bit Layout
図8：UUIDV4フィールドとビットレイアウト
random_a:
random_a：
The first 48 bits of the layout that can be filled with random data as specified in Section 6.9. Occupies bits 0 through 47 (octets 0-5).
セクション6.9で指定されているように、ランダムデータで満たすことができるレイアウトの最初の48ビット。0〜47（オクテット0-5）を占有します。
ver:
ver:
The 4-bit version field as defined by Section 4.2, set to 0b0100 (4). Occupies bits 48 through 51 of octet 6.
セクション4.2で定義されている4ビットバージョンフィールドは、0B0100（4）に設定されています。オクテット6のビット48〜51を占有します。
random_b:
random_b：
12 more bits of the layout that can be filled random data as per Section 6.9. Occupies bits 52 through 63 (octets 6-7).
セクション6.9に従ってランダムデータを入力できるレイアウトのさらに12ビット。52〜63（オクテット6-7）を占有します。
var:
var:
The 2-bit variant field as defined by Section 4.1, set to 0b10. Occupies bits 64 and 65 of octet 8.
セクション4.1で定義された2ビットバリアントフィールド、0B10に設定されています。Octet 8のビット64および65を占有します。
random_c:
ランダム_C：
The final 62 bits of the layout immediately following the var field to be filled with random data as per Section 6.9. Occupies bits 66 through 127 (octets 8-15).
セクション6.9に従って、ランダムデータで満たされるVARフィールドの直後のレイアウトの最後の62ビット。66〜127（オクテット8-15）を占有します。
UUIDv5 is meant for generating UUIDs from "names" that are drawn from, and unique within, some "namespace" as per Section 6.5.
UUIDV5は、セクション6.5に従って、「名前空間」から引き出された「名前」からUUIDを生成するためのものです。
UUIDv5 values are created by computing an SHA-1 hash [FIPS180-4] over a given Namespace ID value (Section 6.6) concatenated with the desired name value after both have been converted to a canonical sequence of octets, as defined by the standards or conventions of its namespace, in network byte order. The most significant, leftmost 128 bits of the SHA-1 value are then used to populate all 128 bits of the UUID layout, and the remaining 32 least significant, rightmost bits of SHA-1 output are discarded. The UUID version and variant then replace the respective bits as defined by Sections 4.2 and 4.1. An example of this bit substitution and discarding excess bits can be found in Appendix A.4.
UUIDV5値は、標準または標準または定義されているように、両方がオクテットの標準的なシーケンスに変換された後に、所望の名前値と連結された特定の名前空間ID値（セクション6.6）でSHA-1ハッシュ[FIPS180-4]を計算することにより作成されます。ネットワークバイトの順序で、その名前空間の規則。SHA-1値の最も重要な左端の128ビットを使用して、UUIDレイアウトの128ビットすべてに入力し、残りの32ビットの右端のSHA-1出力を破棄します。UUIDバージョンとバリアントは、セクション4.2および4.1で定義されているそれぞれのビットを置き換えます。このビット置換と過剰なビットの廃棄の例は、付録A.4に記載されています。
Information around selecting a desired name's canonical format within a given namespace can be found in Section 6.5 under the heading "A note on names".
指定された名前空間内の目的の名前の正規形式の選択に関する情報は、「名前のメモ」という見出しのセクション6.5にあります。
There may be scenarios, usually depending on organizational security policies, where SHA-1 libraries may not be available or may be deemed unsafe for use. As such, it may be desirable to generate name-based UUIDs derived from SHA-256 or newer SHA methods. These name-based UUIDs MUST NOT utilize UUIDv5 and MUST be within the UUIDv8 space defined by Section 5.8. An illustrative example of UUIDv8 for SHA-256 name-based UUIDs is provided in Appendix B.2.
通常、組織のセキュリティポリシーに応じてシナリオがあり、SHA-1ライブラリが利用できない場合や、使用が安全でないとみなされる場合があります。そのため、SHA-256または新しいSHAメソッドから派生した名前ベースのUUIDを生成することが望ましい場合があります。これらの名前ベースのUUIDは、UUIDV5を利用してはならず、セクション5.8で定義されたUUIDV8スペース内にある必要があります。SHA-256ネームベースのUUIDのUUIDV8の例の例は、付録B.2に記載されています。
For more information on SHA-1 security considerations, see [RFC6194].
SHA-1セキュリティに関する考慮事項の詳細については、[RFC6194]を参照してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sha1_high |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sha1_high | ver | sha1_mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| sha1_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sha1_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: UUIDv5 Field and Bit Layout
図9：UUIDV5フィールドとビットレイアウト
sha1_high:
sha1_high：
The first 48 bits of the layout are filled with the most significant, leftmost 48 bits from the computed SHA-1 value. Occupies bits 0 through 47 (octets 0-5).
レイアウトの最初の48ビットは、計算されたSHA-1値から最も重要な左端の48ビットで満たされています。0〜47（オクテット0-5）を占有します。
ver:
ver:
The 4-bit version field as defined by Section 4.2, set to 0b0101 (5). Occupies bits 48 through 51 of octet 6.
セクション4.2で定義されている4ビットバージョンフィールドは、0B0101（5）に設定されています。オクテット6のビット48〜51を占有します。
sha1_mid:
sha1_mid：
12 more bits of the layout consisting of the least significant, rightmost 12 bits of 16 bits immediately following sha1_high from the computed SHA-1 value. Occupies bits 52 through 63 (octets 6-7).
計算されたSHA-1値からSHA1_highの直後に、16ビットの最も重要ではない、右端の12ビットからなるレイアウトの12ビット。52〜63（オクテット6-7）を占有します。
var:
var:
The 2-bit variant field as defined by Section 4.1, set to 0b10. Occupies bits 64 and 65 of octet 8.
セクション4.1で定義された2ビットバリアントフィールド、0B10に設定されています。Octet 8のビット64および65を占有します。
sha1_low:
sha1_low：
The final 62 bits of the layout immediately following the var field to be filled by skipping the two most significant, leftmost bits of the remaining SHA-1 hash and then using the next 62 most significant, leftmost bits. Any leftover SHA-1 bits are discarded and unused. Occupies bits 66 through 127 (octets 8-15).
VARフィールドの直後のレイアウトの最後の62ビットは、残りのSHA-1ハッシュの2つの最も重要な2つの左端のビットをスキップし、次の62の最も重要な左端のビットを使用することで満たされます。残りのSHA-1ビットは廃棄され、未使用です。66〜127（オクテット8-15）を占有します。
UUIDv6 is a field-compatible version of UUIDv1 (Section 5.1), reordered for improved DB locality. It is expected that UUIDv6 will primarily be implemented in contexts where UUIDv1 is used. Systems that do not involve legacy UUIDv1 SHOULD use UUIDv7 (Section 5.7) instead.
UUIDV6は、UUIDV1（セクション5.1）のフィールド互換バージョンであり、DB局所を改善するために並べ替えられています。UUIDV6が主にUUIDV1が使用されるコンテキストで実装されることが予想されます。Legacy UUIDV1を伴わないシステムは、代わりにUUIDV7（セクション5.7）を使用する必要があります。
Instead of splitting the timestamp into the low, mid, and high sections from UUIDv1, UUIDv6 changes this sequence so timestamp bytes are stored from most to least significant. That is, given a 60-bit timestamp value as specified for UUIDv1 in Section 5.1, for UUIDv6 the first 48 most significant bits are stored first, followed by the 4-bit version (same position), followed by the remaining 12 bits of the original 60-bit timestamp.
UUIDV1からタイムスタンプを低、中、および高セクションに分割する代わりに、UUIDV6はこのシーケンスを変更するため、タイムスタンプバイトは最も重要なものから最も重要なものに保存されます。つまり、セクション5.1でUUIDV1に指定された60ビットのタイムスタンプ値を与えられ、UUIDV6の最初の48の最も重要なビットが最初に保存され、その後4ビットバージョン（同じ位置）が続き、その後に残りの12ビットの残りの12ビットが続きます。オリジナルの60ビットタイムスタンプ。
The clock sequence and node bits remain unchanged from their position in Section 5.1.
クロックシーケンスとノードビットは、セクション5.1の位置から変更されません。
The clock sequence and node bits SHOULD be reset to a pseudorandom value for each new UUIDv6 generated; however, implementations MAY choose to retain the old clock sequence and MAC address behavior from Section 5.1. For more information on MAC address usage within UUIDs, see the Section 8.
クロックシーケンスとノードビットは、生成された新しいUUIDV6ごとに擬似ランダム値にリセットする必要があります。ただし、実装は、セクション5.1から古いクロックシーケンスとMACアドレスの動作を保持することを選択する場合があります。UUIDS内のMACアドレスの使用に関する詳細については、セクション8を参照してください。
The format for the 16-byte, 128-bit UUIDv6 is shown in Figure 10.
16バイトの128ビットUUIDV6の形式を図10に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time_high |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time_mid | ver | time_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| clock_seq | node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: UUIDv6 Field and Bit Layout
図10：UUIDV6フィールドとビットレイアウト
time_high:
time_high：
The most significant 32 bits of the 60-bit starting timestamp. Occupies bits 0 through 31 (octets 0-3).
60ビット開始タイムスタンプの中で最も重要な32ビット。0から31（オクテット0-3）を占有します。
time_mid:
time_mid：
The middle 16 bits of the 60-bit starting timestamp. Occupies bits 32 through 47 (octets 4-5).
60ビットの開始タイムスタンプの中央16ビット。32〜47（オクテット4-5）を占有します。
ver:
ver:
The 4-bit version field as defined by Section 4.2, set to 0b0110 (6). Occupies bits 48 through 51 of octet 6.
セクション4.2で定義されている4ビットバージョンフィールドは、0B0110（6）に設定されています。オクテット6のビット48〜51を占有します。
time_low:
time_low：
12 bits that will contain the least significant 12 bits from the 60-bit starting timestamp. Occupies bits 52 through 63 (octets 6-7).
60ビット開始タイムスタンプから最小の12ビットを含む12ビット。52〜63（オクテット6-7）を占有します。
var:
var:
The 2-bit variant field as defined by Section 4.1, set to 0b10. Occupies bits 64 and 65 of octet 8.
セクション4.1で定義された2ビットバリアントフィールド、0B10に設定されています。Octet 8のビット64および65を占有します。
clock_seq:
clock_seq：
The 14 bits containing the clock sequence. Occupies bits 66 through 79 (octets 8-9).
クロックシーケンスを含む14ビット。ビット66〜79（オクテット8-9）を占有します。
node:
ノード：
48-bit spatially unique identifier. Occupies bits 80 through 127 (octets 10-15).
48ビット空間的に一意の識別子。80〜127（オクテット10-15）を占有します。
With UUIDv6, the steps for splitting the timestamp into time_high and time_mid are OPTIONAL since the 48 bits of time_high and time_mid will remain in the same order. An extra step of splitting the first 48 bits of the timestamp into the most significant 32 bits and least significant 16 bits proves useful when reusing an existing UUIDv1 implementation.
UUIDV6を使用すると、48ビットのtime_highとtime_midが同じ順序で留まるため、タイムスタンプをtime_highとtime_midに分割する手順はオプションです。タイムスタンプの最初の48ビットを最も重要な32ビットに分割し、既存のUUIDV1実装を再利用するときに有用であることが証明されています。
UUIDv7 features a time-ordered value field derived from the widely implemented and well-known Unix Epoch timestamp source, the number of milliseconds since midnight 1 Jan 1970 UTC, leap seconds excluded. Generally, UUIDv7 has improved entropy characteristics over UUIDv1 (Section 5.1) or UUIDv6 (Section 5.6).
UUIDV7は、1970年1月1日以降のミリ秒数、広く知られているUnixエポックタイムスタンプのソースから、広く知られている有名なUNIXエポックタイムスタンプのソースから派生した時間順の値フィールドを備えています。一般に、UUIDV7はUUIDV1（セクション5.1）またはUUIDV6（セクション5.6）にわたってエントロピー特性を改善しました。
UUIDv7 values are created by allocating a Unix timestamp in milliseconds in the most significant 48 bits and filling the remaining 74 bits, excluding the required version and variant bits, with random bits for each new UUIDv7 generated to provide uniqueness as per Section 6.9. Alternatively, implementations MAY fill the 74 bits, jointly, with a combination of the following subfields, in this order from the most significant bits to the least, to guarantee additional monotonicity within a millisecond:
UUIDV7値は、最も重要な48ビットでミリ秒単位でUNIXタイムスタンプを割り当て、必要なバージョンとバリアントビットを除く残りの74ビットを埋めることによって作成されます。あるいは、実装は、この順序で最も重要なビットから最小に、ミリ秒以内に追加の単調性を保証するために、次のサブフィールドの組み合わせで74ビットを共同で埋めることができます。
1. An OPTIONAL sub-millisecond timestamp fraction (12 bits at maximum) as per Section 6.2 (Method 3).
1. セクション6.2（方法3）に従って、オプションのサブミリ秒のタイムスタンプ画分（最大で12ビット）。
2. An OPTIONAL carefully seeded counter as per Section 6.2 (Method 1 or 2).
2. セクション6.2（方法1または2）に従って、オプションの慎重にシードされたカウンター。
3. Random data for each new UUIDv7 generated for any remaining space.
3. 残りのスペースに対して生成された新しいUUIDV7ごとにランダムデータ。
Implementations SHOULD utilize UUIDv7 instead of UUIDv1 and UUIDv6 if possible.
可能であれば、実装はUUIDV1とUUIDV6の代わりにUUIDV7を利用する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unix_ts_ms |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unix_ts_ms | ver | rand_a |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| rand_b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rand_b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: UUIDv7 Field and Bit Layout
図11：UUIDV7フィールドとビットレイアウト
unix_ts_ms:
unix_ts_ms：
48-bit big-endian unsigned number of the Unix Epoch timestamp in milliseconds as per Section 6.1. Occupies bits 0 through 47 (octets 0-5).
セクション6.1に従って、ミリ秒単位のUNIXエポックタイムスタンプの48ビットのビッグエンディアンの署名数。0〜47（オクテット0-5）を占有します。
ver:
ver:
The 4-bit version field as defined by Section 4.2, set to 0b0111 (7). Occupies bits 48 through 51 of octet 6.
セクション4.2で定義されている4ビットバージョンフィールドは、0B0111（7）に設定されています。オクテット6のビット48〜51を占有します。
rand_a:
rand_a：
12 bits of pseudorandom data to provide uniqueness as per Section 6.9 and/or optional constructs to guarantee additional monotonicity as per Section 6.2. Occupies bits 52 through 63 (octets 6-7).
セクション6.9および/またはオプションのコンストラクトに従って一意性を提供する12ビットの擬似ランダムデータ。セクション6.2に従って追加の単調性を保証します。52〜63（オクテット6-7）を占有します。
var:
var:
The 2-bit variant field as defined by Section 4.1, set to 0b10. Occupies bits 64 and 65 of octet 8.
セクション4.1で定義された2ビットバリアントフィールド、0B10に設定されています。Octet 8のビット64および65を占有します。
rand_b:
rand_b：
The final 62 bits of pseudorandom data to provide uniqueness as per Section 6.9 and/or an optional counter to guarantee additional monotonicity as per Section 6.2. Occupies bits 66 through 127 (octets 8-15).
セクション6.9および/またはセクション6.2に従って追加の単調性を保証するオプションのカウンターに従って一意性を提供するための最後の62ビットの擬似ランダムデータ。66〜127（オクテット8-15）を占有します。
UUIDv8 provides a format for experimental or vendor-specific use cases. The only requirement is that the variant and version bits MUST be set as defined in Sections 4.1 and 4.2. UUIDv8's uniqueness will be implementation specific and MUST NOT be assumed.
UUIDV8は、実験またはベンダー固有のユースケースの形式を提供します。唯一の要件は、セクション4.1および4.2で定義されているように、バリアントおよびバージョンビットを設定する必要があることです。UUIDV8の一意性は実装固有のものであり、想定してはなりません。
The only explicitly defined bits are those of the version and variant fields, leaving 122 bits for implementation-specific UUIDs. To be clear, UUIDv8 is not a replacement for UUIDv4 (Section 5.4) where all 122 extra bits are filled with random data.
明示的に定義された唯一のビットは、バージョンとバリアントフィールドのビットであり、実装固有のUUIDのために122ビットが残ります。明確にするために、UUIDV8はUUIDV4（セクション5.4）の代替品ではありません。122個の追加ビットがすべてランダムデータで満たされています。
Some example situations in which UUIDv8 usage could occur:
UUIDV8の使用が発生する可能性のある状況の例：
* An implementation would like to embed extra information within the UUID other than what is defined in this document.
* 実装では、このドキュメントで定義されているもの以外に、UUIDに追加の情報を埋め込みます。
* An implementation has other application and/or language restrictions that inhibit the use of one of the current UUIDs.
* 実装には、現在のUUIDの1つの使用を阻害する他のアプリケーションおよび/または言語制限があります。
Appendix B provides two illustrative examples of custom UUIDv8 algorithms to address two example scenarios.
付録Bでは、2つの例のシナリオに対処するために、カスタムUUIDV8アルゴリズムの2つの説明例を示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| custom_a |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| custom_a | ver | custom_b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| custom_c |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| custom_c |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: UUIDv8 Field and Bit Layout
図12：UUIDV8フィールドとビットレイアウト
custom_a:
custom_a：
The first 48 bits of the layout that can be filled as an implementation sees fit. Occupies bits 0 through 47 (octets 0-5).
実装として埋めることができるレイアウトの最初の48ビットは適切です。0〜47（オクテット0-5）を占有します。
ver:
ver:
The 4-bit version field as defined by Section 4.2, set to 0b1000 (8). Occupies bits 48 through 51 of octet 6.
セクション4.2で定義されている4ビットバージョンフィールドは、0B1000（8）に設定されています。オクテット6のビット48〜51を占有します。
custom_b:
custom_b：
12 more bits of the layout that can be filled as an implementation sees fit. Occupies bits 52 through 63 (octets 6-7).
実装が適切であると見なされるように埋めることができるレイアウトのさらに12ビット。52〜63（オクテット6-7）を占有します。
var:
var:
The 2-bit variant field as defined by Section 4.1, set to 0b10. Occupies bits 64 and 65 of octet 8.
セクション4.1で定義された2ビットバリアントフィールド、0B10に設定されています。Octet 8のビット64および65を占有します。
custom_c:
custom_c：
The final 62 bits of the layout immediately following the var field to be filled as an implementation sees fit. Occupies bits 66 through 127 (octets 8-15).
VARフィールドの直後のレイアウトの最後の62ビットは、実装が適切であると見なされるようになります。66〜127（オクテット8-15）を占有します。
The Nil UUID is special form of UUID that is specified to have all 128 bits set to zero.
nil uuidは、128ビットすべてがゼロに設定されるように指定されている特別な形式のuuidです。
00000000-0000-0000-0000-000000000000
Figure 13: Nil UUID Format
図13：nil uuid形式
A Nil UUID value can be useful to communicate the absence of any other UUID value in situations that otherwise require or use a 128-bit UUID. A Nil UUID can express the concept "no such value here". Thus, it is reserved for such use as needed for implementation-specific situations.
NIL UUID値は、128ビットUUIDを必要とするか使用する状況で他のUUID値がないことを伝えるのに役立ちます。nil uuidは、「ここにはそのような価値はない」という概念を表現できます。したがって、実装固有の状況に必要に応じて使用するために予約されています。
Note that the Nil UUID value falls within the range of the Apollo NCS variant as per the first row of Table 1 rather than the variant defined by this document.
NIL UUID値は、このドキュメントで定義されたバリアントではなく、表1の最初の行に従ってApollo NCSバリアントの範囲内に収まることに注意してください。
The Max UUID is a special form of UUID that is specified to have all 128 bits set to 1. This UUID can be thought of as the inverse of the Nil UUID defined in Section 5.9.
Max UUIDは、128ビットすべてを1に設定するように指定されている特別な形式のUUIDです。このUUIDは、セクション5.9で定義されているNil UUIDの逆と考えることができます。
FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF
Figure 14: Max UUID Format
図14：最大UUID形式
A Max UUID value can be used as a sentinel value in situations where a 128-bit UUID is required, but a concept such as "end of UUID list" needs to be expressed and is reserved for such use as needed for implementation-specific situations.
最大値は、128ビットUUIDが必要な状況ではセンチネル値として使用できますが、「UUIDリストの終了」などの概念を表現する必要があり、実装固有の状況に必要な使用のために予約されています。。
Note that the Max UUID value falls within the range of the "yet-to-be defined" future UUID variant as per the last row of Table 1 rather than the variant defined by this document.
最大値は、このドキュメントで定義されたバリアントではなく、表1の最後の行に従って、「まだ定義されていない」将来のUUIDバリアントの範囲内にあることに注意してください。
The minimum requirements for generating UUIDs of each version are described in this document. Everything else is an implementation detail, and it is up to the implementer to decide what is appropriate for a given implementation. Various relevant factors are covered below to help guide an implementer through the different trade-offs among differing UUID implementations.
各バージョンのUUIDを生成するための最小要件は、このドキュメントで説明されています。他のすべては実装の詳細であり、特定の実装に適したものを決定するのは実装者次第です。さまざまなUUID実装間のさまざまなトレードオフを通じて、実装者を導くのに役立つさまざまな関連要因について説明します。
UUID timestamp source, precision, and length were topics of great debate while creating UUIDv7 for this specification. Choosing the right timestamp for your application is very important. This section will detail some of the most common points on this issue.
UUIDタイムスタンプのソース、精度、および長さは、この仕様のためにUUIDV7を作成する際の大きな議論のトピックでした。アプリケーションに適したタイムスタンプを選択することは非常に重要です。このセクションでは、この問題に関する最も一般的なポイントのいくつかについて説明します。
Reliability:
信頼性：
Implementations acquire the current timestamp from a reliable source to provide values that are time ordered and continually increasing. Care must be taken to ensure that timestamp changes from the environment or operating system are handled in a way that is consistent with implementation requirements. For example, if it is possible for the system clock to move backward due to either manual adjustment or corrections from a time synchronization protocol, implementations need to determine how to handle such cases. (See "Altering, Fuzzing, or Smearing" below.)
実装は、信頼できるソースから現在のタイムスタンプを取得して、時間順序と継続的に増加する値を提供します。環境またはオペレーティングシステムからのタイムスタンプの変更が、実装要件と一致する方法で処理されるように注意する必要があります。たとえば、時間同期プロトコルからの手動調整または修正のいずれかのためにシステムクロックが後方に移動できる場合、そのようなケースの処理方法を決定する必要があります。（以下の「変更、ファジング、または塗抹」を参照してください。）
Source:
ソース：
UUIDv1 and UUIDv6 both utilize a Gregorian Epoch timestamp, while UUIDv7 utilizes a Unix Epoch timestamp. If other timestamp sources or a custom timestamp Epoch are required, UUIDv8 MUST be used.
UUIDV1とUUIDV6はどちらもグレゴリオエポックタイムスタンプを利用し、UUIDV7はUNIXエポックタイムスタンプを利用しています。他のタイムスタンプソースまたはカスタムタイムスタンプエポックが必要な場合は、UUIDV8を使用する必要があります。
Sub-second Precision and Accuracy:
サブ秒の精度と精度：
Many levels of precision exist for timestamps: milliseconds, microseconds, nanoseconds, and beyond. Additionally, fractional representations of sub-second precision may be desired to mix various levels of precision in a time-ordered manner. Furthermore, system clocks themselves have an underlying granularity, which is frequently less than the precision offered by the operating system. With UUIDv1 and UUIDv6, 100 nanoseconds of precision are present, while UUIDv7 features a millisecond level of precision by default within the Unix Epoch that does not exceed the granularity capable in most modern systems. For other levels of precision, UUIDv8 is available. Similar to Section 6.2, with UUIDv1 or UUIDv6, a high-resolution timestamp can be simulated by keeping a count of the number of UUIDs that have been generated with the same value of the system time and using that count to construct the low order bits of the timestamp. The count of the high-resolution timestamp will range between zero and the number of 100-nanosecond intervals per system-time interval.
タイムスタンプには多くのレベルの精度が存在します：ミリ秒、マイクロ秒、ナノ秒、その他。さらに、さまざまなレベルの精度を時間順で混合するために、サブ秒の精度の分数表現が望まれる場合があります。さらに、システムクロック自体には、根本的な粒度があります。これは、オペレーティングシステムが提供する精度よりも少ないことが多いです。UUIDV1およびUUIDV6では、100ナノ秒の精度が存在しますが、UUIDV7は、ほとんどの現代システムで能力がある粒度を超えないUNIXエポック内でデフォルトでミリ秒レベルの精度を備えています。他のレベルの精度については、UUIDV8が利用可能です。セクション6.2と同様に、UUIDV1またはUUIDV6を使用して、高解像度のタイムスタンプをシミュレートすることができます。システム時間の同じ値で生成されたUUIDの数をカウントし、そのカウントを使用して低次ビットを構築することができます。タイムスタンプ。高解像度のタイムスタンプのカウントは、システム時間間隔ごとにゼロと100ナノ秒間隔の範囲の範囲です。
Length:
長さ：
The length of a given timestamp directly impacts how many timestamp ticks can be contained in a UUID before the maximum value for the timestamp field is reached. Take care to ensure that the proper length is selected for a given timestamp. UUIDv1 and UUIDv6 utilize a 60-bit timestamp valid until 5623 AD; UUIDv7 features a 48-bit timestamp valid until the year 10889 AD.
特定のタイムスタンプの長さは、タイムスタンプフィールドの最大値に到達する前に、UUIDに含まれるタイムスタンプティックの数に直接影響します。特定のタイムスタンプに対して適切な長さが選択されるように注意してください。UUIDV1とUUIDV6は、5623 ADまで有効な60ビットタイムスタンプを使用します。UUIDV7は、西暦10889年まで有効な48ビットタイムスタンプを備えています。
Altering, Fuzzing, or Smearing:
変更、ファジング、またはスミアリング：
Implementations MAY alter the actual timestamp. Some examples include security considerations around providing a real-clock value within a UUID to 1) correct inaccurate clocks, 2) handle leap seconds, or 3) obtain a millisecond value by dividing by 1024 (or some other value) for performance reasons (instead of dividing a number of microseconds by 1000). This specification makes no requirement or guarantee about how close the clock value needs to be to the actual time. If UUIDs do not need to be frequently generated, the UUIDv1 or UUIDv6 timestamp can simply be the system time multiplied by the number of 100-nanosecond intervals per system-time interval.
実装により、実際のタイムスタンプが変更される場合があります。いくつかの例には、UUID内で1）1）不正確なクロックを修正する、2）秒数秒、または3）パフォーマンス上の理由で1024（またはその他の値）で除算してミリ秒値を取得することに関するセキュリティ上の考慮事項が含まれます（代わりに）多数のマイクロ秒を1000で割る）。この仕様は、クロック値が実際の時間にどれだけ近いかについての要件や保証を行いません。UUIDを頻繁に生成する必要がない場合、UUIDV1またはUUIDV6タイムスタンプは、システム時間間隔ごとに100ナノ秒間隔の数を平均化することができます。
Padding:
パディング：
When timestamp padding is required, implementations MUST pad the most significant bits (leftmost) with data. An example for this padding data is to fill the most significant, leftmost bits of a Unix timestamp with zeroes to complete the 48-bit timestamp in UUIDv7. An alternative approach for padding data is to fill the most significant, leftmost bits with the number of 32-bit Unix timestamp rollovers after 2038-01-19.
タイムスタンプのパディングが必要な場合、実装はデータを使用して最も重要なビット（左端）をパッドパッドする必要があります。このパディングデータの例は、UUIDV7の48ビットタイムスタンプを完了するために、ゼロのUnixタイムスタンプの最も重要な左端のビットを埋めることです。パディングデータの別のアプローチは、2038-01-19以降、最も重要な左端のビットを32ビットUnixタイムスタンプロールオーバーで埋めることです。
Truncating:
切り捨て：
When timestamps need to be truncated, the lower, least significant bits MUST be used. An example would be truncating a 64-bit Unix timestamp to the least significant, rightmost 48 bits for UUIDv7.
タイムスタンプを切り捨てる必要がある場合、より低い、最も有意なビットを使用する必要があります。例としては、64ビットUNIXタイムスタンプをUUIDV7の最も重要でない右端の48ビットに切り捨てることです。
Error Handling:
エラー処理：
If a system overruns the generator by requesting too many UUIDs within a single system-time interval, the UUID service can return an error or stall the UUID generator until the system clock catches up and MUST NOT knowingly return duplicate values due to a counter rollover. Note that if the processors overrun the UUID generation frequently, additional Node IDs can be allocated to the system, which will permit higher speed allocation by making multiple UUIDs potentially available for each timestamp value. Similar techniques are discussed in Section 6.4.
システムが単一のシステム時間間隔内であまりにも多くのUUIDを要求してジェネレーターをオーバーランする場合、UUIDサービスは、システムクロックがキャッチアップするまでエラーを返したり、UUIDジェネレーターを失速させたり、カウンターロールオーバーのために重複した値を故意に返してはなりません。プロセッサがUUID生成を頻繁にオーバーランする場合、追加のノードIDをシステムに割り当てることができ、各タイムスタンプ値で複数のUUIDを潜在的に利用できるようにすることで高速割り当てが可能になります。同様の手法については、セクション6.4で説明します。
Monotonicity (each subsequent value being greater than the last) is the backbone of time-based sortable UUIDs. Normally, time-based UUIDs from this document will be monotonic due to an embedded timestamp; however, implementations can guarantee additional monotonicity via the concepts covered in this section.
単調性（それぞれの後続の値は最後よりも大きい）は、時間ベースのソート可能なUUIDのバックボーンです。通常、このドキュメントからの時間ベースのUUIDは、タイムスタンプが組み込まれているため、単調になります。ただし、実装は、このセクションで説明されている概念を介して追加の単調性を保証できます。
Take care to ensure UUIDs generated in batches are also monotonic. That is, if one thousand UUIDs are generated for the same timestamp, there should be sufficient logic for organizing the creation order of those one thousand UUIDs. Batch UUID creation implementations MAY utilize a monotonic counter that increments for each UUID created during a given timestamp.
バッチで生成されたUUIDも単調であることを確認してください。つまり、同じタイムスタンプに対して1000のUUIDが生成された場合、これらの千のuuidの作成順序を整理するための十分なロジックがあるはずです。バッチUUID作成の実装は、特定のタイムスタンプ中に作成された各UUIDの増分を単調なカウンターで利用する場合があります。
For single-node UUID implementations that do not need to create batches of UUIDs, the embedded timestamp within UUIDv6 and UUIDv7 can provide sufficient monotonicity guarantees by simply ensuring that timestamp increments before creating a new UUID. Distributed nodes are discussed in Section 6.4.
UUIDのバッチを作成する必要のないシングルノードUUID実装の場合、UUIDV6およびUUIDV7に埋め込まれたタイムスタンプは、新しいUUIDを作成する前にタイムスタンプが増加することを保証することで、十分な単調性保証を提供できます。分散ノードについては、セクション6.4で説明します。
Implementations SHOULD employ the following methods for single-node UUID implementations that require batch UUID creation or are otherwise concerned about monotonicity with high-frequency UUID generation.
実装は、バッチUUIDの作成を必要とする、または高周波UUID生成の単調性を懸念する単一ノードUUID実装に次の方法を採用する必要があります。
Fixed Bit-Length Dedicated Counter (Method 1):
ビットレングス専用カウンターを修正しました（方法1）：
Some implementations allocate a specific number of bits in the UUID layout to the sole purpose of tallying the total number of UUIDs created during a given UUID timestamp tick. If present, a fixed bit-length counter MUST be positioned immediately after the embedded timestamp. This promotes sortability and allows random data generation for each counter increment. With this method, the rand_a section (or a subset of its leftmost bits) of UUIDv7 is used as a fixed bit-length dedicated counter that is incremented for every UUID generation. The trailing random bits generated for each new UUID in rand_b can help produce unguessable UUIDs. In the event that more counter bits are required, the most significant (leftmost) bits of rand_b MAY be used as additional counter bits.
一部の実装では、特定のUUIDタイムスタンプティック中に作成されたUUIDの総数を集計するという唯一の目的に、UUIDレイアウトの特定のビット数を割り当てます。存在する場合、埋め込まれたタイムスタンプの直後に固定ビット長カウンターを配置する必要があります。これにより、ソート性が促進され、各カウンター増分のランダムデータ生成が可能になります。この方法では、UUIDV7のRAND_Aセクション（またはその左端ビットのサブセット）は、すべてのUUID生成に対して増分される固定ビット長専用カウンターとして使用されます。RAND_Bの新しいUUIDごとに生成された後続のランダムビットは、装備できないUUIDを生成するのに役立ちます。より多くのカウンタービットが必要な場合、RAND_Bの最も重要な（左端）ビットを追加のカウンタービットとして使用できます。
Monotonic Random (Method 2):
単調なランダム（方法2）：
With this method, the random data is extended to also function as a counter. This monotonic value can be thought of as a "randomly seeded counter" that MUST be incremented in the least significant position for each UUID created on a given timestamp tick. UUIDv7's rand_b section SHOULD be utilized with this method to handle batch UUID generation during a single timestamp tick. The increment value for every UUID generation is a random integer of any desired length larger than zero. It ensures that the UUIDs retain the required level of unguessability provided by the underlying entropy. The increment value MAY be 1 when the number of UUIDs generated in a particular period of time is important and guessability is not an issue. However, incrementing the counter by 1 SHOULD NOT be used by implementations that favor unguessability, as the resulting values are easily guessable.
この方法では、ランダムデータが拡張され、カウンターとしても機能します。この単調な値は、特定のタイムスタンプティックで作成された各UUIDの最も重要な位置でインクリメントする必要がある「ランダムにシードされたカウンター」と考えることができます。UUIDV7のRAND_Bセクションは、この方法で使用して、単一のタイムスタンプティック中にバッチUUID生成を処理する必要があります。すべてのUUID生成の増分値は、ゼロより大きい任意の任意の長さのランダム整数です。これにより、UUIDは、基礎となるエントロピーによって提供される不安定性の必要なレベルを保持します。特定の期間に生成されたUUIDの数が重要であり、推測可能性が問題ではない場合、増分値は1になる可能性があります。ただし、結果の値は簡単に推測できるため、カウンターを1倍に増やすことは、不適格ではないことを支持する実装では使用しないでください。
Replace Leftmost Random Bits with Increased Clock Precision (Method 3):
左端のランダムビットを、クロック精度の増加に置き換えます（方法3）：
For UUIDv7, which has millisecond timestamp precision, it is possible to use additional clock precision available on the system to substitute for up to 12 random bits immediately following the timestamp. This can provide values that are time ordered with sub-millisecond precision, using however many bits are appropriate in the implementation environment. With this method, the additional time precision bits MUST follow the timestamp as the next available bit in the rand_a field for UUIDv7.
ミリ秒のタイムスタンプ精度を持つUUIDV7の場合、システムで利用可能な追加のクロック精度を使用して、タイムスタンプの直後に最大12のランダムビットを代用することができます。これにより、実装環境では多くのビットが適切であるが、サブミリ秒の精度で順序付けられる時間の値を提供できます。この方法では、追加の時間精度ビットは、UUIDV7のRAND_Aフィールドで次の利用可能なビットとしてタイムスタンプをたどる必要があります。
To calculate this value, start with the portion of the timestamp expressed as a fraction of the clock's tick value (fraction of a millisecond for UUIDv7). Compute the count of possible values that can be represented in the available bit space, 4096 for the UUIDv7 rand_a field. Using floating point or scaled integer arithmetic, multiply this fraction of a millisecond value by 4096 and round down (toward zero) to an integer result to arrive at a number between 0 and the maximum allowed for the indicated bits, which sorts monotonically based on time. Each increasing fractional value will result in an increasing bit field value to the precision available with these bits.
この値を計算するには、クロックのティック値の一部として表されたタイムスタンプの部分（UUIDV7のミリ秒の割合）から始めます。UUIDV7 RAND_Aフィールドでは、利用可能なビットスペース、4096で表現できる可能性のある値のカウントを計算します。フローティングポイントまたはスケーリングされた整数算術を使用して、この分数のミリ秒値の割合を4096と切り下げ（ゼロに向かって）に掛けて、指定されたビットに許可された0から許可された最大数に到達します。。分数値が増加するたびに、これらのビットで利用可能な精度にビットフィールド値が増加します。
For example, let's assume a system timestamp of 1 Jan 2023 12:34:56.1234567. Taking the precision greater than 1 ms gives us a value of 0.4567, as a fraction of a millisecond. If we wish to encode this as 12 bits, we can take the count of possible values that fit in those bits (4096 or 2^12), multiply it by our millisecond fraction value of 0.4567, and truncate the result to an integer, which gives an integer value of 1870. Expressed as hexadecimal, it is 0x74E or the binary bits 0b011101001110. One can then use those 12 bits as the most significant (leftmost) portion of the random section of the UUID (e.g., the rand_a field in UUIDv7). This works for any desired bit length that fits into a UUID, and applications can decide the appropriate length based on available clock precision; for UUIDv7, it is limited to 12 bits at maximum to reserve sufficient space for random bits.
たとえば、2023年1月1日のシステムタイムスタンプ12：34：56.1234567を想定しましょう。1 msを超える精度をとると、数ミリ秒のわずかな値として、0.4567の値が得られます。これを12ビットとしてエンコードしたい場合は、それらのビット（4096または2^12）に適合する可能性のある値のカウントを取得し、ミリ秒の画分値0.4567を掛け、結果を整数に切り捨てます。1870年の整数値を与えます。ヘキサデシマルとして表され、0x74Eまたはバイナリビット0B011101001110です。その後、これらの12ビットをUUIDのランダムセクションの最も重要な（左端）部分（UUIDV7のRAND_Aフィールドなど）として使用できます。これは、UUIDに収まる任意の任意のビット長で機能し、アプリケーションは利用可能なクロック精度に基づいて適切な長さを決定できます。UUIDV7の場合、ランダムビットのための十分なスペースを予約するために、最大で12ビットに制限されています。
The main benefit to encoding additional timestamp precision is that it utilizes additional time precision already available in the system clock to provide values that are more likely to be unique; thus, it may simplify certain implementations. This technique can also be used in conjunction with one of the other methods, where this additional time precision would immediately follow the timestamp. Then, if any bits are to be used as a clock sequence, they would follow next.
追加のタイムスタンプ精度をエンコードすることの主な利点は、システムクロックですでに利用可能な追加の時間精度を利用して、一意になる可能性が高い値を提供することです。したがって、特定の実装を簡素化する場合があります。この手法は、他の方法のいずれかと組み合わせて使用することもできます。この方法では、この追加の時間精度がタイムスタンプに直後に続きます。次に、ビットをクロックシーケンスとして使用する場合、次に続きます。
The following sub-topics cover issues related solely to creating reliable fixed bit-length dedicated counters:
次のサブトピックは、信頼できる固定ビット長の専用カウンターの作成にのみ関連する問題をカバーしています。
Fixed Bit-Length Dedicated Counter Seeding:
ビットレングスの専用カウンターシードを修正しました：
Implementations utilizing the fixed bit-length counter method randomly initialize the counter with each new timestamp tick. However, when the timestamp has not increased, the counter is instead incremented by the desired increment logic. When utilizing a randomly seeded counter alongside Method 1, the random value MAY be regenerated with each counter increment without impacting sortability. The downside is that Method 1 is prone to overflows if a counter of adequate length is not selected or the random data generated leaves little room for the required number of increments. Implementations utilizing fixed bit-length counter method MAY also choose to randomly initialize a portion of the counter rather than the entire counter. For example, a 24-bit counter could have the 23 bits in least significant, rightmost position randomly initialized. The remaining most significant, leftmost counter bit is initialized as zero for the sole purpose of guarding against counter rollovers.
固定ビット長カウンターメソッドを使用して、新しいタイムスタンプティックごとにカウンターをランダムに初期化します。ただし、タイムスタンプが増加していない場合、代わりにカウンターは目的の増分ロジックによって増加します。方法1と一緒にランダムにシードされたカウンターを使用する場合、ランダム値は、ソート性に影響を与えることなく、各カウンター増分で再生される場合があります。欠点は、適切な長さのカウンターが選択されていない場合、または生成されたランダムデータが必要な増分の余地がほとんどない場合、方法1がオーバーフローする傾向があることです。固定ビット長カウンターメソッドを使用している実装では、カウンター全体ではなく、カウンターの一部をランダムに初期化することもできます。たとえば、24ビットのカウンターは、23ビットが少なくとも有意な右端の位置をランダムに初期化することができます。残りの最も重要な左端のカウンタービットは、カウンターロールオーバーを守るという唯一の目的のために、ゼロとして初期化されます。
Fixed Bit-Length Dedicated Counter Length:
ビットレングス専用のカウンター長を修正しました：
Select a counter bit-length that can properly handle the level of timestamp precision in use. For example, millisecond precision generally requires a larger counter than a timestamp with nanosecond precision. General guidance is that the counter SHOULD be at least 12 bits but no longer than 42 bits. Care must be taken to ensure that the counter length selected leaves room for sufficient entropy in the random portion of the UUID after the counter. This entropy helps improve the unguessability characteristics of UUIDs created within the batch.
使用中のタイムスタンプ精度のレベルを適切に処理できるカウンタービットレングスを選択します。たとえば、ミリ秒の精度には、一般に、ナノ秒精度のあるタイムスタンプよりも大きなカウンターが必要です。一般的なガイダンスは、カウンターは少なくとも12ビットであるが、42ビット以下である必要があるということです。カウンターの長さが、カウンターの後にUUIDのランダム部分に十分なエントロピーのための部屋を去ることを保証するために注意する必要があります。このエントロピーは、バッチ内で作成されたUUIDの不安定な特性を改善するのに役立ちます。
The following sub-topics cover rollover handling with either type of counter method:
次のサブトピックは、いずれかのタイプのカウンターメソッドを使用したロールオーバーハンドリングをカバーします。
Counter Rollover Guards:
カウンターロールオーバーガード：
The technique from "Fixed Bit-Length Dedicated Counter Seeding" above that describes allocating a segment of the fixed bit-length counter as a rollover guard is also helpful to mitigate counter rollover issues. This same technique can be used with monotonic random counter methods by ensuring that the total length of a possible increment in the least significant, rightmost position is less than the total length of the random value being incremented. As such, the most significant, leftmost bits can be incremented as rollover guarding.
ロールオーバーガードとして固定ビット長カウンターのセグメントを割り当てることを説明する「固定ビット長専用カウンターシード」の手法は、カウンターロールオーバーの問題を軽減するのにも役立ちます。この同じ手法は、最も重要でない右端の位置での可能な増分の総長さが増分されるランダム値の総長さよりも少ないことを保証することにより、単調なランダムカウンターメソッドで使用できます。そのため、最も重要な左端のビットは、ロールオーバーガードとして増加することができます。
Counter Rollover Handling:
カウンターロールオーバー処理：
Counter rollovers MUST be handled by the application to avoid sorting issues. The general guidance is that applications that care about absolute monotonicity and sortability should freeze the counter and wait for the timestamp to advance, which ensures monotonicity is not broken. Alternatively, implementations MAY increment the timestamp ahead of the actual time and reinitialize the counter.
ソートの問題を避けるために、カウンターロールオーバーはアプリケーションによって処理する必要があります。一般的なガイダンスは、絶対的な単調性とソート性を気にするアプリケーションは、カウンターをフリーズし、タイムスタンプが前進するのを待つべきであるということです。あるいは、実装は、実際の時間よりも先にタイムスタンプを増やし、カウンターを再編成する場合があります。
Implementations MAY use the following logic to ensure UUIDs featuring embedded counters are monotonic in nature:
実装は、次のロジックを使用して、組み込みカウンターを特徴とするUUIDが本質的に単調であることを確認する場合があります。
1. Compare the current timestamp against the previously stored timestamp.
1. 現在のタイムスタンプを、以前に保存したタイムスタンプと比較してください。
2. If the current timestamp is equal to the previous timestamp, increment the counter according to the desired method.
2. 現在のタイムスタンプが以前のタイムスタンプに等しい場合、目的の方法に従ってカウンターを増やします。
3. If the current timestamp is greater than the previous timestamp, re-initialize the desired counter method to the new timestamp and generate new random bytes (if the bytes were frozen or being used as the seed for a monotonic counter).
3. 現在のタイムスタンプが以前のタイムスタンプよりも大きい場合は、新しいタイムスタンプに目的のカウンターメソッドを再目立てし、新しいランダムバイトを生成します（バイトが凍結されているか、単調カウンターのシードとして使用されている場合）。
Monotonic Error Checking:
単調なエラーチェック：
Implementations SHOULD check if the currently generated UUID is greater than the previously generated UUID. If this is not the case, then any number of things could have occurred, such as clock rollbacks, leap second handling, and counter rollovers. Applications SHOULD embed sufficient logic to catch these scenarios and correct the problem to ensure that the next UUID generated is greater than the previous, or they should at least report an appropriate error. To handle this scenario, the general guidance is that the application MAY reuse the previous timestamp and increment the previous counter method.
実装は、現在生成されているUUIDが以前に生成されたUUIDよりも大きいかどうかを確認する必要があります。そうでない場合は、クロックロールバック、跳躍中断ハンドリング、カウンターロールバーなど、多くのことが発生した可能性があります。アプリケーションは、これらのシナリオをキャッチし、問題を修正して、次のUUIDが以前よりも大きいことを確認するのに十分なロジックを埋め込む必要があります。または、少なくとも適切なエラーを報告する必要があります。このシナリオを処理するために、一般的なガイダンスは、アプリケーションが以前のタイムスタンプを再利用し、以前のカウンターメソッドをインクリメントする可能性があることです。
The (optional) UUID generator state only needs to be read from stable storage once at boot time, if it is read into a system-wide shared volatile store (and updated whenever the stable store is updated).
（オプションの）UUIDジェネレーター状態は、システム全体の共有揮発性ストアに読み取られた場合（および安定したストアが更新されるたびに更新される場合）、ブート時に安定したストレージから読み取る必要があります。
This stable storage MAY be used to record various portions of the UUID generation, which prove useful for batch UUID generation purposes and monotonic error checking with UUIDv6 and UUIDv7. These stored values include but are not limited to last known timestamp, clock sequence, counters, and random data.
この安定したストレージは、UUID生成のさまざまな部分を記録するために使用できます。これは、UUIDV6およびUUIDV7でのバッチUUID生成の目的と単調なエラーチェックに役立ちます。これらの保存された値には、最後の既知のタイムスタンプ、クロックシーケンス、カウンター、およびランダムデータが含まれますが、これらに限定されません。
If an implementation does not have any stable store available, then it MAY proceed with UUID generation as if this were the first UUID created within a batch. This is the least desirable implementation because it will increase the frequency of creation of values such as clock sequence, counters, or random data, which increases the probability of duplicates. Further, frequent generation of random numbers also puts more stress on any entropy source and/or entropy pool being used as the basis for such random numbers.
実装に安定したストアが利用できない場合、これがバッチ内で作成された最初のUUIDであるかのようにUUID世代を進めることができます。これは、複製の確率を高めるクロックシーケンス、カウンター、ランダムデータなどの値の作成頻度を増加させるため、最も望ましい実装です。さらに、乱数の頻繁な生成は、そのような乱数の基礎として使用されるエントロピー源および/またはエントロピープールにもより多くのストレスをかけます。
An implementation MAY also return an application error in the event that collision resistance is of the utmost concern. The semantics of this error are up to the application and implementation. See Section 6.7 for more information on weighting collision tolerance in applications.
衝突抵抗が最大限の懸念事項である場合、実装はアプリケーションエラーを返す場合があります。このエラーのセマンティクスは、アプリケーションと実装次第です。アプリケーションの重み付け衝突耐性の詳細については、セクション6.7を参照してください。
For UUIDv1 and UUIDv6, if the Node ID can never change (e.g., the network interface card from which the Node ID is derived is inseparable from the system), or if any change also re-initializes the clock sequence to a random value, then instead of keeping it in stable store, the current Node ID may be returned.
uuidv1およびuuidv6の場合、ノードIDが変更されない場合（たとえば、ノードIDが導出されるネットワークインターフェイスカードはシステムとは分離できません）、または変更がクロックシーケンスをランダムな値に再開化し、次に変更する場合、安定したストアに保持する代わりに、現在のノードIDが返される場合があります。
For UUIDv1 and UUIDv6, the state does not always need to be written to stable store every time a UUID is generated. The timestamp in the stable store can periodically be set to a value larger than any yet used in a UUID. As long as the generated UUIDs have timestamps less than that value, and the clock sequence and Node ID remain unchanged, only the shared volatile copy of the state needs to be updated. Furthermore, if the timestamp value in stable store is in the future by less than the typical time it takes the system to reboot, a crash will not cause a re-initialization of the clock sequence.
UUIDV1およびUUIDV6の場合、UUIDが生成されるたびに、状態を安定したストアに常に書き込む必要はありません。安定したストアのタイムスタンプは、UUIDで使用されているまだ大きい値に定期的に設定できます。生成されたUUIDのタイムスタンプがその値よりも少なく、クロックシーケンスとノードIDが変更されていないままである限り、状態の共有揮発性コピーのみを更新する必要があります。さらに、安定したストアのタイムスタンプの値が、システムが再起動するのにかかる通常の時間よりも将来的に将来的に将来的にある場合、クラッシュはクロックシーケンスの再初期化を引き起こしません。
If it is too expensive to access shared state each time a UUID is generated, then the system-wide generator can be implemented to allocate a block of timestamps each time it is called; a per-process generator can allocate from that block until it is exhausted.
UUIDが生成されるたびに共有状態にアクセスするには高すぎる場合、システム全体のジェネレーターを実装して、呼び出されるたびにタイムスタンプのブロックを割り当てることができます。プロセスごとの発電機は、疲れるまでそのブロックから割り当てることができます。
Some implementations MAY desire the utilization of multi-node, clustered, applications that involve two or more nodes independently generating UUIDs that will be stored in a common location. While UUIDs already feature sufficient entropy to ensure that the chances of collision are low, as the total number of UUID generating nodes increases, so does the likelihood of a collision.
一部の実装では、共通の場所に保存されるUUIDを個別に生成する2つ以上のノードを含むマルチノード、クラスター化されたアプリケーションの使用率を希望する場合があります。UUIDは、UUID生成ノードの総数が増加するにつれて衝突の可能性が低いことを保証するのに十分なエントロピーを既に備えていますが、衝突の可能性も増加します。
This section will detail the two additional collision resistance approaches that have been observed by multi-node UUID implementations in distributed environments.
このセクションでは、分散環境でのマルチノードUUID実装によって観察された2つの追加の衝突抵抗アプローチについて詳しく説明します。
It should be noted that, although this section details two methods for the sake of completeness, implementations should utilize the pseudorandom Node ID option if additional collision resistance for distributed UUID generation is a requirement. Likewise, utilization of either method is not required for implementing UUID generation in distributed environments.
このセクションでは、完全性のために2つの方法を詳しく説明していますが、分散UUID生成の追加の衝突抵抗が要件である場合、実装は擬似ランダムノードIDオプションを利用する必要があることに注意してください。同様に、分散環境でUUID生成を実装するためには、いずれかの方法の使用は必要ありません。
Node IDs:
ノードID：
With this method, a pseudorandom Node ID value is placed within the UUID layout. This identifier helps ensure the bit space for a given node is unique, resulting in UUIDs that do not conflict with any other UUID created by another node with a different node id. Implementations that choose to leverage an embedded node id SHOULD utilize UUIDv8. The node id SHOULD NOT be an IEEE 802 MAC address per Section 8. The location and bit length are left to implementations and are outside the scope of this specification. Furthermore, the creation and negotiation of unique node ids among nodes is also out of scope for this specification.
この方法では、擬似ランダムノードID値がUUIDレイアウト内に配置されます。この識別子は、特定のノードのビットスペースが一意であることを確認するのに役立ち、別のノードIDを持つ別のノードによって作成された他のUUIDと競合しないUUIDが生じます。埋め込みノードIDを活用することを選択する実装は、UUIDV8を利用する必要があります。ノードIDは、セクション8ごとにIEEE 802 MACアドレスではありません。場所とビットの長さは実装に任され、この仕様の範囲外です。さらに、ノード間の一意のノードIDの作成と交渉も、この仕様の範囲外です。
Centralized Registry:
集中レジストリ：
With this method, all nodes tasked with creating UUIDs consult a central registry and confirm the generated value is unique. As applications scale, the communication with the central registry could become a bottleneck and impact UUID generation in a negative way. Shared knowledge schemes with central/global registries are outside the scope of this specification and are NOT RECOMMENDED.
この方法では、UUIDSの作成を課すすべてのノードが中央レジストリに相談し、生成された値が一意であることを確認します。アプリケーションが拡大するにつれて、中央レジストリとの通信はボトルネックになり、UUIDの生成に否定的な方法で影響を与える可能性があります。中央/グローバルレジストリと共有された知識スキームは、この仕様の範囲外であり、推奨されません。
Distributed applications generating UUIDs at a variety of hosts MUST be willing to rely on the random number source at all hosts.
さまざまなホストでUUIDを生成する分散アプリケーションは、すべてのホストの乱数ソースに頼ることをいとわない必要があります。
Although some prefer to use the word "hash-based" to describe UUIDs featuring hashing algorithms (MD5 or SHA-1), this document retains the usage of the term "name-based" in order to maintain consistency with previously published documents and existing implementations.
ハッシュアルゴリズム（MD5またはSHA-1）を特徴とするUUIDを記述するために「ハッシュベース」という単語を使用することを好む人もいますが、このドキュメントは、以前に公開されたドキュメントや既存のドキュメントとの一貫性を維持するために「名前ベース」という用語の使用を保持しています。実装。
The requirements for name-based UUIDs are as follows:
名前ベースのUUIDの要件は次のとおりです。
* UUIDs generated at different times from the same name (using the same canonical format) in the same namespace MUST be equal.
* 同じ名前（同じ標準形式を使用）から異なる時間に生成されたUUIDは、同じ名前空間で等しくなければなりません。
* UUIDs generated from two different names (same or differing canonical format) in the same namespace should be different (with very high probability).
* 同じ名前空間で2つの異なる名前（同じまたは異なる標準形式）から生成されたUUIDは異なる必要があります（非常に高い確率で）。
* UUIDs generated from the same name (same or differing canonical format) in two different namespaces should be different (with very high probability).
* 2つの異なる名前空間で同じ名前（同じまたは異なる標準形式）から生成されたUUIDは異なる必要があります（非常に高い確率で）。
* If two UUIDs that were generated from names (using the same canonical format) are equal, then they were generated from the same name in the same namespace (with very high probability).
* 名前から生成された2つのUUID（同じ標準形式を使用）が等しい場合、同じ名前から同じ名前から生成されました（非常に高い確率で）。
A note on names:
名前に関するメモ：
The concept of name (and namespace) should be broadly construed and not limited to textual names. A canonical sequence of octets is one that conforms to the specification for that name form's canonical representation. A name can have many usual forms, only one of which can be canonical. An implementer of new namespaces for UUIDs needs to reference the specification for the canonical form of names in that space or define such a canonical form for the namespace if it does not exist. For example, at the time of writing, Domain Name System (DNS) [RFC9499] has three conveyance formats: common (www.example.com), presentation (www.example.com.), and wire format (3www7example3com0). Looking at [X500] Distinguished Names (DNs), [RFC4122] allowed either text-based or binary DER-based names as inputs. For Uniform Resource Locators (URLs) [RFC1738], one could provide a Fully Qualified Domain Name (FQDN) with or without the protocol identifier www.example.com or https://www.example.com. When it comes to Object Identifiers (OIDs) [X660], one could choose dot notation without the leading dot (2.999), choose to include the leading dot (.2.999), or select one of the many formats from [X680] such as OID Internationalized Resource Identifier (OID-IRI) (/Joint-ISO-ITU-T/Example). While most users may default to the common format for DNS, FQDN format for a URL, text format for X.500, and dot notation without a leading dot for OID, name-based UUID implementations generally SHOULD allow arbitrary input that will compute name-based UUIDs for any of the aforementioned example names and others not defined here. Each name format within a namespace will output different UUIDs. As such, the mechanisms or conventions used for allocating names and ensuring their uniqueness within their namespaces are beyond the scope of this specification.
名前（および名前空間）の概念は、広く解釈され、テキスト名に限定されるべきではありません。オクテットの標準的なシーケンスは、その名前フォームの標準表現の仕様に準拠するものです。名前には多くの通常の形式を持つことができますが、そのうちの1つだけが標準的です。UUIDの新しい名前空間の実装者は、その空間内の標準形式の名前の仕様を参照するか、存在しない場合は名前空間のそのような標準形式を定義する必要があります。たとえば、執筆時点で、ドメイン名システム（DNS）[RFC9499]には、Common（www.example.com）、プレゼンテーション（www.example.com。）、およびワイヤ形式（3www7example3com0）の3つの運搬形式があります。[X500]著名な名前（DNS）を見ると、[RFC4122]は、テキストベースまたはバイナリDERベースの名前のいずれかを入力として許可しました。ユニフォームのリソースロケーター（URL）[RFC1738]の場合、プロトコル識別子www.example.comまたはhttps://www.example.comで、完全に適格なドメイン名（FQDN）を提供できます。オブジェクト識別子（OIDS）[x660]に関しては、先行ドット（2.999）なしでドット表記を選択するか、先行ドット（.2.999）を含めるか、[x680]からの多くの形式の1つを選択することができます。OID Internationalized Resource Identifier（oid-iri）（/goint-iso-itu-t/example）。ほとんどのユーザーは、DNSの共通形式、URLのFQDN形式、X.500のテキスト形式、およびOIDの主要なドットなしでのドット表記にデフォルトである場合がありますが、一般に、名前ベースのUUID実装は、名前が計算される任意の入力を許可するはずです - 前述のサンプル名と、ここでは定義されていない他の名前のいずれかのuUIDに基づいています。名前空間内の各名前形式は、異なるUUIDを出力します。そのため、名前の割り当てと名前空間内での独自性を確保するために使用されるメカニズムまたは慣習は、この仕様の範囲を超えています。
This section details the namespace IDs for some potentially interesting namespaces such as those for DNS [RFC9499], URLs [RFC1738], OIDs [X660], and DNs [X500].
このセクションでは、DNS [RFC9499]、URLS [RFC1738]、OIDS [X660]、およびDNS [X500]のような潜在的に興味深い名前空間の名前空間IDの詳細について説明します。
Further, this section also details allocation, IANA registration, and other details pertinent to Namespace IDs.
さらに、このセクションでは、割り当て、IANA登録、および名前空間IDに関連するその他の詳細についても詳しく説明しています。
+=========+====================================+=========+==========+
|Namespace|Namespace ID Value |Name |Namespace |
| | |Reference|ID |
| | | |Reference |
+=========+====================================+=========+==========+
|DNS |6ba7b810-9dad-11d1-80b4-00c04fd430c8|[RFC9499]|[RFC4122],|
| | | |RFC 9562 |
+---------+------------------------------------+---------+----------+
|URL |6ba7b811-9dad-11d1-80b4-00c04fd430c8|[RFC1738]|[RFC4122],|
| | | |RFC 9562 |
+---------+------------------------------------+---------+----------+
|OID |6ba7b812-9dad-11d1-80b4-00c04fd430c8|[X660] |[RFC4122],|
| | | |RFC 9562 |
+---------+------------------------------------+---------+----------+
|X500 |6ba7b814-9dad-11d1-80b4-00c04fd430c8|[X500] |[RFC4122],|
| | | |RFC 9562 |
+---------+------------------------------------+---------+----------+
Table 3: Namespace IDs
表3：名前空間ID
Items may be added to this registry using the Specification Required policy as per [RFC8126].
[RFC8126]に従って、必要なポリシーを使用して、項目をこのレジストリに追加することができます。
For designated experts, generally speaking, Namespace IDs are allocated as follows:
指定された専門家の場合、一般的に言えば、名前空間IDは次のように割り当てられます。
* The first Namespace ID value, for DNS, was calculated from a time-based UUIDv1 and "6ba7b810-9dad-11d1-80b4-00c04fd430c8", used as a starting point.
* DNSのファーストネームスペースID値は、出発点として使用される時間ベースのUUIDV1および「6BA7B810-9DAD-11D1-80B4-00C04FD430C8」から計算されました。
* Subsequent Namespace ID values increment the least significant, rightmost bit of time_low "6ba7b810" while freezing the rest of the UUID to "9dad-11d1-80b4-00c04fd430c8".
* 後続の名前空間ID値は、UUIDの残りを「9DAD-11D1-80B4-00C04FD430C8」に凍結しながら、最も重要ではない右端のtime_low "6ba7b810"を増やします。
* New Namespace ID values MUST use this same logic and MUST NOT use a previously used Namespace ID value.
* 新しい名前空間ID値と同じロジックを使用する必要があり、以前に使用された名前空間ID値を使用しないでください。
* Thus, "6ba7b815" is the next available time_low for a new Namespace ID value with the full ID being "6ba7b815-9dad-11d1-80b4-00c04fd430c8".
* したがって、「6BA7B815」は、「6BA7B815-9DAD-11D1-80B4-00C04FD430C8」です。
* The upper bound for time_low in this special use, Namespace ID values, is "ffffffff" or "ffffffff-9dad-11d1-80b4-00c04fd430c8", which should be sufficient space for future Namespace ID values.
* この特別な使用法の上限、名前空間ID値は「fffffffff」または「fffffffff-9dad-11d1-80b4-00c04fd430c8」です。
Note that the Namespace ID value "6ba7b813-9dad-11d1-80b4-00c04fd430c8" and its usage are not defined by this document or by [RFC4122]; thus, it SHOULD NOT be used as a Namespace ID value.
名前空間ID値 "6BA7B813-9DAD-11D1-80B4-00C04FD430C8"は、このドキュメントまたは[RFC4122]によって定義されていないことに注意してください。したがって、名前空間ID値として使用しないでください。
New Namespace ID values MUST be documented as per Section 7 if they are to be globally available and fully interoperable. Implementations MAY continue to use vendor-specific, application-specific, and deployment-specific Namespace ID values; but know that interoperability is not guaranteed. These custom Namespace ID values MUST NOT use the logic above; instead, generating a UUIDv4 or UUIDv7 Namespace ID value is RECOMMENDED. If collision probability (Section 6.7) and uniqueness (Section 6.8) of the final name-based UUID are not a problem, an implementation MAY also leverage UUIDv8 instead to create a custom, application-specific Namespace ID value.
新しい名前空間ID値は、グローバルに利用可能で完全に相互運用可能である場合、セクション7に従って文書化する必要があります。実装は、ベンダー固有、アプリケーション固有、および展開固有の名前空間ID値を引き続き使用する場合があります。ただし、相互運用性は保証されていないことを知ってください。これらのカスタムネームスペースID値は、上記のロジックを使用してはなりません。代わりに、UUIDV4またはUUIDV7 NAMESPACE ID値を生成することをお勧めします。最終名ベースのUUIDの衝突確率（セクション6.7）と一意性（セクション6.8）が問題ではない場合、実装はUUIDV8を活用して、カスタムのアプリケーション固有の名前空間ID値を作成することもできます。
Implementations SHOULD provide the ability to input a custom namespace to account for newly registered IANA Namespace ID values outside of those listed in this section or custom, application-specific Namespace ID values.
実装は、このセクションまたはカスタムアプリケーション固有の名前空間ID値にリストされているものの外側に、新しく登録されたIANAネームスペースID値を考慮してカスタムネームスペースを入力する機能を提供する必要があります。
Implementations should weigh the consequences of UUID collisions within their application and when deciding between UUID versions that use entropy (randomness) versus the other components such as those in Sections 6.1 and 6.2. This is especially true for distributed node collision resistance as defined by Section 6.4.
実装は、アプリケーション内のUUID衝突の結果を比較検討し、セクション6.1および6.2のコンポーネントと比較して、エントロピー（ランダム性）を使用するUUIDバージョン（ランダム性）と他のコンポーネントを決定する場合があります。これは、セクション6.4で定義されている分散ノード衝突抵抗に特に当てはまります。
There are two example scenarios below that help illustrate the varying seriousness of a collision within an application.
以下に、アプリケーション内の衝突のさまざまな深刻さを示すのに役立つ2つの例のシナリオがあります。
Low Impact:
影響が少ない：
A UUID collision generated a duplicate log entry, which results in incorrect statistics derived from the data. Implementations that are not negatively affected by collisions may continue with the entropy and uniqueness provided by UUIDs defined in this document.
UUID衝突により、複製されたログエントリが生成され、データから派生した誤った統計が生成されます。衝突によって悪影響を受けない実装は、このドキュメントで定義されているUUIDSが提供するエントロピーと一意性を継続する可能性があります。
High Impact:
影響力の高い：
A duplicate key causes an airplane to receive the wrong course, which puts people's lives at risk. In this scenario, there is no margin for error. Collisions must be avoided: failure is unacceptable. Applications dealing with this type of scenario must employ as much collision resistance as possible within the given application context.
重複するキーは、飛行機が間違ったコースを受け取り、人々の命を危険にさらします。このシナリオでは、エラーのマージンはありません。衝突は避ける必要があります。失敗は受け入れられません。このタイプのシナリオを扱うアプリケーションは、特定のアプリケーションコンテキスト内で可能な限り多くの衝突抵抗を使用する必要があります。
UUIDs created by this specification MAY be used to provide local uniqueness guarantees. For example, ensuring UUIDs created within a local application context are unique within a database MAY be sufficient for some implementations where global uniqueness outside of the application context, in other applications, or around the world is not required.
この仕様によって作成されたUUIDは、ローカルの一意性保証を提供するために使用できます。たとえば、ローカルアプリケーションコンテキスト内で作成されたUUIDがデータベース内で一意であることを確認するだけで、アプリケーションのコンテキスト、他のアプリケーション、または世界中で世界的な一意性が必要ない場合には十分です。
Although true global uniqueness is impossible to guarantee without a shared knowledge scheme, a shared knowledge scheme is not required by a UUID to provide uniqueness for practical implementation purposes. Implementations MAY use a shared knowledge scheme, introduced in Section 6.4, as they see fit to extend the uniqueness guaranteed by this specification.
真のグローバルな一意性は、共有された知識スキームなしでは保証することは不可能ですが、実用的な実装の目的で独自性を提供するためにUUIDが共有する知識スキームは必要ありません。実装は、セクション6.4で導入された共有知識スキームを使用する場合があります。これらは、この仕様によって保証されている一意性を拡張するのに適していると考えているためです。
Implementations SHOULD utilize a cryptographically secure pseudorandom number generator (CSPRNG) to provide values that are both difficult to predict ("unguessable") and have a low likelihood of collision ("unique"). The exception is when a suitable CSPRNG is unavailable in the execution environment. Take care to ensure the CSPRNG state is properly reseeded upon state changes, such as process forks, to ensure proper CSPRNG operation. CSPRNG ensures the best of Sections 6.7 and 8 are present in modern UUIDs.
実装では、暗号化された擬似ランダム数ジェネレーター（CSPRNG）を利用して、予測が困難な値（「Un -Guessable」）と衝突の可能性が低い（「ユニーク」）値を提供する必要があります。例外は、適切なCSPRNGが実行環境で利用できない場合です。適切なCSPRNG操作を確保するために、プロセスフォークなどの状態の変更により、CSPRNG状態が適切に再採用されるように注意してください。CSPRNGは、最新のUUIDに最高のセクション6.7と8が存在することを保証します。
Further advice on generating cryptographic-quality random numbers can be found in [RFC4086], [RFC8937], and [RANDOM].
暗号化品質の乱数の生成に関するさらなるアドバイスは、[RFC4086]、[RFC8937]、および[ランダム]に記載されています。
This section describes how to generate a UUIDv1 or UUIDv6 value if an IEEE 802 address is not available or its use is not desired.
このセクションでは、IEEE 802アドレスが利用できない場合、またはその使用が望ましくない場合、UUIDV1またはUUIDV6値を生成する方法について説明します。
Implementations MAY leverage MAC address randomization techniques [IEEE802.11bh] as an alternative to the pseudorandom logic provided in this section.
実装は、このセクションで提供されている擬似ランダムロジックの代替として、MACアドレスランダム化手法[IEEE802.11BH]を活用する場合があります。
Alternatively, implementations MAY elect to obtain a 48-bit cryptographic-quality random number as per Section 6.9 to use as the Node ID. After generating the 48-bit fully randomized node value, implementations MUST set the least significant bit of the first octet of the Node ID to 1. This bit is the unicast or multicast bit, which will never be set in IEEE 802 addresses obtained from network cards. Hence, there can never be a conflict between UUIDs generated by machines with and without network cards. An example of generating a randomized 48-bit node value and the subsequent bit modification is detailed in Appendix A. For more information about IEEE 802 address and the unicast or multicast or local/global bits, please review [RFC9542].
あるいは、実装は、セクション6.9に従って、ノードIDとして使用するように、48ビットの暗号化品質乱数を取得することを選択する場合があります。48ビットの完全なランダム化ノード値を生成した後、実装はノードIDの最初のオクテットの最小値を1に設定する必要があります。カード。したがって、ネットワークカードの有無にかかわらず、マシンによって生成されたUUID間に競合することはありません。ランダム化された48ビットノード値とその後のビット変更を生成する例については、付録Aに詳細に説明します。IEEE802アドレスとユニキャストまたはマルチキャストまたはローカル/グローバルビットの詳細については、[RFC9542]を確認してください。
For compatibility with earlier specifications, note that this document uses the unicast or multicast bit instead of the arguably more correct local/global bit because MAC addresses with the local/ global bit set or not set are both possible in a network. This is not the case with the unicast or multicast bit. One node cannot have a MAC address that multicasts to multiple nodes.
以前の仕様との互換性については、このドキュメントでは、ローカル/グローバルなビットセットを使用したMACアドレスがネットワークで可能であるため、間違いなく正しいローカル/グローバルビットの代わりにユニキャストまたはマルチキャストビットを使用していることに注意してください。これは、ユニキャストまたはマルチキャストビットには当てはまりません。1つのノードには、複数のノードにマルチキャストするMACアドレスを持つことはできません。
In addition, items such as the computer's name and the name of the operating system, while not strictly speaking random, will help differentiate the results from those obtained by other systems.
さらに、コンピューターの名前やオペレーティングシステムの名前などのアイテムは、厳密に言えばランダムではありませんが、他のシステムで得られた結果との結果を区別するのに役立ちます。
The exact algorithm to generate a Node ID using these data is system specific because both the data available and the functions to obtain them are often very system specific. However, a generic approach is to accumulate as many sources as possible into a buffer, use a message digest (such as SHA-256 or SHA-512 defined by [FIPS180-4]), take an arbitrary 6 bytes from the hash value, and set the multicast bit as described above.
これらのデータを使用してノードIDを生成する正確なアルゴリズムは、利用可能なデータとそれらを取得する関数の両方が非常にシステム固有であるため、システム固有です。ただし、一般的なアプローチは、できるだけ多くのソースをバッファーに蓄積し、メッセージダイジェスト（[FIPS180-4]で定義されたSHA-256やSHA-512など）を使用して、ハッシュ値から任意の6バイトを取得することです。上記のようにマルチキャストビットを設定します。
UUIDv6 and UUIDv7 are designed so that implementations that require sorting (e.g., database indexes) sort as opaque raw bytes without the need for parsing or introspection.
UUIDV6およびUUIDV7は、解析や内省を必要とせずに、ソート（データベースインデックスなど）を不透明なバイトとしてソートする必要がある実装が設計されています。
Time-ordered monotonic UUIDs benefit from greater database-index locality because the new values are near each other in the index. As a result, objects are more easily clustered together for better performance. The real-world differences in this approach of index locality versus random data inserts can be one order of magnitude or more.
インデックス内の新しい値が互いに近くにあるため、タイム順序の単調性UUIDは、より大きなデータベースインデックスローカリティの恩恵を受けます。その結果、パフォーマンスを向上させるために、オブジェクトがより簡単にクラスター化されます。インデックスローカリティとランダムデータインサートのこのアプローチの実際の違いは、1桁以上のことです。
UUID formats created by this specification are intended to be lexicographically sortable while in the textual representation.
この仕様によって作成されたUUID形式は、テキスト表現中に辞書的に分類可能であることを目的としています。
UUIDs created by this specification are crafted with big-endian byte order (network byte order) in mind. If little-endian style is required, UUIDv8 is available for custom UUID formats.
この仕様によって作成されたUUIDは、ビッグエンディアンバイトの順序（ネットワークバイト順序）を念頭に置いて作成されています。リトルエンディアンスタイルが必要な場合、UUIDV8はカスタムUUID形式で利用できます。
As general guidance, avoiding parsing UUID values unnecessarily is recommended; instead, treat UUIDs as opaquely as possible. Although application-specific concerns could, of course, require some degree of introspection (e.g., to examine Sections 4.1 or 4.2 or perhaps the timestamp of a UUID), the advice here is to avoid this or other parsing unless absolutely necessary. Applications typically tend to be simpler, be more interoperable, and perform better when this advice is followed.
一般的なガイダンスとして、UUID値の解析を不必要に回避することをお勧めします。代わりに、UUIDを可能な限り不透明に扱います。もちろん、アプリケーション固有の懸念には、ある程度の内省が必要になる可能性がありますが（たとえば、セクション4.1または4.2、またはおそらくUUIDのタイムスタンプを調べるために）、ここでのアドバイスは、絶対に必要な場合を除き、このまたは他の解析を避けることです。通常、アプリケーションはよりシンプルになり、相互運用可能になり、このアドバイスが守られるとパフォーマンスが向上する傾向があります。
For many applications, such as databases, storing UUIDs as text is unnecessarily verbose, requiring 288 bits to represent 128-bit UUID values. Thus, where feasible, UUIDs SHOULD be stored within database applications as the underlying 128-bit binary value.
データベースなどの多くのアプリケーションでは、テキストとしてUUIDを保存することは不必要に冗長であり、128ビットのUUID値を表すには288ビットが必要です。したがって、実行可能な場合、UUIDは、基礎となる128ビットバイナリ値としてデータベースアプリケーション内に保存する必要があります。
For other systems, UUIDs MAY be stored in binary form or as text, as appropriate. The trade-offs to both approaches are as follows:
他のシステムの場合、UUIDは、必要に応じて、バイナリ形式またはテキストとして保存できます。両方のアプローチのトレードオフは次のとおりです。
* Storing in binary form requires less space and may result in faster data access.
* バイナリ形式で保存するには、より少ないスペースが必要であり、データアクセスが速くなる可能性があります。
* Storing as text requires more space but may require less translation if the resulting text form is to be used after retrieval, which may make it simpler to implement.
* テキストとして保存するには、より多くのスペースが必要ですが、結果のテキストフォームを検索後に使用する場合、より少ない翻訳が必要になる場合があります。これにより、実装が簡単になる場合があります。
DBMS vendors are encouraged to provide functionality to generate and store UUID formats defined by this specification for use as identifiers or left parts of identifiers such as, but not limited to, primary keys, surrogate keys for temporal databases, foreign keys included in polymorphic relationships, and keys for key-value pairs in JSON columns and key-value databases. Applications using a monolithic database may find using database-generated UUIDs (as opposed to client-generated UUIDs) provides the best UUID monotonicity. In addition to UUIDs, additional identifiers MAY be used to ensure integrity and feedback.
DBMSベンダーは、この仕様で定義されたUUID形式を生成および保存する機能を提供することをお勧めします。これには、プライマリキー、時間的データベースの代理キー、ポリ型関係に含まれる外部キーなどの識別子の識別子の左部品の左部品を使用することができます。JSON列およびキー価値データベースのキー価値ペアのキー。モノリシックデータベースを使用したアプリケーションは、データベース生成UUIDを使用して（クライアントで生成されたUUIDとは対照的に）、最高のUUID単調性を提供する場合があります。UUIDに加えて、追加の識別子を使用して、完全性とフィードバックを確保することができます。
Designers of database schema are cautioned against using name-based UUIDs (see Sections 5.3 and 5.5) as primary keys in tables. A common issue observed in database schema design is the assumption that a particular value will never change, which later turns out to be an incorrect assumption. Postal codes, license or other identification numbers, and numerous other such identifiers seem unique and unchanging at a given point time -- only later to have edge cases where they need to change. The subsequent change of the identifier, used as a "name" input for name-based UUIDs, can invalidate a given database structure. In such scenarios, it is observed that using any non-name-based UUID version would have resulted in the field in question being placed somewhere that would have been easier to adapt to such changes (primary key excluded from this statement). The general advice is to avoid name-based UUID natural keys and, instead, to utilize time-based UUID surrogate keys based on the aforementioned problems detailed in this section.
データベーススキーマの設計者は、テーブルの主要なキーとして、名前ベースのUUID（セクション5.3および5.5を参照）を使用することに対して警告されています。データベーススキーマ設計で観察される一般的な問題は、特定の値が決して変わらないという仮定であり、これは後に誤った仮定であることが判明しました。郵便コード、ライセンスまたはその他の識別番号、およびその他の多くのそのような識別子は、特定の時点でユニークで不変のように見えます。名前ベースのUUIDの「名前」入力として使用される識別子のその後の変更は、特定のデータベース構造を無効にする可能性があります。このようなシナリオでは、非名前ベースのUUIDバージョンを使用すると、問題のフィールドがそのような変更に適応しやすい場所に配置されることが観察されています（このステートメントから除外されたプライマリキー）。一般的なアドバイスは、名前ベースのUUIDナチュラルキーを避け、代わりに、このセクションで詳述されている前述の問題に基づいて、時間ベースのUUIDサロゲートキーを利用することです。
All references to [RFC4122] in IANA registries (outside of those created by this document) have been replaced with references to this document, including the IANA URN namespace registration [URNNamespaces] for UUID. References to Section 4.1.2 of [RFC4122] have been updated to refer to Section 4 of this document.
IANAレジストリ（このドキュメントによって作成されたもの以外）における[RFC4122]へのすべての参照は、UUIDのIANA urn Namespace登録[urnmamespaces]を含むこのドキュメントへの参照に置き換えられています。[RFC4122]のセクション4.1.2への言及は、このドキュメントのセクション4を参照するために更新されました。
Finally, IANA should track UUID Subtypes and Special Case "Namespace IDs Values" as specified in Sections 7.1 and 7.2 at the following location: <https://www.iana.org/assignments/uuid>.
最後に、IANAは、次の場所でセクション7.1および7.2で指定されているように、UUIDサブタイプと特別なケース「名前空間IDS値」を追跡する必要があります。
When evaluating requests, the designated expert should consider community feedback, how well-defined the reference specification is, and this specification's requirements. Vendor-specific, application-specific, and deployment-specific values are unable to be registered. Specification documents should be published in a stable, freely available manner (ideally, located with a URL) but need not be standards. The designated expert will either approve or deny the registration request and communicate this decision to IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.
リクエストを評価する際、指定された専門家は、コミュニティのフィードバック、参照仕様がどれだけ適切に定義されているか、およびこの仕様の要件を考慮する必要があります。ベンダー固有、アプリケーション固有、および展開固有の値を登録できません。仕様文書は、安定した自由に利用可能な方法（理想的にはURLとともに配置されている）で公開する必要がありますが、標準である必要はありません。指定された専門家は、登録要求を承認または拒否し、この決定をIANAに伝えます。拒否には説明を含める必要があります。必要に応じて、リクエストを成功させる方法に関する提案が含まれます。
This specification defines the "UUID Subtypes" registry for common widely used UUID standards.
この仕様は、広く使用されているUUID標準の「UUIDサブタイプ」レジストリを定義します。
+======================+====+=========+================+============+
| Name | ID | Subtype | Variant | Reference |
+======================+====+=========+================+============+
| Gregorian Time-based | 1 | version | OSF DCE | [RFC4122], |
| | | | / IETF | RFC 9562 |
+----------------------+----+---------+----------------+------------+
| DCE Security | 2 | version | OSF DCE | [C309], |
| | | | / IETF | [C311] |
+----------------------+----+---------+----------------+------------+
| MD5 Name-based | 3 | version | OSF DCE | [RFC4122], |
| | | | / IETF | RFC 9562 |
+----------------------+----+---------+----------------+------------+
| Random | 4 | version | OSF DCE | [RFC4122], |
| | | | / IETF | RFC 9562 |
+----------------------+----+---------+----------------+------------+
| SHA-1 Name-based | 5 | version | OSF DCE | [RFC4122], |
| | | | / IETF | RFC 9562 |
+----------------------+----+---------+----------------+------------+
| Reordered Gregorian | 6 | version | OSF DCE | RFC 9562 |
| Time-based | | | / IETF | |
+----------------------+----+---------+----------------+------------+
| Unix Time-based | 7 | version | OSF DCE | RFC 9562 |
| | | | / IETF | |
+----------------------+----+---------+----------------+------------+
| Custom | 8 | version | OSF DCE | RFC 9562 |
| | | | / IETF | |
+----------------------+----+---------+----------------+------------+
Table 4: IANA UUID Subtypes
表4：IANA UUIDサブタイプ
This table may be extended by Standards Action as per [RFC8126].
この表は、[RFC8126]に従って標準アクションによって拡張される場合があります。
For designated experts:
指定された専門家向け：
* The minimum and maximum "ID" value for the subtype "version" within the "OSF DCE / IETF" variant is 0 through 15. The versions within Table 1 described as "Reserved for future definition" or "unused" are omitted from this IANA registry until properly defined.
* 適切に定義されるまでレジストリ。
* The "Subtype" column is free-form text. However, at the time of publication, "version" and "family" are the only known UUID subtypes. The "family" subtype is part of the "Apollo NCS" variant space (both are outside the scope of this specification). The Microsoft variant may have subtyping mechanisms defined; however, they are unknown and outside of the scope of this specification. Similarly, the final "Reserved for future definition" variant may introduce new subtyping logic at a future date. Subtype IDs are permitted to overlap. That is, an ID of "1" may exist in multiple variant spaces.
* 「サブタイプ」列は自由形式のテキストです。ただし、出版時には、「バージョン」と「ファミリー」は唯一の既知のUUIDサブタイプです。「ファミリー」サブタイプは、「Apollo NCS」バリアント空間の一部です（どちらもこの仕様の範囲外です）。Microsoftバリアントには、サブタイピングメカニズムが定義されている場合があります。ただし、それらは不明であり、この仕様の範囲外です。同様に、最終的な「将来の定義のために予約されている」バリアントは、将来の新しいサブタイピングロジックを導入する可能性があります。サブタイプIDのオーバーラップが許可されています。つまり、「1」のIDが複数のバリアントスペースに存在する場合があります。
* The "Variant" column is free-form text. However, it is likely that one of four values will be included: the first three are "OSF DCE / IETF", "Apollo NCS", and "Microsoft", and the final variant value belongs to the "Reserved for future definition" variant and may introduce a new name at a future date.
* 「バリアント」列は自由形式のテキストです。ただし、最初の3つの値は「OSF DCE / IETF」、「Apollo NCS」、および「Microsoft」であり、最終的なバリアント値は「将来の定義のために予約された」バリアントに属します。そして、将来の日に新しい名前を紹介する場合があります。
This specification defines the "UUID Namespace IDs" registry for common, widely used Namespace ID values.
この仕様は、一般的で広く使用されている名前空間ID値の「UUID NameSpace IDS」レジストリを定義します。
The full details of this registration, including information for designated experts, can be found in Section 6.6.
指定された専門家の情報を含むこの登録の詳細は、セクション6.6に記載されています。
Implementations SHOULD NOT assume that UUIDs are hard to guess. For example, they MUST NOT be used as security capabilities (identifiers whose mere possession grants access). Discovery of predictability in a random number source will result in a vulnerability.
実装は、UUIDを推測するのが難しいと想定すべきではありません。たとえば、セキュリティ機能（単なる所有権がアクセスを付与する識別子）として使用してはなりません。乱数ソースでの予測可能性の発見は、脆弱性をもたらします。
Implementations MUST NOT assume that it is easy to determine if a UUID has been slightly modified in order to redirect a reference to another object. Humans do not have the ability to easily check the integrity of a UUID by simply glancing at it.
実装は、参照を別のオブジェクトにリダイレクトするために、UUIDがわずかに変更されているかどうかを簡単に判断できると仮定してはなりません。人間には、単にそれをちらっと見て、UUIDの完全性を簡単にチェックする能力がありません。
MAC addresses pose inherent security risks around privacy and SHOULD NOT be used within a UUID. Instead CSPRNG data SHOULD be selected from a source with sufficient entropy to ensure guaranteed uniqueness among UUID generation. See Sections 6.9 and 6.10 for more information.
MACアドレスは、プライバシーに固有のセキュリティリスクをもたらし、UUID内で使用すべきではありません。代わりに、UUID生成の間で保証された一意性を保証するために、十分なエントロピーを備えたソースからCSPRNGデータを選択する必要があります。詳細については、セクション6.9および6.10を参照してください。
Timestamps embedded in the UUID do pose a very small attack surface. The timestamp in conjunction with an embedded counter does signal the order of creation for a given UUID and its corresponding data but does not define anything about the data itself or the application as a whole. If UUIDs are required for use with any security operation within an application context in any shape or form, then UUIDv4 (Section 5.4) SHOULD be utilized.
UUIDに埋め込まれたタイムスタンプは、非常に小さな攻撃面をもたらします。埋め込まれたカウンターと組み合わせたタイムスタンプは、特定のUUIDおよびその対応するデータの作成順序を示していますが、データ自体またはアプリケーション全体については何も定義しません。任意の形状またはフォームのアプリケーションコンテキスト内でセキュリティ操作で使用するためにUUIDが必要な場合は、UUIDV4（セクション5.4）を利用する必要があります。
See [RFC6151] for MD5 security considerations and [RFC6194] for SHA-1 security considerations.
MD5セキュリティに関する考慮事項については[RFC6151]、SHA-1セキュリティに関する考慮事項については[RFC6194]を参照してください。
[C309] X/Open Company Limited, "X/Open DCE: Remote Procedure
Call", ISBN 1-85912-041-5, Open CAE Specification C309,
August 1994,
<https://pubs.opengroup.org/onlinepubs/9696999099/
toc.pdf>.
[C311] The Open Group, "DCE 1.1: Authentication and Security
Services", Open Group CAE Specification C311, August 1997,
<https://pubs.opengroup.org/onlinepubs/9696989899/
toc.pdf>.
[FIPS180-4]
National Institute of Standards and Technology (NIST),
"Secure Hash Standard (SHS)", FIPS PUB 180-4,
DOI 10.6028/NIST.FIPS.180-4, August 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>.
[FIPS202] National Institute of Standards and Technology (NIST),
"SHA-3 Standard: Permutation-Based Hash and Extendable-
Output Functions", FIPS PUB 202,
DOI 10.6028/NIST.FIPS.202, August 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.202.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
<https://www.rfc-editor.org/info/rfc8141>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[X667] ITU-T, "Information technology - Open Systems
Interconnection - Procedures for the operation of OSI
Registration Authorities: Generation and registration of
Universally Unique Identifiers (UUIDs) and their use as
ASN.1 object identifier components", ISO/IEC 9834-8:2004,
ITU-T Recommendation X.667, September 2004.
[COMBGUID] "Creating sequential GUIDs in C# for MSSQL or PostgreSql",
commit 2759820, December 2020,
<https://github.com/richardtallent/RT.Comb>.
[CUID] "Collision-resistant ids optimized for horizontal scaling
and performance.", commit 215b27b, October 2020,
<https://github.com/ericelliott/cuid>.
[Elasticflake]
Pearcy, P., "Sequential UUID / Flake ID generator pulled
out of elasticsearch common", commit dd71c21, January
2015, <https://github.com/ppearcy/elasticflake>.
[Err1957] RFC Errata, Erratum ID 1957, RFC 4122,
<https://www.rfc-editor.org/errata/eid1957>.
[Err3546] RFC Errata, Erratum ID 3546, RFC 4122,
<https://www.rfc-editor.org/errata/eid3546>.
[Err4975] RFC Errata, Erratum ID 4975, RFC 4122,
<https://www.rfc-editor.org/errata/eid4975>.
[Err4976] RFC Errata, Erratum ID 4976, RFC 4122,
<https://www.rfc-editor.org/errata/eid4976>.
[Err5560] RFC Errata, Erratum ID 5560, RFC 4122,
<https://www.rfc-editor.org/errata/eid5560>.
[Flake] Boundary, "Flake: A decentralized, k-ordered id generation
service in Erlang", commit 15c933a, February 2017,
<https://github.com/boundary/flake>.
[FlakeID] "Flake ID Generator", commit fcd6a2f, April 2020,
<https://github.com/T-PWK/flake-idgen>.
[IBM_NCS] IBM, "uuid_gen Command (NCS)", March 2023,
<https://www.ibm.com/docs/en/aix/7.1?topic=u-uuid-gen-
command-ncs>.
[IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic.", IEEE
Std 754-2019, DOI 10.1109/IEEESTD.2019.8766229, July 2019,
<https://standards.ieee.org/ieee/754/6210/>.
[IEEE802.11bh]
IEEE, "IEEE Draft Standard for Information technology--
Telecommunications and information exchange between
systems Local and metropolitan area networks--Specific
requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications Amendment:
Enhancements for Extremely High Throughput (EHT)",
Electronic ISBN 978-1-5044-9520-2, March 2023,
<https://standards.ieee.org/ieee/802.11bh/10525/>.
[KSUID] Segment, "K-Sortable Globally Unique IDs", commit bf376a7,
July 2020, <https://github.com/segmentio/ksuid>.
[LexicalUUID]
Twitter, "Cassie", commit f6da4e0, November 2012,
<https://github.com/twitter-archive/cassie>.
[Microsoft]
Microsoft, "2.3.4.3 GUID - Curly Braced String
Representation", April 2023, <https://learn.microsoft.com/
en-us/openspecs/windows_protocols/ms-
dtyp/222af2d3-5c00-4899-bc87-ed4c6515e80d>.
[MS_COM_GUID]
Chen, R., "Why does COM express GUIDs in a mix of big-
endian and little-endian? Why can't it just pick a side
and stick with it?", September 2022,
<https://devblogs.microsoft.com/
oldnewthing/20220928-00/?p=107221>.
[ObjectID] MongoDB, "ObjectId",
<https://docs.mongodb.com/manual/reference/method/
ObjectId/>.
[orderedUuid]
Cabrera, I. B., "Laravel: The mysterious "Ordered UUID"",
January 2020, <https://itnext.io/laravel-the-mysterious-
ordered-uuid-29e7500b4f8>.
[pushID] Lehenbauer, M., "The 2^120 Ways to Ensure Unique
Identifiers", February 2015,
<https://firebase.googleblog.com/2015/02/the-2120-ways-to-
ensure-unique_68.html>.
[Python] Python, "uuid - UUID objects according to RFC 4122",
<https://docs.python.org/3/library/uuid.html>.
[RANDOM] Occil, P., "Random Number Generator Recommendations for
Applications", June 2023,
<https://peteroupc.github.io/random.html>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992,
<https://www.rfc-editor.org/info/rfc1321>.
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738,
December 1994, <https://www.rfc-editor.org/info/rfc1738>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/info/rfc6151>.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<https://www.rfc-editor.org/info/rfc6194>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N.,
and C. Wood, "Randomness Improvements for Security
Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020,
<https://www.rfc-editor.org/info/rfc8937>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
[RFC9542] Eastlake 3rd, D., Abley, J., and Y. Li, "IANA
Considerations and IETF Protocol and Documentation Usage
for IEEE 802 Parameters", BCP 141, RFC 9542,
DOI 10.17487/RFC9542, April 2024,
<https://www.rfc-editor.org/info/rfc9542>.
[ShardingID]
Instagram Engineering, "Sharding & IDs at Instagram",
December 2012, <https://instagram-engineering.com/
sharding-ids-at-instagram-1cf5a71e5a5c>.
[SID] "sid : generate sortable identifiers", Commit 660e947,
June 2019, <https://github.com/chilts/sid>.
[Snowflake]
Twitter, "Snowflake is a network service for generating
unique ID numbers at high scale with some simple
guarantees.", commit ec40836, May 2014,
<https://github.com/twitter-archive/snowflake>.
[Sonyflake]
Sony, "A distributed unique ID generator inspired by
Twitter's Snowflake", commit 848d664, August 2020,
<https://github.com/sony/sonyflake>.
[ULID] "Universally Unique Lexicographically Sortable
Identifier", Commit d0c7170, May 2019,
<https://github.com/ulid/spec>.
[URNNamespaces]
IANA, "Uniform Resource Names (URN) Namespaces",
<https://www.iana.org/assignments/urn-namespaces/>.
[X500] ITU-T, "Information technology - Open Systems
Interconnection - The Directory: Overview of concepts,
models and services", ISO/IEC 9594-1, ITU-T
Recommendation X.500, October 2019.
[X660] ITU-T, "Information technology - Procedures for the
operation of object identifier registration authorities:
General procedures and top arcs of the international
object identifier tree", ISO/IEC 9834-1, ITU-T
Recommendation X.660, July 2011.
[X680] ITU-T, "Information Technology - Abstract Syntax Notation
One (ASN.1) & ASN.1 encoding rules", ISO/IEC 8824-1:2021,
ITU-T Recommendation X.680, February 2021.
[XID] "Globally Unique ID Generator", commit efa678f, October
2020, <https://github.com/rs/xid>.
Both UUIDv1 and UUIDv6 test vectors utilize the same 60-bit timestamp: 0x1EC9414C232AB00 (138648505420000000) Tuesday, February 22, 2022 2:22:22.000000 PM GMT-05:00.
UUIDV1とUUIDV6テストベクトルの両方が、同じ60ビットタイムスタンプを使用しています：0x1EC9414C232AB00（138648505420000000）2022年2月22日火曜日2：22：22：22.000000 PM GMT-05：00。
Both UUIDv1 and UUIDv6 utilize the same values in clock_seq and node; all of which have been generated with random data. For the randomized node, the least significant bit of the first octet is set to a value of 1 as per Section 6.10. Thus, the starting value 0x9E6BDECED846 was changed to 0x9F6BDECED846.
UUIDV1とUUIDV6の両方が、clock_seqとノードで同じ値を使用します。これらはすべて、ランダムデータで生成されています。ランダム化されたノードの場合、最初のオクテットの最も有意なビットは、セクション6.10に従って1の値に設定されます。したがって、開始値0x9e6bdeced846は0x9f6bdeced846に変更されました。
The pseudocode used for converting from a 64-bit Unix timestamp to a 100 ns Gregorian timestamp value has been left in the document for reference purposes.
64ビットUNIXタイムスタンプから100 nsのグレゴリオタイムスタンプ値への変換に使用される擬似コードは、参照目的でドキュメントに残されています。
# Gregorian-to-Unix Offset:
# The number of 100 ns intervals between the
# UUID Epoch 1582-10-15 00:00:00
# and the Unix Epoch 1970-01-01 00:00:00
# Greg_Unix_offset = 0x01b21dd213814000 or 122192928000000000
# Unix 64-bit Nanosecond Timestamp:
# Unix NS: Tuesday, February 22, 2022 2:22:22 PM GMT-05:00
# Unix_64_bit_ns = 0x16D6320C3D4DCC00 or 1645557742000000000
# Unix Nanosecond precision to Gregorian 100-nanosecond intervals
# Greg_100_ns = (Unix_64_bit_ns/100)+Greg_Unix_offset
# Work:
# Greg_100_ns = (1645557742000000000/100)+122192928000000000
# Unix_64_bit_ns = (138648505420000000-122192928000000000)*100
# Final:
# Greg_100_ns = 0x1EC9414C232AB00 or 138648505420000000
Figure 15: Test Vector Timestamp Pseudocode
図15：ベクタータイムスタンプPSEUDOCODEをテストします
-------------------------------------------
field bits value
-------------------------------------------
time_low 32 0xC232AB00
time_mid 16 0x9414
ver 4 0x1
time_high 12 0x1EC
var 2 0b10
clock_seq 14 0b11, 0x3C8
node 48 0x9F6BDECED846
-------------------------------------------
total 128
-------------------------------------------
final: C232AB00-9414-11EC-B3C8-9F6BDECED846
Figure 16: UUIDv1 Example Test Vector
図16：UUIDV1の例テストベクトル
The MD5 computation from is detailed in Figure 17 using the DNS Namespace ID value and the Name "www.example.com". The field mapping and all values are illustrated in Figure 18. Finally, to further illustrate the bit swapping for version and variant, see Figure 19.
MD5の計算は、DNS名空間ID値と「www.example.com」という名前を使用して、図17で詳しく説明しています。フィールドマッピングとすべての値を図18に示します。最後に、バージョンとバリアントのビットスワッピングをさらに説明するために、図19を参照してください。
Namespace (DNS): 6ba7b810-9dad-11d1-80b4-00c04fd430c8
Name: www.example.com
------------------------------------------------------
MD5: 5df418813aed051548a72f4a814cf09e
Figure 17: UUIDv3 Example MD5
図17：UUIDV3の例MD5
-------------------------------------------
field bits value
-------------------------------------------
md5_high 48 0x5df418813aed
ver 4 0x3
md5_mid 12 0x515
var 2 0b10
md5_low 62 0b00, 0x8a72f4a814cf09e
-------------------------------------------
total 128
-------------------------------------------
final: 5df41881-3aed-3515-88a7-2f4a814cf09e
Figure 18: UUIDv3 Example Test Vector
図18：UUIDV3の例テストベクトル
MD5 hex and dash: 5df41881-3aed-0515-48a7-2f4a814cf09e
Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
Final: 5df41881-3aed-3515-88a7-2f4a814cf09e
Figure 19: UUIDv3 Example Ver/Var Bit Swaps
図19：uuidv3の例ver/varビットスワップ
This UUIDv4 example was created by generating 16 bytes of random data resulting in the hexadecimal value of 919108F752D133205BACF847DB4148A8. This is then used to fill out the fields as shown in Figure 20.
このUUIDV4の例は、16バイトのランダムデータを生成することにより作成され、919108F752D133205BACF847DB4148A8の16進価値が生成されました。これは、図20に示すようにフィールドに記入するために使用されます。
Finally, to further illustrate the bit swapping for version and variant, see Figure 21.
最後に、バージョンとバリアントのビットスワッピングをさらに説明するために、図21を参照してください。
-------------------------------------------
field bits value
-------------------------------------------
random_a 48 0x919108f752d1
ver 4 0x4
random_b 12 0x320
var 2 0b10
random_c 62 0b01, 0xbacf847db4148a8
-------------------------------------------
total 128
-------------------------------------------
final: 919108f7-52d1-4320-9bac-f847db4148a8
Figure 20: UUIDv4 Example Test Vector
図20：UUIDV4の例テストベクトル
Random hex: 919108f752d133205bacf847db4148a8
Random hex and dash: 919108f7-52d1-3320-5bac-f847db4148a8
Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
Final: 919108f7-52d1-4320-9bac-f847db4148a8
Figure 21: UUIDv4 Example Ver/Var Bit Swaps
図21：uuidv4の例ver/varビットスワップ
The SHA-1 computation form is detailed in Figure 22, using the DNS Namespace ID value and the Name "www.example.com". The field mapping and all values are illustrated in Figure 23. Finally, to further illustrate the bit swapping for version and variant and the unused/ discarded part of the SHA-1 value, see Figure 24.
SHA-1計算フォームは、DNS名空間ID値と「www.example.com」という名前を使用して、図22に詳述されています。フィールドマッピングとすべての値を図23に示します。最後に、バージョンとバリアントのビットスワッピング、およびSHA-1値の未使用/廃棄部分をさらに説明します。図24を参照してください。
Namespace (DNS): 6ba7b810-9dad-11d1-80b4-00c04fd430c8
Name: www.example.com
----------------------------------------------------------
SHA-1: 2ed6657de927468b55e12665a8aea6a22dee3e35
Figure 22: UUIDv5 Example SHA-1
図22：UUIDV5の例SHA-1
-------------------------------------------
field bits value
-------------------------------------------
sha1_high 48 0x2ed6657de927
ver 4 0x5
sha1_mid 12 0x68b
var 2 0b10
sha1_low 62 0b01, 0x5e12665a8aea6a2
-------------------------------------------
total 128
-------------------------------------------
final: 2ed6657d-e927-568b-95e1-2665a8aea6a2
Figure 23: UUIDv5 Example Test Vector
図23：UUIDV5の例テストベクトル
SHA-1 hex and dash: 2ed6657d-e927-468b-55e1-2665a8aea6a2-2dee3e35
Ver and Var Overwrite: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
Final: 2ed6657d-e927-568b-95e1-2665a8aea6a2
Discarded: -2dee3e35
Figure 24: UUIDv5 Example Ver/Var Bit Swaps and Discarded SHA-1 Segment
図24：UUIDV5の例Ver/varビットスワップと廃棄されたSHA-1セグメント
-------------------------------------------
field bits value
-------------------------------------------
time_high 32 0x1EC9414C
time_mid 16 0x232A
ver 4 0x6
time_high 12 0xB00
var 2 0b10
clock_seq 14 0b11, 0x3C8
node 48 0x9F6BDECED846
-------------------------------------------
total 128
-------------------------------------------
final: 1EC9414C-232A-6B00-B3C8-9F6BDECED846
Figure 25: UUIDv6 Example Test Vector
図25：UUIDV6の例テストベクトル
This example UUIDv7 test vector utilizes a well-known Unix Epoch timestamp with millisecond precision to fill the first 48 bits.
この例UUIDV7テストベクターは、最初の48ビットを埋めるために、ミリ秒の精度でよく知られているUNIXエポックタイムスタンプを使用しています。
rand_a and rand_b are filled with random data.
RAND_AとRAND_Bはランダムデータで満たされています。
The timestamp is Tuesday, February 22, 2022 2:22:22.00 PM GMT-05:00, represented as 0x017F22E279B0 or 1645557742000.
タイムスタンプは、2022年2月22日火曜日2：22：22.00 PM GMT-05：00で、0x017F22E279B0または1645557742000と表されています。
-------------------------------------------
field bits value
-------------------------------------------
unix_ts_ms 48 0x017F22E279B0
ver 4 0x7
rand_a 12 0xCC3
var 2 0b10
rand_b 62 0b01, 0x8C4DC0C0C07398F
-------------------------------------------
total 128
-------------------------------------------
final: 017F22E2-79B0-7CC3-98C4-DC0C0C07398F
Figure 26: UUIDv7 Example Test Vector
図26：UUIDV7の例テストベクトル
The following sections contain illustrative examples that serve to show how one may use UUIDv8 (Section 5.8) for custom and/or experimental application-based logic. The examples below have not been through the same rigorous testing, prototyping, and feedback loop that other algorithms in this document have undergone. The authors encourage implementers to create their own UUIDv8 algorithm rather than use the items defined in this section.
次のセクションには、カスタムおよび/または実験的なアプリケーションベースのロジックにUUIDV8（セクション5.8）をどのように使用するかを示すのに役立つ実例例が含まれています。以下の例は、このドキュメントの他のアルゴリズムが受けたのと同じ厳密なテスト、プロトタイピング、およびフィードバックループを使用していません。著者は、このセクションで定義されているアイテムを使用するのではなく、実装者が独自のUUIDV8アルゴリズムを作成することを奨励しています。
This example UUIDv8 test vector utilizes a well-known 64-bit Unix Epoch timestamp with 10 ns precision, truncated to the least significant, rightmost bits to fill the first 60 bits of custom_a and custom_b, while setting the version bits between these two segments to the version value of 8.
この例UUIDV8テストベクターは、10 ns精度のある有名な64ビットUNIXエポックタイムスタンプを使用し、最も重要でない右端のビットに切り捨てて、最初の60ビットのCustom_aとcustom_bを埋めながら、これら2つのセグメント間のバージョンビットを設定します。8のバージョン値。
The variant bits are set; and the final segment, custom_c, is filled with random data.
バリアントビットが設定されています。また、最終セグメントであるCustom_Cは、ランダムデータで満たされています。
Timestamp is Tuesday, February 22, 2022 2:22:22.000000 PM GMT-05:00, represented as 0x2489E9AD2EE2E00 or 164555774200000000 (10 ns-steps).
タイムスタンプは2022年2月22日火曜日2：22：22.000000 PM GMT-05：00で、0x2489E9AD2EE2E00または164555774200000000（10 NS-steps）と表されます。
-------------------------------------------
field bits value
-------------------------------------------
custom_a 48 0x2489E9AD2EE2
ver 4 0x8
custom_b 12 0xE00
var 2 0b10
custom_c 62 0b00, 0xEC932D5F69181C0
-------------------------------------------
total 128
-------------------------------------------
final: 2489E9AD-2EE2-8E00-8EC9-32D5F69181C0
Figure 27: UUIDv8 Example Time-Based Illustrative Example
図27：UUIDV8の例時間ベースの例示的な例
As per Section 5.5, name-based UUIDs that want to use modern hashing algorithms MUST be created within the UUIDv8 space. These MAY leverage newer hashing algorithms such as SHA-256 or SHA-512 (as defined by [FIPS180-4]), SHA-3 or SHAKE (as defined by [FIPS202]), or even algorithms that have not been defined yet.
セクション5.5によると、最新のハッシュアルゴリズムを使用したい名前ベースのUUIDは、UUIDV8スペース内で作成する必要があります。これらは、SHA-256やSHA-512（[FIPS180-4]で定義）、SHA-3またはSHAKE（[FIPS202]で定義）、またはまだ定義されていないアルゴリズムなどの新しいハッシュアルゴリズムを活用する場合があります。
A SHA-256 version of the SHA-1 computation in Appendix A.4 is detailed in Figure 28 as an illustrative example detailing how this can be achieved. The creation of the name-based UUIDv8 value in this section follows the same logic defined in Section 5.5 with the difference being SHA-256 in place of SHA-1.
付録A.4のSHA-1計算のSHA-256バージョンは、これをどのように達成できるかを詳述する例として図28に詳述されています。このセクションでの名前ベースのUUIDV8値の作成は、セクション5.5で定義された同じロジックに従って、違いはSHA-1の代わりにSHA-256です。
The field mapping and all values are illustrated in Figure 29. Finally, to further illustrate the bit swapping for version and variant and the unused/discarded part of the SHA-256 value, see Figure 30. An important note for secure hashing algorithms that produce outputs of an arbitrary size, such as those found in SHAKE, is that the output hash MUST be 128 bits or larger.
フィールドマッピングとすべての値を図29に示します。最後に、バージョンとバリアントのビットスワッピング、およびSHA-256値の未使用/廃棄部分をさらに説明するために、図30を参照してください。Shakeで見つかったような任意のサイズの出力は、出力ハッシュが128ビット以上でなければならないことです。
Namespace (DNS): 6ba7b810-9dad-11d1-80b4-00c04fd430c8
Name: www.example.com
----------------------------------------------------------------
SHA-256:
5c146b143c524afd938a375d0df1fbf6fe12a66b645f72f6158759387e51f3c8
Figure 28: UUIDv8 Example SHA256
図28：UUIDV8の例SHA256
-------------------------------------------
field bits value
-------------------------------------------
custom_a 48 0x5c146b143c52
ver 4 0x8
custom_b 12 0xafd
var 2 0b10
custom_c 62 0b00, 0x38a375d0df1fbf6
-------------------------------------------
total 128
-------------------------------------------
final: 5c146b14-3c52-8afd-938a-375d0df1fbf6
Figure 29: UUIDv8 Example Name-Based SHA-256 Illustrative Example
図29：UUIDV8の例NameベースのSHA-256例
A: 5c146b14-3c52-4afd-938a-375d0df1fbf6-fe12a66b645f72f6158759387e51f3c8
B: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
C: 5c146b14-3c52-8afd-938a-375d0df1fbf6
D: -fe12a66b645f72f6158759387e51f3c8
Figure 30: UUIDv8 Example Ver/Var Bit Swaps and Discarded SHA-256 Segment
図30：UUIDV8の例ver/varビットスワップと廃棄されたSHA-256セグメント
Examining Figure 30:
図30を調べる：
* Line A details the full SHA-256 as a hexadecimal value with the dashes inserted.
* 挿入されたダッシュを使用して、16進数として完全なSHA-256を詳細に説明します。
* Line B details the version and variant hexadecimal positions, which must be overwritten.
* 行Bは、バージョンとバリアントの16進の位置を詳しく説明します。これは上書きする必要があります。
* Line C details the final value after the ver and var have been overwritten.
* LINE Cは、VERとVARが上書きされた後の最終値を詳しく説明します。
* Line D details the discarded leftover values from the original SHA-256 computation.
* 行Dは、元のSHA-256計算から廃棄された残りの値を詳しく説明しています。
The authors gratefully acknowledge the contributions of Rich Salz, Michael Mealling, Ben Campbell, Ben Ramsey, Fabio Lima, Gonzalo Salgueiro, Martin Thomson, Murray S. Kucherawy, Rick van Rein, Rob Wilton, Sean Leonard, Theodore Y. Ts'o, Robert Kieffer, Sergey Prokhorenko, and LiosK.
著者は、リッチゾルツ、マイケル・ミーリング、ベン・キャンベル、ベン・ラムジー、ファビオ・リマ、ゴンザロ・サルゲイロ、マーティン・トムソン、マレー・S・クチェラウィー、リック・ヴァン・レイン、ロブ・ウィルトン、ショーン・レナード、セオドア・Y・Ts'o、ロバート・キーファー、セルゲイ・プロホレンコ、リオスク。
As well as all of those in the IETF community and on GitHub to who contributed to the discussions that resulted in this document.
IETFコミュニティのすべてのものと、GitHubで、このドキュメントをもたらしたディスカッションに貢献したのは誰ですか。
This document draws heavily on the OSF DCE specification (Appendix A of [C309]) for UUIDs. Ted Ts'o provided helpful comments.
このドキュメントは、UUIDSのOSF DCE仕様（[C309]の付録A）に大きく描かれています。Ted Ts'oは有益なコメントを提供しました。
We are also grateful to the careful reading and bit-twiddling of Ralf S. Engelschall, John Larmouth, and Paul Thorpe. Professor Larmouth was also invaluable in achieving coordination with ISO/IEC.
また、Ralf S. Engelschall、John Larmouth、およびPaul Thorpeの慎重な読書とビットの装いにも感謝しています。ラーマス教授は、ISO/IECとの調整を達成することにも非常に貴重でした。
Kyzer R. Davis
Cisco Systems
Email: kydavis@cisco.com
Brad G. Peabody
Uncloud
Email: brad@peabody.io
Paul J. Leach
University of Washington
Email: pjl7@uw.edu