UUID
RFC 9562 Universally Unique IDentifiers (UUIDs) ISO/IEC 9834-8:2014
128bit 固有IDっぽいもの
バージョンが判別可能
GUIDはMicrosoft の UUIDの別名? リトルエンディアン? UUIDv2の場合
time-low 32bit
time-mid 16bit
time-high-and-version 16bit
version 4bit
time_hi 12bit
clock-seq-and-reserved 8bit
variant 2bit
clock_seq 14bit
clock-seq-low 8bit
node 48bit
code:ABNF
UUID = 4hexOctet "-"
2hexOctet "-"
2hexOctet "-"
2hexOctet "-"
6hexOctet
hexOctet = HEXDIG HEXDIG
DIGIT = %x30-39
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
バイト順はネットワークバイトオーダー(ビッグエンディアン)、ただしGUIDはLittle-Endianを使う。
XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
f81d4fae-7dec-11d0-a765-00a0c91e6bf6
文字列型UUID フォーマットの例
11111000000111010100111110101110011111011110110000010001110100001010011101100101000000001010000011001001000111100110101111110110
バイナリUUIDの例
329800735698586629295641978511506172918
整数UUIDの例
urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
9オクテット目? variant 上位2ビット (RFC, ISOの場合)
table:バリアント
0 Network Computing System 後方互換性
10 RFC, ISO用 UUID
110 Microsoft GUID
111 予約
7オクテット目? version
UUIDv1 時間ベース Macアドレス 仮想化などで一意性が保証されなくなった
UUIDv2 DCEセキュリティ
UUIDv3 名前ベース MD5ハッシュ
UUIDv4 ランダム
UUIDv5 SHA-1ハッシュ DNS, URL, OID, X.500
UUIDv6 v1と互換で時間順ソート可能
UUIDv7 時間順ソート可能
UUIDv8 実験
v4かv7が推奨 v5をSHA-2にする場合は実験のv8を使用する
UUIDv4
UUIDv5
Namespcae ID
というものがあるよ
example.com などの名前のハッシュ(主にsha-1?)と組み合わせることで共通のUUIDが得られるっぽい
DNS
URL
OID
X500
用の4種類のUUIDがあるらしい
亜種 RFC 9562
暗号化により実現
JavaScript
Java
RFC 9562
概要
この仕様は、UUID（Universally Unique IDentifiers）（GUID（Globally Unique IDentifiers）とも呼ばれる）と、UUID用のUniform Resource Name名前空間を定義します。UUIDは128ビット長で、空間と時間にわたる一意性を保証することを目的としています。UUIDは、当初はApollo Network Computing System（NCS）で使用され、その後Open Software Foundation（OSF）のDistributed Computing Environment（DCE）で使用され、さらにMicrosoft Windowsプラットフォームでも使用されました。
この仕様は、OSF（現在は「The Open Group」として知られています）の厚意により、OSF DCE仕様から派生したものです。OSF DCE仕様の以前のバージョンの情報は、この文書に組み込まれています。この文書は、RFC 4122を廃止するものです。
1. はじめに
本仕様は、ユニバーサルユニーク識別子（UUID）（グローバルユニーク識別子（GUID）とも呼ばれる）のためのUniform Resource Name（統一資源名）名前空間を定義します。UUIDは128ビット長で、中央登録プロセスを必要としません。
UUIDはコンピューティングにおいて非常に広く使用されています。Microsoft Windowsなどの多くのオペレーティングシステムやMozilla Webブラウザなどのアプリケーションの中核的な識別子インフラストラクチャを構成していますが、多くの場合、非標準的な方法で公開される可能性があります。本仕様は、この慣行を可能な限りオープンに、かつインターネット全体に利益をもたらす方法で標準化することを目指しています。ここでの情報は、URN RFC 8141と組み合わせてUUIDを使用するサービスなどを実装したいと考えている人々のための簡潔なガイドとなることを目的としています。RFC 4122から派生したITU-T勧告とISO/IEC標準X.667があります。両方の仕様は整合が取れており、完全に技術的に互換性があります。このドキュメントのいかなる内容も、UUIDを定義したDCE標準規格に優先するものと解釈されるべきではありません。 2. 目的
UUIDを使用する主な理由の一つは、UUIDを管理するために中央機関を必要としないことです（ただし、2つの形式ではオプションのIEEE 802ノードIDを活用できますが、他の形式では活用できません）。その結果、オンデマンド生成を完全に自動化し、様々な用途に使用できます。ここで説明するUUID生成アルゴリズムは、必要に応じてマシンあたり1秒あたり1000万回以上の非常に高い割り当て速度をサポートしているため、トランザクションIDとして使用することも可能です。
UUIDは固定サイズ（128ビット）であり、他の代替手段と比較して十分に小さいサイズです。そのため、あらゆる種類のソート、順序付け、ハッシュ化、データベースへの保存、単純な割り当て、そしてプログラミング全般の容易さに適しています。UUIDは一意かつ永続的であるため、URNとして最適です。登録プロセスなしで新しい UUID を生成できる独自の機能により、UUID は最も作成コストが低い URN の 1 つになります。
2.1. 更新の動機
UUIDが最初に作成されて以来、多くの変化がありました。現代のアプリケーションでは、複雑な計算システムにおける様々な項目の主要な識別子としてUUIDを作成し、利用する必要があります。これには、データベースキー、ファイル名、マシン名またはシステム名、イベント駆動型トランザクションの識別子などが含まれますが、これらに限定されません。
UUIDが普及している分野の一つがデータベースキーです。これは、現代のアプリケーションの分散化が進んでいることに起因しています。このような場合、データベースでよく使用される「自動インクリメント」方式はうまく機能しません。ネットワーク全体で連続した数値識別子を調整するために必要な労力は、容易に負担になる可能性があります。 UUIDは分散システムにおいて、調整を必要とせずに一意で比較的短い値を作成できるため、優れた代替手段となります。しかし、RFC4122で最初に定義されたUUIDバージョン1～5には、以下のような望ましい特性が欠けています。 1. UUIDv4（セクション5.4で説明）のように、時間順序付けされていないUUIDバージョンは、データベースインデックスの局所性が低くなります。これは、連続して作成される新しい値がインデックス内で互いに近接していないことを意味します。そのため、挿入はランダムな場所に実行する必要があります。結果として、この目的で使用される一般的な構造（Bツリーとその派生）に劇的なパフォーマンス悪影響を及ぼす可能性があります。
2. UUIDv1 タイムスタンプで使用される 100 ナノ秒のグレゴリオ紀元 (セクション 5.1 で説明) は一般的ではなく、IEEE754 で説明されているような標準の数値形式を使用して正確に表現することは困難です。 3. 単純なバイトごとの比較を実行できるのではなく、時間シーケンスで順序付けるにはイントロスペクション/解析が必要です。
4. プライバシーとネットワーク セキュリティの問題は、UUIDv1 のノード フィールドにメディア アクセス制御 (MAC) アドレスを使用することで発生します。露出した MAC アドレスは、ネットワーク インターフェイスを特定するための攻撃対象領域として使用され、そのようなマシンに関するさまざまな情報 (少なくとも製造元、場合によってはその他の詳細) が明らかになる可能性があります。さらに、仮想マシンとコンテナーの出現により、MAC アドレスの一意性は保証されなくなりました。
5. RFC4122 で指定されている実装の詳細の多くには、すべてのアプリケーションに指定することは不可能であり、相互運用可能な実装を作成するために必要でもないトレードオフが含まれています。 6. RFC4122では、UUIDを生成するための要件と、単にUUIDを保存するための要件は区別されていませんでしたが、実際には両者はしばしば異なります。 前述の問題のため、多くの広く分散されたデータベースアプリケーションや大手アプリケーションベンダーは、データベースキーとして使用するための、より優れた時間ベースのソート可能な一意の識別子を作成するという課題の解決に取り組んできました。これにより、過去10年以上にわたり、同じ問題をわずかに異なる方法で解決する多数の実装が生まれました。
本仕様の準備段階では、以下の16の異なる実装について、IDの全長、ビットレイアウト、語彙のフォーマットとエンコード、タイムスタンプの種類、タイムスタンプのフォーマット、タイムスタンプの精度、ノードのフォーマットとコンポーネント、衝突処理、およびマルチタイムスタンプのティック生成シーケンスの傾向を分析しました。
これらの実装と上記の問題を調査した結果、この文書が作成されました。この文書では、これらの問題に対処するために新しいUUIDが採用されています。
さらに、RFC4122自体も、以下のような多くのトピックに対処するために全面的な見直しが必要でした。（ただし、これらに限定されるわけではありません。） 2. 他のUUIDバージョンをUUIDv1のビットレイアウトから分離することで、「time_hi_and_version」などのフィールドを時間ベースではないUUID内で参照する必要がないようにし、UUIDv3、UUIDv4、UUIDv5にもUUIDv1と同様の定義セクションを提供します。
3. 既存およびプロトタイプ実装で観察された多くの現実世界のシナリオとコーナーケースに関する実装のベストプラクティスを提供します。
4. MACアドレス、ハッシュアルゴリズム、安全なランダム性、その他のトピックに関連する、現代のセキュリティのベストプラクティスと考慮事項に対処します。
5. 実装に、実装固有または実験的なUUID設計のための標準ベースのオプションを提供します。
6. 実際のUUID設計を示すより多くのテストベクトルを提供します。仕様に従って作成された UUID。