ユニバーサルユニーク識別子

ユニバーサルユニーク識別子

頭字語	UUID
組織	オープンソフトウェア財団（OSF）、ISO / IEC、インターネット技術タスクフォース（IETF）
桁数	32
例	f81d4fae-7dec-11d0-a765-00a0c91e6bf6
Webサイト	RFC  9562 (廃止されたRFC 4122 )

ユニバーサルユニーク識別子（UUID）は、コンピュータシステム内のオブジェクトを一意に識別するために設計された128ビットの数値です。UUIDは、ランダムに生成されたUUIDが実質的に一意となるように十分な大きさに設計されていますが、他の方法で一意性を実現することも可能です。グローバルユニーク識別子（GUID ）という用語も、主にMicrosoft設計のシステムで使用されています。^{[ 1 ] [ 2 ]} UUIDを表す標準的な方法は、32桁の16進数で、ハイフンで5つのグループに分割されます。

ユニバーサルユニーク識別子（UUID）は通常、乱数生成器を用いて生成されますが、一部のシステムでは生成時刻やその他の情報も識別子に組み込んでいます。UUIDを生成するための標準規格は複数存在し、それぞれの要件は異なります。^{[ 1 ]} UUID値が重複する確率はゼロではありませんが、一般的に無視できる程度と考えられています。^{[ 3 ] [ 4 ]} 10UUID 値は³⁸種類 ( 340 冪乗以上) あり、さまざまなコンピュータ システムで、生成した UUID が世界中のすべてのコンピュータ システムで一意であると想定できます。つまり、同じ識別子の再利用を避けるためにシステム間で調整する必要はありません。

UUIDは、現代のコンピュータシステムやインターネットにおいて、ファイルやデータベースエントリなどのデータオブジェクトのラベル付けに広く使用されています。UUIDは普遍的に一意であるのに十分な大きさであるにもかかわらず、オーバーヘッドが低く、生成と比較も迅速に行えます。

歴史

1980年代、アポロコンピュータはネットワークコンピューティングシステム（NCS）でUUIDを初めて使用しました。その後、オープンソフトウェア財団（OSF）は分散コンピューティング環境（DCE）でUUIDを使用しました。DCE UUIDの設計は、NCS UUIDを部分的にベースとしており、^{[ 5 ]} NCS UUIDの設計は、アポロコンピュータが設計したオペレーティングシステムであるDomain/OSで定義され、広く使用されている（ 64ビット）ユニーク識別子に触発されました。^{[ 6 ]} 1990年代初頭、Microsoft WindowsプラットフォームはDCEの設計を「グローバルユニーク識別子」（GUID）として採用しました。

RFC 4122はUUIDのURN名前空間を登録し、以前の仕様を同じ技術的内容で要約しました。^{[ 2 ]} 2005年7月にRFC 4122がIETF標準案として公開されたとき、ITUも以前の標準とRFC 4122の初期バージョンに基づいてUUIDを標準化していました。2024年5月7日にはRFC 9562 ^{[ 1 ]}が公開され、3つの新しい「バージョン」が導入され、いくつかの曖昧さが明確になりました。

標準

UUID技術は様々な団体によって標準化されています。その定義は、分散コンピューティング環境（DCE）の一部として、オープンソフトウェア財団（OSF）によって標準化されています。^{[ 7 ] [ 8 ]}その定義は、ISO / IEC 11578:1996「情報技術- 開放型システム間相互接続 -遠隔手続き呼び出し（RPC）」の一部として文書化されており、最近ではITU-T勧告X.667 | ISO / IEC 9834-8:2014にも記載されています。^{[ 9 ]}インターネット技術タスクフォース（IETF）は、標準化過程のRFC 4122 ^{[ 2 ]を公開しました。これは技術的にはITU-T勧告X.667 | ISO/IEC 9834-8と同等です。その後、RFC 4122はRFC 9562 [ 1 ]}に置き換えられ、3つの新しいUUIDバージョン（6、7、8）が追加

形式

UUIDは128ビットの数値で、1～3ビットはUUIDのバリアントを示すために使用されます。最も一般的な2つのバリアントは、さらに4ビットをUUIDのバージョンとして定義し、現在8つのバージョンが指定されています。残りのビットの生成は、選択されたバリアント/バージョンによって制御されます。

変種

バリアントフィールドはUUIDの形式を示します。以下のバリアントが定義されています。

• Apollo NCS バリアント 0 (1 ビット パターン 0xxx ₂で示されます) は、1988 年頃に開発され現在は廃止されている Apollo Network Computing System 1.5 UUID 形式との下位互換性を保つためのものです。現在の UUID のバリアント フィールドは NCS UUID のアドレス ファミリ オクテットと重複しており、現在も使用されている NCS UUID ではバリアント フィールドの最初のビットが 0 になります。
• OSF DCE バリアント 1 (10 _{2 ) UUID は、元の}インターネット ドラフトの作成者にちなんで、RFC 4122/DCE 1.1 UUID、または「Leach–Salz」UUID と呼ばれます。
• Microsoft COM/DCOM バリアント 2 (110 ₂ ) は、RFC では「Microsoft Corporation の下位互換性のために予約済み」とされており、Microsoft Windowsプラットフォームの初期の GUID に使用されていました。このバリアントとバリアント 1 の主な違いは、追加のバリアントビットを除けば、UUID 内のバイト順序です。現在の Microsoft ツールでは、このバリアントは生成されません。また、バージョン 6、7、8 を追加した RFC 9562 では、バリアント 1 以外のバリアントは範囲外であるとされていますが、実際には相互運用性の問題が発生する可能性は低いと考えられます。そのため、従来の Microsoft バリアント 2 に適用されるバージョンは多少不明確ですが、バージョン 1、3、4 のみが含まれると考えられます。
• バリアント3（111 ₂）は予約されています。

バージョン

OSF DCEおよびMicrosoft COM/DCOMバリアント（1および2）にはバージョンがあり、UUIDの7バイト目の上位4ビットの値で示されます。UUIDのテキスト表現では、これは2番目のハイフンの後の文字です。

バージョン 1 および 6 (日付と時刻、MAC アドレス)

バージョン1は、「ノード」（つまりUUIDを生成するコンピュータ）の48ビットMACアドレスと60ビットのタイムスタンプを連結します。64ビットMACアドレスを持つシステムでは、下位48ビットが使用されます。48ビットの乱数も使用される場合があります。タイムスタンプは、グレゴリオ暦が初めて採用された日である協定世界時（UTC） 1582年10月15日午前0時からの100ナノ秒間隔の数値です。RFC 4122では、時刻値は西暦3400年頃にロールオーバーすると規定されています^{[ 2 ]。 使用されるアルゴリズムに応じて3倍}になるため、60ビットのタイムスタンプは符号付き量です。ただし、libuuidライブラリなどの一部のソフトウェアは、タイムスタンプを符号なしとして扱い、ロールオーバー時刻を西暦5623年とします^{[ 10 ] 。}

13ビットまたは14ビットの「一意化」クロックシーケンスは、プロセッサクロックの進みが十分でない場合や、ノードごとに複数のプロセッサとUUIDジェネレータがある場合に対応するために、タイムスタンプを拡張します。UUIDがシステムクロックの進みよりも速く生成される場合、タイムスタンプフィールドの下位ビットは、UUIDが生成されるたびにインクリメントすることで生成され、高解像度のタイムスタンプをシミュレートできます。各バージョン1 UUIDは空間（ノード）と時間（間隔とクロックシーケンス）の単一の点に対応するため、適切に生成された2つのバージョン1 UUIDが意図せず同じになる可能性は実質的にゼロです。時間とクロックシーケンスの合計は74ビットなので、2 ⁷⁴ (1.8 × 10^{1ノードIDあたり22}（18セクストルオン）のバージョン1 UUIDを生成でき、最大平均速度は1ノードIDあたり1秒あたり1630億です。 ^{[ 2 ]}

したがって、バージョン 1 UUID のレイアウトは次のようになります。

UUID バージョン 1 レコードレイアウト

名前	長さ（バイト）	長さ（16進数）	コンテンツ
時間_low	4	8	時刻の下位32ビットを表す整数
時間_mid	2	4	時間の中央16ビットを表す整数
時間_hi_and_version	2	4	最上位ビットに4ビットの「バージョン」、続いて時刻の上位12ビット
clock_seq_hi_and_res クロック_seq_low	2	4	最上位ビットに1～3ビットの「バリアント」があり、その後に13～15ビットのクロックシーケンスが続く
ノード	6	12	48ビットのノードID

バージョン6は、タイムスタンプビットの順序を除いてバージョン1と同じです。バージョン6では、タイムスタンプビットは最上位から最下位の順に並べられます。これにより、システムはバージョン6のUUIDを語彙的に並べ替えるだけで、作成順に並べることができます。

バージョン 2 (日時と MAC アドレス、DCE セキュリティ バージョン)

RFC 9562 ^{[ 1 ]}はバージョン2を「DCEセキュリティ」UUID用に予約していますが、詳細は規定されていません。このため、多くのUUID実装ではバージョン2が省略されています。しかし、バージョン2 UUIDの仕様はDCE 1.1認証およびセキュリティサービス仕様で規定されています。^{[ 8 ]}

バージョン2のUUIDはバージョン1と似ていますが、クロックシーケンスの下位8ビットが「ローカルドメイン」番号に置き換えられ、タイムスタンプの下位32ビットが指定されたローカルドメイン内で意味のある整数識別子に置き換えられます。POSIXシステムでは、ローカルドメイン番号0と1はそれぞれユーザーID（UID）とグループID（GID）に使用され、その他のローカルドメイン番号はサイト定義です。^{[ 8 ]} POSIX以外のシステムでは、すべてのローカルドメイン番号はサイト定義です。

UUIDに40ビットのドメイン/識別子を含める機能には、トレードオフが伴います。まず、40ビットでは、ノードIDごとに約1兆個のドメイン/識別子値を使用できます。一方、クロック値がバージョン1の60ビットから28ビットに切り捨てられるため、バージョン2のUUIDのクロックは、バージョン1では100ナノ秒ごとに1回刻まれていたのに対し、429.49秒（7分強）ごとに1回しか刻まれません。また、クロックシーケンスはバージョン1の14ビットから6ビットに減少するため、7分間のクロックティックごとに、ノード/ドメイン/識別子ごとに64個の一意のUUIDしか生成できません。これは、バージョン1では16,384個のクロックシーケンス値が生成されていたのに対し、バージョン2では64個しか生成できないことを意味します。^{[ 11 ]}

バージョン 3 および 5 (名前空間名ベース)

バージョン3とバージョン5のUUIDは、名前空間識別子と名前をハッシュ化することによって生成されます。バージョン3ではハッシュアルゴリズムとしてMD5が使用され、バージョン5ではSHA-1が使用されます。^{[ 1 ]}

名前空間識別子自体はUUIDです。仕様では、URL、完全修飾ドメイン名、オブジェクト識別子、およびX.500識別名の名前空間を表す定数UUIDが提供されていますが、任意のUUIDを名前空間指定子として使用できます。

与えられた名前空間と名前に対応するバージョン3のUUIDを決定するために、名前空間のUUIDはバイト列に変換され、入力された名前と連結され、MD5でハッシュ化されて128ビットになります。その後、6ビットまたは7ビットが固定値に置き換えられます。固定値は4ビットバージョン（例：バージョン3の場合は0011 ₂）、2ビットまたは3ビットのUUID「バリアント」（例：RFC 9562 ^{[ 1 ]} _{UUIDを示す10 2}、または従来のMicrosoft GUIDを示す110 ₂）です。このように6ビットまたは7ビットは事前に決定されているため、UUIDの一意性に寄与するのは121ビットまたは122ビットのみです。

バージョン5のUUIDも同様ですが、MD5ではなくSHA-1が使用されます。SHA-1は160ビットのダイジェストを生成するため、バージョンビットとバリアントビットが置き換えられる前に、ダイジェストは128ビットに切り捨てられます。

バージョン3とバージョン5のUUIDは、同じ名前空間と名前が同じUUIDにマッピングされるという特性があります。しかし、名前空間と名前のいずれか一方が指定されていても、総当たり攻撃による場合を除き、UUIDからその名前空間と名前を特定することはできません。RFC 4122では、バージョン3（MD5）よりもバージョン5（SHA-1）を推奨しており、どちらのバージョンのUUIDもセキュリティ認証情報として使用しないよう警告しています。^{[ 2 ]}

バージョン4（ランダム）

バージョン4のUUIDはランダムに生成されます。他のUUIDと同様に、バージョン4を示すために4ビットが使用され、バリアントを示すために2ビットまたは3ビットが使用されます（バリアント1の場合は10 ₂、バリアント2の場合は110 ₂）。したがって、バリアント1（つまりほとんどのUUID）の場合、ランダムなバージョン4のUUIDは、6ビットのバリアントビットとバージョンビットで構成され、ランダムに生成される部分は122ビットとなり、合計2 ¹²²、つまり5.3 × 10になります。^{バージョン4のバリアント1のUUIDは36個}（5.3 冪乗）あります。バージョン4のバリアント2のUUID（レガシーGUID）は、利用可能なランダムビットが1つ少なく、バリアントに3ビット消費されるため、その半分の個数になります。

バージョン 7 (Unix エポック タイムスタンプとランダム)

バージョン7のUUIDは、大規模データベースや分散システムにおいて、作成時刻順に単調に昇順で並べられたキーとして利用されることを意図しており、局所性とパフォーマンスの向上に貢献します。他のUUIDバージョンとは異なり、MACアドレスを組み込まず、MACアドレスに関連するプライバシーの問題を回避できます。UUIDは以下のように構成されます。

• 48 ビット ビッグ エンディアンの符号なし Unix エポック タイムスタンプ (ミリ秒単位)。
• 4 ビット バージョンは に設定されます7。
• 精度や単調性を向上させるための 12 ビットの構造、または一意性を提供するための疑似ランダム データ。
• 2 ビットのバリアント、 に設定されます10。
• 62 ビットの構造により、精度や単調性が向上し、疑似ランダム データにより一意性が提供されます。

オプションの単調性構造には、精度の向上したサブミリ秒のタイムスタンプ小数やシードされたカウンターなどの項目が含まれます。

バージョン8（カスタム）

カスタムUUIDでは、バージョンフィールドは8ビット、バリアントビットは10合計6ビットです。残りの122ビットは指定されません。したがって、一意性は実装依存となり、RFC 9562に従って、そのように想定してはいけません。

MACアドレスの使用

他の UUID バージョンとは対照的に、バージョン 1、2、および 6 は、ネットワーク カードの MAC アドレスに基づいています。その一意性は、中央登録機関によって発行される識別子、つまりMAC アドレスの組織固有識別子(OUI) 部分に部分的に依存しており、これはIEEEによってネットワーク機器の製造業者に発行されます。^{[ 12 ]}ネットワーク カードの MAC アドレスに基づく UUID の一意性は、ネットワーク カードの製造業者がカードに一意の MAC アドレスを適切に割り当てることにも依存しており、他の製造プロセスと同様にエラーが発生する可能性があります。MAC アドレスはネットワーク カードに由来しない場合があります。たとえば、仮想マシンはハイパーバイザーで構成可能な範囲から MAC アドレスを受け取ります。^{[ 13 ]}また、一部のオペレーティング システム (特にOpenWRT )では、エンド ユーザーが MAC アドレスをカスタマイズできます。^{[ 14 ]} そのため、UUID で使用される MAC アドレスは、意図的であろうと偶発的であろうと、グローバルに一意ではない可能性があります。

ノードIDにノードのネットワークカードのMACアドレスを使用すると、バージョン1、2、6のUUIDを作成したコンピュータまで追跡できる場合が多くあります。文書は、ワープロソフトによって埋め込まれたUUIDを通じて、作成または編集されたコンピュータまで追跡できる場合があります。このプライバシーホールは、Melissaウイルスの作成者を特定する際に利用されました。^{[ 15 ]}

RFC 9562 ^{[ 1 ]}では、バージョン1、2、または6のUUIDのMACアドレスを、ノードがMACアドレスを持たないか、それを公開したくないという理由で、ランダムな48ビットのノードIDに置き換えることが許可されています。その場合、RFCではノードIDの最初のオクテットの最下位ビットを1に設定する必要があります。^{[ 2 ]}これはMACアドレスのマルチキャストビットに対応しており、これを設定することで、ネットワークカードのMACアドレスに基づいてランダムに生成されたUUID（通常はユニキャストMACアドレスを持つ）からノードIDを区別することができます。^{[ 2 ]}

特別な値

「nil」UUIDは00000000-0000-0000-0000-000000000000（つまり、すべてのビットがクリアされている）です。^{[ 1 ]}これはバリアント0のUUIDです。「max」UUID（「omni」UUIDとも呼ばれる）はFFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF（つまり、すべてのビットがセットされている）です。^{[ 1 ]} これはバリアント3の領域にあります。

エンコーディング

バイナリ表現

当初、アポロコンピュータは、バージョン1に非常によく似た次のワイヤ形式でUUIDを設計しました^{[ 5 ] [ 16 ]}

オリジナルのApollo Computer NCS UUIDフォーマット

名前	オフセット	長さ	説明
時間_高	0x00	4オクテット / 32ビット	最初の6オクテットは、1980年1月1日0時00分（ UTC）から経過した4マイクロ秒（μs）単位の時間数です。 1980年開始から^248 ×4μs後の時刻は、2015年9月5日5時58分26.84262秒（UTC）でした。したがって、このオリジナル形式でUUIDを生成できた最後の時刻は2015年でした。[ 17 ]
時間_low	0x04	2オクテット / 16ビット
予約済み	0x06	2オクテット / 16ビット	これらのオクテットは将来の使用のために予約されています。
家族	0x08	1オクテット / 8ビット	このオクテットはアドレス ファミリです。
ノード	0x09	7オクテット / 56ビット	これらのオクテットは、指定されたアドレス ファミリによって許可される形式のホスト ID です。

その後、UUIDは従来のファミリーフィールドと新しいバリアントフィールドを組み合わせることで拡張されました。ファミリーフィールドはこれまで0から13までの値しか使用していなかったため、最上位ビットが0に設定されたUUIDはレガシーUUIDであると判断されました。これにより、ファミリーグループの表は次のようになります。

ファミリー/バリアントフィールド

MSB 0	MSB 1	MSB 2	レガシーファミリーフィールド値の範囲	16進数で	説明
0	×	×	0～127（0～13のみ使用）	0x00～0x7f	レガシーApollo NCS UUID
1	0	×	128～191	0x80～0xbf	OSF DCE UUID
1	1	0	192～223	0xc0～0xdf	マイクロソフト COM / DCOM UUID
1	1	1	224～255	0xe0～0xff	将来の定義のために予約済み

従来のApollo NCS UUIDは、前の表で説明した形式です。OSF DCE UUIDのバリアントはRFC 9562 ^{[ 1 ]}で説明されています。Microsoft COM / DCOM UUIDのバリアントは、Microsoftのドキュメントに記載されています。

エンディアン

UUIDをバイナリ形式で保存する場合、ビッグエンディアンで順次エンコードされます。例えば00112233-4455-6677-8899-aabbccddeeff、バリアント1のUUIDである は、バイト としてエンコードされます00 11 22 3344 5566 7788 99aa bb cc dd ee ff。^{[ 18 ] [ 19 ]}

例外として、Microsoftのバリアント2 UUID（「GUID」）があります。歴史的にCOM/OLEライブラリで使用されてきたこの形式はリトルエンディアン形式ですが、UUIDの最初の3つの要素がリトルエンディアン、最後の2つの要素がビッグエンディアンであるため、混合エンディアンとして表示されます。MicrosoftのGUID構造は、最後の8バイトを8バイト配列として定義し、昇順にシリアル化することで、バイト表現が混合エンディアンのように見えます。^{[ 20 ]}例えば、バリアント2 UUIDはバイトとしてエンコードされます。^{[ 21 ] [ 22 ]}00112233-4455-6677-8899-ccddeeffaabb33 22 11 0055 4477 6688 99cc dd ee ff aa bb

テキスト表現

ほとんどの場合、UUIDはハイフンで区切られた16進数値で表されます。最もよく使用されるのは8-4-4-4-12形式、つまり4つのハイフンを含む32桁の16進数値の文字列ですxxxxxxxx-xxxx-vxxx-wxxxx-xxxxxxxxxxxx。ハイフンはバージョン1のフィールドを区切りますが、すべてのバージョンで同じ形式が一般的に使用されます。16進数値の各桁は4ビットを表し、vはバージョンバイトを表し、上位1～3ビットはwバリアントを表します。Windowsレジストリ形式も同じですが、UUIDは中{}括弧で囲まれます。

ハイフンを含む形式は、新しいバリアントシステムで導入されました。それ以前のApollo形式では、若干異なる形式が使用されていました34dc23469000.0d.00.00.7c.5f.00.00.00。最初の部分は時間（time_highとtime_lowの組み合わせ）です。予約フィールドはスキップされます。ファミリーフィールドは最初のドットの直後に来るため、この場合はDDS（データ配信サービス）0dを表します（10進数で13）。残りの部分はそれぞれドットで区切られ、ノードバイトです。

小文字の16進数字が推奨されます。ITU-T勧告X.667では、生成時には小文字が必須ですが、入力時には大文字も受け付けられることが規定されています。UUIDは128ビットの数値であるため、10進数や2進数など、他の形式も可能であり、時折見かけることがあります。

RFC 9562 ^{[ 1 ]}は「uuid」名前空間を登録します。これにより、UUIDからURN（例えば ）を作成できますurn:uuid:550e8400-e29b-41d4-a716-446655440000。URNの作成には、通常の8-4-4-4-12形式が使用されます。また、UUIDからOID URN（例えば ）を作成することもできますurn:oid:2.25.113059749145936325402354257176981405696。OID URNの場合は、符号なし10進形式が使用されます。「oid」URNよりも「uuid」URNの使用が推奨されます。

衝突

衝突は、同じUUIDが複数回生成され、異なる参照先に割り当てられた場合発生します。固有のMACアドレスやタイムスタンプを使用する標準バージョン1、2、6、および一部のバージョン7のUUIDの場合、衝突は製造上の問題、クロックのずれ、ソフトウェアのバグなどのエラーによってのみ発生する可能性があります。

対照的に、乱数生成やハッシュ化などのプロセスを用いて生成されたUUIDバージョンでは、偶然の衝突により、エラーなく衝突が発生する可能性があります。この確率は通常非常に小さいため無視でき、誕生日問題の解析に基づいて正確に計算できます。^{[ 23 ]}例えば、少なくとも1つの衝突の確率が50%になるように生成する必要があるランダムバージョン4のUUIDの数は2.71京であり、次のように計算されます。^{[ 24 ]}

${\displaystyle n\approx {\frac {1}{2}}+{\sqrt {{\frac {1}{4}}+\ln(2)\times 2^{123}}}\approx 2.71\times 10^{18}.}$

この数は、毎秒10億個のUUIDを約86年間生成し続けることに相当します。1UUIDあたり16バイトのこの数のUUIDを含むファイルは、約43.4 エクサバイト（37.7  EiB）になります。少なくとも1つの衝突が見つかる確率がpとなるために必要なバージョン4 UUIDの最小数は、以下の式で近似されます。

${\displaystyle {\sqrt {2^{123}\times \ln {\frac {1}{1-p}}}}.}}$

したがって、適切に生成されたバージョン 4 UUID 103 兆個内で重複が見つかる確率は 10 億分の 1 です。

用途

ファイルシステム

重要な用途としては、ファイルシステムのユーザー空間ツール^{[ 25 ]}が挙げられます。これらのほとんどは、Theodore Ts'o によるオリジナルの実装から派生したものです。^{[ 10 ]} 「パーティションラベル」と「パーティション UUID」はどちらもスーパーブロックに格納されます。これらはどちらもパーティションではなくファイルシステムの一部です。例えば、ext4とBtrfs にはUUID が含まれますが、NTFSやFAT32には含まれません（ただし、これらのファイルシステムでは通常、より短い UID (一意の識別子) が使用されます）。スーパーブロックはファイルシステムの一部であるため、パーティション内に完全に含まれます。そのため、 sda1 と sdb1 は同じラベルと UUID を持つことになります。

以下はUUID（およびFAT32 EFIシステムパーティションのUID ）の使用例です/etc/fstab（要約）。

UUID=b18e3b6c-ccb7-4308-b527-35e5e6ee2145 / btrfs デフォルト、compress=zstd 0 0 UUID=103C-86D6 /efi vfat utf8 0 2 UUID=64f3cb6a-e70e-45e5-8b90-d86cddbab7bb スワ​​ップ スワップデフォルト、pri=2 0 0 UUID=eda746c6-1f1b-4cf1-9225-d8b0b46511cc /mnt/Stuff btrfs デフォルト、圧縮=zstd 0 0 

パーティションテーブル

GUIDパーティション テーブル(GPT) は、GUID を使用してパーティション タイプにラベルを付ける一例です。

リモート処理

Microsoft のコンポーネント オブジェクト モデル(COM) で使用される GUID にはいくつかの種類があります。

• IID – インターフェース識別子（システムに登録されているものはWindowsレジストリの[HKEY_CLASSES_ROOT\Interface]^{[ 26 ]}に保存されます）
• CLSID– クラス識別子（ に格納されます[HKEY_CLASSES_ROOT\CLSID]）。実際には、インターフェースをリモート処理するにはプロキシ/スタブオブジェクトが必要になる場合があり、一部のツールセットではインターフェースのIIDと同じCLSIDを使用してこれらのオブジェクトを作成するため、 IID空間とは完全に分離されていません。
• LIBID – 型ライブラリ識別子; ( [HKEY_CLASSES_ROOT\TypeLib]^{[ 27 ]}に保存)
• CATID – カテゴリ識別子（クラスに存在することで、そのクラスが[HKEY_CLASSES_ROOT\Component Categories]^{[ 28 ]}にリストされている特定のクラスカテゴリに属していることが識別される）

データベース

UUIDは、データベーステーブル内の一意のキーとして一般的に使用されます。Microsoft SQL Serverバージョン4 Transact-SQLのNEWID関数は、標準のランダムバージョン4 UUIDを返します。一方、NEWSEQUENTIALID関数は、次回のシステム再起動まで順番に昇順になるようにコミットされるUUIDに似た128ビットの識別子を返します。^{[ 29 ]} Oracle DatabaseのSYS_GUID関数は、名前にもかかわらず標準のGUIDを返しません。代わりに、ホスト識別子とプロセスまたはスレッド識別子に基づいて、GUIDに似た16バイト128ビットのRAW値を返します。^{[ 30 ]} PostgreSQLにはUUIDデータ型が含まれており^{[ 31 ]}、モジュールの関数を使用してほとんどのバージョンのUUIDを生成できます。^{[ 32 ] [ 33 ]} MySQLには、標準バージョン1 UUIDを生成するUUID関数が用意されています。^{[ 34 ]}

結合された時間-GUID

標準UUIDバージョン3、4、5のランダム性、および標準バージョン1および2におけるフィールドの順序付けは、UUIDを主キーとして使用した場合に、データベースの局所性またはパフォーマンスに問題を引き起こす可能性があります。例えば、2002年にJimmy Nilssonは、キーとして使用されていたバージョン4のUUIDにシステム時刻に基づく非ランダムなサフィックスを追加するように変更したところ、Microsoft SQL Serverのパフォーマンスが大幅に向上したと報告しました。このいわゆる「COMB」（combined time-GUID）アプローチは、Nilssonも認めているように、UUIDが重複する可能性を大幅に高めましたが、Nilssonが求めていたのはアプリケーション内での一意性だけでした。^{[ 35 ]}タイムスタンプが先頭になるようにバージョン1および2のUUIDを並べ替えてエンコードすることで、挿入時のパフォーマンス低下を回避できます。^{[ 36 ]}

COMBのようなUUIDペイロードの配置は、最終的にRFC 9562 ^{[ 1 ]}でバージョン6と7として標準化されました。

その他の例

UEFIとACPIはGUIDを使用する例です。^{[ 37 ]}

参照

• 誕生日攻撃
• オブジェクト識別子（OID）
• ユニフォームリソース識別子（URI）
• スノーフレークID

参考文献

1. Davis, K.; Peabody, B.; Leach, P. (2024).ユニバーサルユニークID（UUID） .インターネットエンジニアリングタスクフォース. doi : 10.17487/RFC9562 . RFC 9562. 2024年5月9日閲覧。
2. Leach, P.; Mealling, M.; Salz, R. (2005).ユニバーサルユニークID（UUID）URN名前空間.インターネット技術タスクフォース. doi : 10.17487/RFC4122 . RFC 4122. 2017年1月17日閲覧。
3. 「Universally Unique Identifiers (UUID)」 H2 . 2021年3月21日閲覧。
4. ITU-T勧告X.667：ユニバーサルユニーク識別子（UUID）の生成と登録、およびASN.1オブジェクト識別子コンポーネントとしての使用。標準。2012年10月。
5. Zahn, Lisa; Dineen, Terence; Leach, Paul; Martin, Elizabeth; Mishkin, Nathaniel; Pato, Joseph; Wyant, Geoffrey (1990). Network Computing Architecture . Prentice Hall . p. 10. ISBN 978-0-13-611674-5。
6. Leach, PJ; Levine, PH; Hamilton, JA; Stumpf, BL (1982年8月18～20日). 「分散ファイルシステムにおける内部名としてのUID」.第1回ACM SIGACT-SIGOPSシンポジウム「分散コンピューティングの原理」議事録 - PODC '82 . pp.  34– 41. doi : 10.1145/800220.806679 . ISBN 0-89791-081-8。
7. 「DCE 1.1: リモートプロシージャコール」 The Open Group. 1997年。
8. 「DCE 1.1: 認証およびセキュリティサービス」 The Open Group. 1997年。
9. 「ITU-T研究グループ17 - オブジェクト識別子（OID）および登録機関に関する勧告」 ITU.int 2023年3月28日閲覧。
10. "ext2/e2fsprogs.git - Ext2/3/4ファイルシステムのユーザー空間ユーティリティ" . Kernel.org . 2017年1月9日閲覧。
11. Kuchling, AM 「What's New in Python 2.5」 . Python.org . 2016年1月23日閲覧。
12. 「登録機関」 IEEE規格協会2011年4月4日時点のオリジナルよりアーカイブ。
13. 「仮想マシンのMACアドレス」。スーパーユーザー。
14. 「MACアドレスの設定」OpenWRT . 2021年9月15日.
15. ライター、ルーク（1999年4月2日）「メリッサの分身を追跡」 ZDNet 2017年1月16日閲覧。
16. "uuid.c" . opensource.apple.com . 2021年2月24日時点のオリジナルよりアーカイブ。2017年6月8日閲覧。
17. しかし、Domain/OSのバグにより、タイムスペースの前半部分しか使用できず、1997年11月2日に問題が発生しました。Jim Rees (1996). 「Apollo Date Bug」 . 2024年4月29日時点のオリジナルよりアーカイブ。 2024年4月29日閲覧。
18. Steele, Nick. 「UUIDの分解」
19. 「UUID バージョンの説明 | UUIDTools.com 」。www.uuidtools.com 。
20. Chen, Raymond (2022年9月28日). 「COMはなぜビッグエンディアンとリトルエンディアンの混合でGUIDを表現するのか？ なぜどちらか一方を選んでそれに固執できないのか？」 . The Old New Thing . 2022年10月31日閲覧。
21. Leach, Paul. 「UUIDとGUID」。
22. 「Guid.ToByteArray メソッド (システム)」。learn.microsoft.com。
23. イエス、パウロ;バケロ、カルロス。アルマイダ、パウロ。「モバイル環境での ID 生成」(PDF)。Repositorium.Sdum.Uminho.pt。
24. Mathis, Frank H. (1991年6月). 「一般化された誕生日問題」. SIAM Review . 33 (2): 265– 270. CiteSeerX 10.1.1.5.5851 . doi : 10.1137/1033051 . ISSN 0036-1445 . JSTOR 2031144. OCLC 37699182 .    
25. "gen_uuid.c" . opensource.apple.com . 2017年7月6日時点のオリジナルよりアーカイブ。2017年9月17日閲覧。
26. 「インターフェイスポインタとインターフェイス」 . Windows デベロッパーセンター - デスクトップアプリテクノロジ. Microsoft . 2015年12月15日閲覧。実行時にインターフェイスを参照するには、グローバル一意インターフェイス識別子 ( IID ) を使用します。このIID は、COM がサポートするグローバル一意識別子 ( GUID )の特定のインスタンスであり、クライアントはオブジェクトに対し、インターフェイスのセマンティクスをサポートしているかどうかを正確に問い合わせることができます。不要なオーバーヘッドや、同じ名前の同じインターフェイスが複数バージョン存在する場合にシステムで発生する可能性のある混乱を避けることができます。
27. 「タイプライブラリの登録」 . Microsoft Developer Network . Microsoft . 2015年12月15日閲覧。
28. 「コンポーネント機能による分類」 . Windows Dev Center - デスクトップアプリテクノロジ. Microsoft . 2015年12月15日閲覧。CATIDと判読可能な名前の一覧は、レジストリ内の既知の場所に保存されます。
29. "NEWSEQUENTIALID (Transact-SQL)" . Microsoft Developer Network . Microsoft . 2015年8月8日. 2017年1月14日閲覧。
30. 「 Oracle Database SQLリファレンス」。Oracle 。
31. 「セクション8.12 UUID型」 . PostgreSQL 9.4.10ドキュメント. PostgreSQLグローバル開発グループ. 2020年2月13日.
32. "uuid-ossp" . PostgreSQL: ドキュメント: 9.6 . PostgreSQL Global Development Group. 2021年8月12日.
33. "pgcrypto" . PostgreSQL: ドキュメント: 9.6 . PostgreSQL Global Development Group. 2021年8月12日.
34. 「セクション13.20 その他の関数」 . MySQL 5.7リファレンスマニュアル. Oracle Corporation .
35. Nilsson, Jimmy (2002年3月8日). 「GUIDを主キーとして使用する場合のコスト」 . InformIT . 2012年6月20日閲覧。
36. 「MySQLへのUUID値の保存」 Percona、2014年12月19日。2020年11月29日時点のオリジナルよりアーカイブ。 2021年2月10日閲覧。
37. https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/21_ACPI_Data_Tables_and_Table_Def_Language/ACPI_Data_Tables.html

外部リンク

• ITU-T X.667勧告（無料アクセス）
• ISO/IEC 9834-8:2014（有料）
• テクニカルノート TN2166 - GPTの秘密- Apple Developer
• UUID ドキュメント- Apache Commons Id
• CLSID キー- Microsoft Docs
• ユニバーサルユニーク識別子- The Open Group Library
• UUIDデコーダーツール
• UUIDの簡単な歴史
• UUIDの生成方法を理解する