Loading article…
ユニバーサル一意識別子（UUID）は、コンピュータシステム内の情報を識別するために使用される128ビットの数値です。グローバル一意識別子（GUID ）という用語も、通常、 Microsoftが作成したソフトウェアで使用されます。[ 1 ]
規格に従って生成されたUUIDは、実際上、一意です。他のほとんどの番号付け方式とは異なり、その一意性は中央登録機関や生成者間の調整に依存しません。
UUID が重複する確率はゼロではありませんが、無視できるほどゼロに近い値です。[ 2 ]したがって、誰でも多数の UUID を作成し、それを識別子として使用できます。その際、他者が作成した、または作成する予定の UUID と重複しないというほぼ確実な保証が得られます。一意性を確保するために必要な調整は、UUID 標準に準拠することだけです。そのため、独立した当事者によって UUID がラベル付けされた情報は、重複する確率が無視できるほど低い状態で、同じデータベースやチャネルに共存できます。
UUIDの採用は広く普及しており、多くのコンピューティングプラットフォームがUUIDの生成とテキスト表現の解析をサポートしている。
アポロコンピュータは、1987年に発売されたネットワークコンピューティングシステム（NCS）でUUIDを使用しました。これは、以前のアポロオペレーティングシステムであるDomain/OSの64ビット一意識別子に触発された設計です。[ 3 ]マイクロソフトのWindowsプラットフォームは、1990年代初頭にNCS（および後にDCE）の設計を「グローバル一意識別子」（GUID）として採用しました。
やや後になって、Open Software Foundation (OSF)は、NCS UUID を部分的にベースとした設計で、分散コンピューティング環境(DCE) で UUID を使用しました。これは、1996 年の DCE 1.1 RPC 仕様と、1997 年に公開された DCE 1.1 認証およびセキュリティ サービス仕様に文書化されています。 [ 4 ] [ 5 ] [ 6 ] ISO/IEC は、1996 年にISO / IEC 11578:1996「情報技術- オープン システム相互接続 -リモート プロシージャ コール」 で DCE の設計を文書化しました。[ 7 ]
2005 年 7 月、インターネット技術タスク フォース(IETF) は、標準化トラック RFC 4122 を公開しました。[ 1 ]また、この文書ではUUID 用のURN名前空間も登録されています。一方、 ITU は、以前の標準と RFC 4122 の初期バージョンに基づいて、ITU-T 勧告 X.667 ISO/IEC 9834-8 で UUID を標準化しました。これは技術的には RFC 4122 と同等です。[ 8 ]
現在の IETF 仕様は、2024 年 5 月に公開された提案標準である RFC 9562 [ 9 ]です。これは、DCE バリアントの 3 つの新しい UUID バージョン (6 ～ 8) を定義しています。現在使用されている UUID は DCE/IETF 設計であり、「レガシー」の Apollo NCS UUID および Microsoft GUID との下位互換性が確保されています。
RFC 4122 の著者は Paul Leach、Michael Mealling、Rich Salzであり、最初の 1997 Internet Draft [ 10 ]の著者は Leach と Salz でした。Leach は Domain/OS のアーキテクトであり、Apollo で NCS の設計者として働き続け、その後、Microsoft の Distinguished Architect として OLE/COM/DCOM の設計に貢献し、UUID の概念をそのプロジェクトに持ち込みました。[ 11 ] Leach は RFC 9562 の著者の 1 人でもありました。Salz は Open Software Foundation の DCE チームのメンバーでした。[ 12 ] Apollo は 1989 年に、OSF の創設メンバーであるHewlett-Packardと合併しました。HP の従業員となった元 NCS チームのメンバーが OSF DCE に UUID を持ち込みました。ミーリングは著名なIETFメンバーであり、インターネット技術運営グループに席を持ち、URNに関するIETFの作業に深く関わっていた。[ 13 ] RFC 4122はこれらすべての要素を統合した。
UUIDは128ビットの数値です。ビットの意味はバリアントによって決まり、3種類が定義されています。最も一般的なのはバリアント1で、その他のバリアントは以前のフォーマットとの下位互換性のため、または将来の定義のために用意されています。バリアント1と2には「バージョン」があり、UUIDの解釈をさらに細かく定義します。
バリアントフィールドは、 9バイト目の最上位ビットの可変個数で構成されます。UUIDのテキスト表現では、これは3番目のハイフンの後の16進数の一部です。これはUUIDのフォーマットを示します。以下のバリアントが定義されています。
OSF DCE および Microsoft COM/DCOM のバリアント (それぞれ 1 および 2) にはバージョンがあり、これは UUID の 7 番目のバイトの上位 4 ビットの値で示されます。UUID のテキスト表現では、これは 2 番目のハイフンの後の 16 進数です。バリアント 0 Apollo NCS UUID にはバージョンがなく、バージョンではなく「アドレス ファミリー」によってサブタイプされます。バージョン 6、7、および 8 を定義した RFC 9562 [ 9 ]では、OSF DCE バリアント 1 以外のバリアントは RFC の「範囲外」であると述べ、バリアント 2 の新しいバージョンを定義するのは Microsoft に任せました。ただし、RFC 4122 [ 1 ]で標準化されたバージョン 1 ～ 5 は、バイト順序を除いて、Microsoft バリアントでも同じです。
バージョン1では、「ノード」（つまり、UUIDを生成するコンピュータ）の48ビットMACアドレスと60ビットのタイムスタンプを連結します。64ビットEUI-64「MACアドレス」を持つシステムでは、下位48ビットが使用されます。48ビットの乱数を使用することもできます。
タイムスタンプは、グレゴリオ暦が初めて採用された1582年10月15日協定世界時（UTC）の真夜中からの100ナノ秒間隔の数です。RFC 4122では、使用されるアルゴリズムに応じて、時刻の値が西暦3409年にロールオーバーすると規定されています[ 1 ]。これは、60ビットのタイムスタンプが符号付き量であることを意味します。しかし、libuuidライブラリなどの一部のソフトウェアは、タイムスタンプを符号なしとして扱い、ロールオーバー時間を西暦5236年としています[ 14 ]。
13ビットまたは14ビットの「一意化」クロックシーケンスは、プロセッサクロックの進みが十分速くない場合や、ノードごとに複数のプロセッサとUUIDジェネレータが存在する場合に対応するために、タイムスタンプを拡張します。UUIDがシステムクロックの進みよりも速く生成される場合、タイムスタンプとクロックシーケンスの下位ビットをインクリメントして、より高い精度をシミュレートし、一意性を確保できます。各バージョン1 UUIDは空間（ノード）と時間（間隔とクロックシーケンス）の単一の点に対応するため、適切に生成された2つのバージョン1 UUIDが意図せず同じになる可能性は事実上ゼロです。時間とクロックシーケンスの合計は74ビットなので、2 74 (1.8 × 10ノード ID ごとに22（または 18 垓）バージョン 1 UUID を生成でき、ノード ID ごとに最大平均レートで毎秒 1630 億を生成できます。 [ 1 ]
バージョン1のUUIDのレイアウトは次のとおりです。
バージョン6は、タイムスタンプビットの順序を除いてバージョン1と同じです。バージョン6では、タイムスタンプビットは最上位ビットから最下位ビットの順に並んでいます。これにより、システムはバージョン6のUUIDを字句順にソートするだけで、作成順に並べ替えることができます。ソートを可能にするためにタイムスタンプの元のNCSハイローバイト順序を復元することで、バージョン6はバージョン1よりも「レガシー」バリアント0のNCS UUIDにさらに近くなっています。
RFC 4122 および 9562 [ 9 ]はバージョン 2 を「DCE セキュリティ」 UUID 用に予約していますが、詳細は提供していません。RFC 9562 は、これらを「範囲外」と宣言しています。多くの UUID 実装およびライブラリはバージョン 2 を省略しています。ただし、バージョン 2 UUID の仕様は、DCE 1.1 認証およびセキュリティ サービス仕様によって提供されています。[ 6 ]
バージョン 2 の UUID はバージョン 1 と似ていますが、クロック シーケンスの最下位 8 ビットが「ローカル ドメイン」番号に置き換えられ、60 ビットのグレゴリオ タイムスタンプの最下位 32 ビットが指定されたローカル ドメイン内で意味のある整数識別子に置き換えられます。POSIX システムでは、ローカル ドメイン番号 0 と 1 はそれぞれユーザー ID ( UID ) とグループ ID ( GID ) に使用され、その他のローカル ドメイン番号はサイト定義です。[ 6 ]非 POSIX システムでは、すべてのローカル ドメイン番号はサイト定義です。
したがって、バージョン 2 UUID は、指定された 8 ビット型 (「ドメイン」) の 32 ビットのローカル、ノード スコープの識別子と、ノードの識別子およびグレゴリオ暦由来のタイムスタンプを組み合わせることで、ノード スコープの識別子を普遍的に一意なものに変換する方法です。トレードオフは、タイムスタンプがバージョン 1 のタイムスタンプに比べて低解像度であり、429.49 秒 (7 分強) ごとに 1 回しかティックされないことです。これは、 バージョン 1 の 100 ナノ秒ティックとは大きく異なります。[ 15 ]
バージョン3とバージョン5のUUIDは、名前空間識別子と名前をハッシュ化することによって生成されます。バージョン3ではハッシュアルゴリズムとしてMD5が使用され、バージョン5ではSHA-1が使用されます。[ 9 ]これは、システムが調整なしに、他の名前や識別子のセットに基づいて同じUUIDを決定論的に生成する必要がある場合に役立ちます。
名前空間識別子自体がUUIDです。RFCでは、URL、完全修飾ドメイン名、オブジェクト識別子、およびX.500識別名の名前空間を表すための定数UUIDが提供されていますが、任意のUUIDを名前空間指定子として使用できます。追加の名前空間IDについては、IANAレジストリを参照してください。
指定された名前空間と名前に対応するバージョン 3 UUID を決定するには、名前空間の UUID をバイト列に変換し、入力名と連結し、MD5 でハッシュ化して 128 ビットにします。次に、6 ビットまたは 7 ビットを固定値に置き換えます。4 ビットバージョン (バージョン 3 の場合は 0011 2など) と、2 ビットまたは 3 ビットの UUID 「バリアント」 ( RFC 9562 [ 9 ] UUID を示す 10 2や、従来の Microsoft GUID を示す 110 2など) です。このように 6 ビットまたは 7 ビットが事前に決定されているため、UUID の一意性に寄与するのは 121 ビットまたは 122 ビットのみです。
バージョン5のUUIDはMD5と似ていますが、MD5の代わりにSHA-1が使用されます。SHA-1は160ビットのダイジェストを生成するため、バージョンとバリアントのビットが置き換えられる前に、ダイジェストは128ビットに切り詰められます。
バージョン3とバージョン5のUUIDは、バージョンが与えられれば、同じ名前空間と名前が同じUUIDにマッピングされるという特性を持っています。しかし、名前空間と名前のどちらかが指定されていても、総当たり検索以外ではUUIDから名前空間と名前を特定することはできません。RFC 4122は、バージョン3（MD5）よりもバージョン5（SHA-1）を推奨しています。これは、MD5の方がSHA-1よりも衝突が発生しやすいと考えられているためですが、MD5の方が若干高速です。RFCは、セキュリティ機能としてどのバージョンのUUIDも使用しないよう警告しています。[ 1 ]： 16
バージョン4のUUIDはランダムに生成されます。他のUUIDと同様に、バージョン4を示すために4ビット、バリアントを示すために2ビットまたは3ビット（バリアント1と2の場合はそれぞれ10²または110² ）が使用されます。したがって、バリアント1（つまり、ほとんどのUUID）の場合、ランダムに生成されたバージョン4のUUIDは、あらかじめ決められた6つのバリアントとバージョンビットを持ち、ランダムに生成される部分には122ビットが残ります。合計で2¹²² 、つまり5.3 × 10バージョン4、バリアント1のUUIDは36種類（5.3ウンデシリオン）存在する。バージョン4、バリアント2のUUID（レガシーGUID）は、利用可能な乱数ビットが1つ少ないため、バリアント用に3ビットが消費されるため、その半分の数しか存在しない。
バージョン7のUUIDは、大規模データベースや分散システムにおいて、単調増加で作成時刻順に並び、辞書式順序でソート可能なキーとして設計されており、局所性とパフォーマンスの向上に貢献します。バージョン7をデータベースキーとして使用すると、「新しい」レコードはキーシーケンスの論理的な末尾に挿入され、時間的に近いレコードはキーシーケンス内で互いに近くなります。これは、ランダムなバージョン4とは対照的です。バージョン4をデータベースキーとして使用すると、基となるレコードが時間的に近い場合でも、キーシーケンス全体に均等かつランダムに分散されるため、多くの種類のデータベースでパフォーマンスに悪影響を及ぼします。
それらは以下のように構成されています。
タイムスタンプに加えて、3 つのオプション構成要素 (タイムスタンプの精度、シード付きカウンタ、ランダムデータ) 用に合計 74 ビットが用意されていますが、構成要素の順序と、タイムスタンプの精度向上に最大 12 ビットを使用するという要件を除いて、各構成要素に割り当てられるビット数 (0 ビットを含む) と構成要素の詳細は実装者に委ねられています。48 ビットのタイムスタンプは、単調性とプライバシーのために変更、ファジング、またはぼかすことができます。また、タイムスタンプが実際の (Unix) 時刻にどれだけ近い必要があるかについての要件はないと明示的に述べられています。しかし、タイムスタンプは単調で Unix 時刻に近似するべきであるという意図は明らかであり、RFC では、Unix 時刻ではないタイムスタンプベースの設計にはカスタム UUID バージョン 8 を使用する必要があると述べています。他のUUIDバージョンとは異なり、バージョン7のUUIDはMACアドレスを組み込んでいないため、MACアドレスに関連するプライバシーの問題を回避できます。
カスタムUUIDでは、バージョンは8、バリアントビットは10、合計6ビットでなければなりません。残りの122ビットは指定されていません。
RFCによると、バージョン8のUUIDは、実験的な用途やベンダー固有の用途を想定しています。RFCでは、例えば、UUIDバージョン3（MD5）およびバージョン5（SHA-1）で指定されているハッシュ関数よりも新しいハッシュ関数で生成された名前/ハッシュベースの識別子にこのバージョンを使用できると示唆しています。また、RFCでは、バージョン6または7に適合しないタイムスタンプベースのUUID設計（例えば、異なるエポックなど）にもバージョン8を使用できると示唆しています。
しかし、バージョン8はこのようなシナリオに限定されるものではありません。本質的に、バージョン8のUUIDは122ビットの不透明ビットと、6ビットのバージョンおよびバリアントビットを組み合わせたものであり、他のUUID形式と区別することができます。
他のバージョンとは異なり、RFC では特定のビットレイアウトや生成アルゴリズムは規定されておらず、一意であると想定されることもありません。バージョン 4 UUID は高エントロピーの乱数源から 122 ビット生成され、一意性と衝突耐性が数学的分析の対象となるのに対し、バージョン 8 UUID の一意性、推測不可能性、衝突耐性、プライバシーなどは、一般的に、ソース (既知の場合) への信頼、帯域外調整、または標準規格以外の外部ドキュメントに基づいてのみ信頼できます。さらに、他の UUID バージョンと同様に、バージョン サブタイプの概念はありません。バージョン 8 の場合、これは、複数のソースと生成方法からのバージョン 8 UUID が単一のストリームまたはデータベースにプールされ、一部に問題があることが判明した場合、可能であれば解決する以外に、ソースごとに UUID を分離する方法がないことを意味します。
他の UUID バージョンとは対照的に、バージョン 1、2、および 6 はネットワーク カードの MAC アドレスに基づいており、その一意性は、中央登録機関によって発行された識別子、つまりMAC アドレスの組織固有識別子(OUI) 部分に依存しています。OUI は、主にネットワーク機器の製造業者にIEEEによって発行されます。 [ 16 ]ネットワーク カードの MAC アドレスに基づく UUID の一意性は、ネットワーク カードの製造業者がカードに固有の MAC アドレスを適切に割り当てることにも依存しますが、これは他の製造プロセスと同様にエラーが発生する可能性があります。MAC アドレスは、ネットワーク カード以外のソースから取得される場合もあります。たとえば、仮想マシンはハイパーバイザで構成可能な範囲から MAC アドレスを受け取ります。[ 17 ]また、一部のオペレーティングシステムでは、エンド ユーザーが MAC アドレスをカスタマイズできます。特にOpenWrtがそうです。[ 18 ]デバイスが EUI-64 64 ビットの「MAC アドレス」を持っている場合、RFC で推奨されているようにその下位 48 ビットを使用すると、UUID のノード ID 部分が重複する可能性があります。そのため、MAC アドレスに基づくノード ID はグローバルに一意ではない可能性があります。
ノードIDにノードのネットワークカードMACアドレスを使用すると、バージョン1、2、6のUUIDは、それらを作成したコンピュータまで追跡できることがよくあります。このようなUUIDは、UUIDの生成に使用されているハードウェアの種類を推測するために使用できます。文書は、ワープロソフトによって埋め込まれたUUIDを通じて、作成または編集されたコンピュータまで追跡できる場合があります。このプライバシーの脆弱性は、Melissaウイルスの作成者を特定する際に使用されました。[ 19 ]
RFC 9562 [ 9 ]では、ノードに MAC アドレスがない場合、または MAC アドレスを含めることが望ましくない場合、バージョン 1、2、または 6 の UUID の MAC アドレスをランダムな 48 ビットのノード ID に置き換えることが許可されています。この場合、RFC では、ノード ID の最初のオクテットの最下位ビットを 1 に設定する必要があると規定されています。[ 1 ]これは MAC アドレスのマルチキャストビットに対応しており、これを設定することで、ノード ID がランダムに生成された UUID と、通常ユニキャストMAC アドレスを持つネットワーク カードの MAC アドレスに基づく UUID を区別することができます。[ 1 ]
バージョン1、2、6、7は、UUIDが生成された時刻に基づいており、その時刻は多くの場合、レコードの作成や歴史的な出来事に対応しています。UUIDが人物やその活動に関連付けられている場合、UUIDから人物の年齢や活動の正確な時刻を推測できる可能性があります。時間ベースで単調増加するUUIDからは、システムが稼働を開始した時期や、システム内のどのオブジェクトが新規または最近更新されたかを判断できる可能性があります。たとえば、識別されたオブジェクトが製品の注文やユーザーのサインアップを表している場合、UUIDから時間の経過に伴うユーザー数の増加や売上高を判断できる可能性があります。したがって、時間ベースのUUIDが公開されている場合、個人情報や企業情報が漏洩し、プライバシーに関する懸念が生じ、望ましくないデータマイニングを助長する可能性があります。
UUIDの時間順序とソート可能性に関して、バージョン1と2はタイムスタンプの下位32ビットを「中間」として開始します。これらの2つのバージョンは、バージョン3～5および8と同様に、時間順に辞書式ソートされません。これらのUUIDバージョンにおけるタイムスタンプの役割は、UUIDを時間的に容易に順序付けできるようにすることではなく、空間と時間における生成を固定することで普遍的な一意性を実現することでした。
バージョン6と7では、データベースのインデックス作成においてタイムスタンプの役割が優先され、レコードを時系列順に並べ替えることが可能になっています。しかし、RFC 9562ではバージョン7の実装に大きな柔軟性が与えられており、オプションのサブミリ秒単位のタイムスタンプ精度、カウンタ、乱数生成のための厳密なビットレイアウトではなく、一般的なフレームワークが定義されています。
この仕様では、48ビットのUnixタイムスタンプを調整または「ファジング」して、単調性（連続して作成されたIDが常に増加するようにする）を維持したり、プライバシーを強化したりすることができます。RFCでは実際のUnix時間からの厳密な最大偏差を定義していないため、異なる実装では、時系列の正確さとこれらの他の要件とのバランスの取り方が異なる場合があります。[ 20 ]
したがって、バージョン6および7のUUIDの語彙的ソート可能性は、同じライブラリまたはシステムによって生成された場合に最も安定します。異なるソースからのUUIDを混在させたり、単一のデータベース内で異なるバージョンやバリアントを混在させたりすると、これらのバージョンが提供するように設計された時間順序付けとインデックスの局所性が低下する可能性があります。
RFC 9562 はバージョン 7 の最小乱数ビット数を規定していません。128 ビット構造の残りの部分をサブミリ秒精度と単調性カウンタ フィールドが占めることを許可しています。したがって、衝突耐性と推測可能性は、これらのビットの特定の実装による割り当てに完全に依存します。[ 21 ]
Nil UUID は00000000-0000-0000-0000-000000000000(つまり、すべてのビットがクリア) であり、「そのような値はありません」という概念を表現するのに役立ちます。[ 9 ]これは、アドレス ファミリが「0」の「バリアント 0」 NCS UUID であり、NCS では「未指定または初期化されていません」と定義されています。Max UUID は、Omni UUID とも呼ばれ、FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF(つまり、すべてのビットがセット) です。これは、「UUID リストの終わり」を表現するために使用することを目的としています。[ 9 ]
当初、アポロコンピュータは、バージョン1および6と同様に、タイムスタンプとノード識別子に基づいて、次のワイヤフォーマットでUUIDを設計しました[ 4 ] [ 22 ]。
RFC 4122 では、新しいフォーマットのバリアント ビットを NCS アドレス ファミリ フィールドと重ね合わせることで、従来の NCS UUID を新しいフォーマットの「バリアント 0」として組み込みました。NCS で定義されているアドレス ファミリの最大値は 13 (16 進数で 00 ～ 0D) であるため、既存の NCS UUID ではバリアント オクテットの最上位ビットは常に 0 ですが、新しい 3 つの IETF バリアントではこのビットは 1 になります。事実上、NCS アドレス ファミリ 0 ～ 127 が新しい「バリアント 0」となり、NCS で未定義だった NCS アドレス ファミリ 128 ～ 255 の番号空間は、バリアント 1 ～ 3 の IETF および Microsoft UUID に再割り当てされました。その結果、従来の NCS UUID とバリアント 1 ～ 3 の UUID は分離され、同じデータベースおよび同じ通信チャネルで共存できるようになりました。
従来の Apollo NCS UUID は、前の表で説明した形式です。OSF DCE UUID バリアントは、RFC 9562 [ 9 ]で説明されています。Microsoft COM / DCOM UUID のバリアントは、Microsoft のドキュメントで説明されていますが、バージョン 1 ～ 5 では、追加のバリアント ビットとバイト順序を除いて、DCE バリアントとほぼ同じです。（次のセクションを参照）。バリアント 2 には、バージョン 6 ～ 8 はありません。
バリアント1と2では、さまざまなビットブロックの解釈が「バージョン」に応じて異なります。バリアント2では、data_a、data_b、version|data_cはバイトスワップされますが、variant|data_dとdata_eはバイトスワップされません。
バリアント 1 の UUID は、ビッグエンディアンで順次エンコードされます。たとえば、00112233-4455-6677-8899-aabbccddeeffはバイトとしてエンコードされます00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff。[ 23 ] [ 24 ]
対照的に、バリアント 2 UUID ("GUID"): は、歴史的に Microsoft COM/OLE ライブラリで使用され、混合エンディアン形式を持ち、最初の 3 つのフィールド (バージョン 1 のタイムスタンプ サブフィールドに対応) はリトルエンディアンですが、最後の 2 つのフィールドはビッグ エンディアンのバイト配列として出力されます。上記の UUID の例がバリアント 2 UUID であれば、ワイヤ上では としてエンコードされます33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff。[ 25 ] [ 26 ]バリアント 2 より下のすべてのバージョンは、3、4、5 のように数値フィールドを含まないバージョンも含め、このバイト順序で出力されます。
ほとんどの場合、UUID はハイフンで区切られた 16 進数値で表されます。最もよく使われるのは 8-4-4-4-12 形式で、4 つのハイフンで区切られた 32 桁の 16 進数値ですxxxxxxxx-xxxx-vxxx-wxxx-xxxxxxxxxxxx。ハイフンはバージョン 1 フィールドを区切っていますが、同じ形式がすべてのバージョンで一般的に使用されます。各 16 進数値は 4 ビットを表します。はvバージョン ニブルを表し、の上位 1 ～ 3 ビットはwバリアントです。Windows レジストリ形式は同じですが、UUID を中{}括弧で囲みます。バリアント 2 のバイト順序の違いはバイナリ ストレージまたはワイヤでの送信に適用され、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 4122 [ 1 ]は、URN の「uuid」名前空間を登録します。これにより、UUID から URN を生成できるようになりますurn:uuid:550e8400-e29b-41d4-a716-446655440000。通常の 8-4-4-4-12 フォーマットが使用されます。
UUID からOIDを作成することも可能で、それによって URN を作成する別の方法も得られます。前の例の OID は です2.25.113059749145936325402354257176981405696。UUID の符号なし 10 進数形式には が接頭辞として付き2.25、これは{joint-iso-itu-t(2) uuid(25)}OID 名前空間内の「アーク」を表します。これにさらに を接頭辞として付けることで、urn:oid:UUID の 2 番目の URN 形式を作成できます。一般的には、uuidよりも の URN が推奨されますoid。
衝突は、同じUUIDが複数回生成され、異なる参照先に割り当てられた場合に発生します。MACアドレスやタイムスタンプを一意に保持する多くの標準バージョン1、2、6のUUIDの場合、衝突は製造上の問題、時計のずれ、ソフトウェアのバグなどのエラーによってのみ発生します。
乱数生成やハッシュ化などのプロセスを用いて生成されたUUIDのバージョンにエラーがあると、UUIDの重複が発生することもあります。例えば、バージョン4のUUIDを生成する際には、エントロピーの高い乱数源を用いることが重要です。しかし、このようなUUIDでも、エラーがなくても偶然（いわゆる「不運」）によって衝突が発生することがあります。
この確率は通常非常に小さいため無視でき、誕生日問題の分析に基づいて正確に計算できます。[ 27 ]例えば、少なくとも1回の衝突の確率が50%になるように生成する必要のあるランダムなバージョン4 UUIDの数は2.71 京であり、次のように計算されます。[ 28 ]
この数は、1秒間に10億個のUUIDを約86年間生成することに相当します 。1UUIDあたり16バイトのUUIDをこれだけ含むファイルは、約43.4エクサバイト（37.7 EiB）になります。これは、識別子のみをリストしたファイルであり、現在存在する最大のデータベース（100 PB程度、例えばGoogleのウェブインデックス）よりも数桁大きいサイズです。標準に従って生成された場合、重複するUUIDは、UUID生成時の偶然の結果ではなく、メモリやディスクストレージを通過する宇宙線によって引き起こされるビット反転（いわゆるシングルイベントアップセット）の結果である可能性の方が高いです。
少なくとも 1 つの衝突が見つかる確率がpとなるために生成する必要のあるバージョン 4 UUID の最小数は、次の式で近似されます。
したがって、適切に生成された103兆個のバージョン4 UUIDの中に重複が見つかる確率は 10億分の1である。
いくつかのファイルシステムタイプ（例えば、ext4やBtrfs）は、UUIDを使用して各ファイルシステムをオペレーティングシステムに一意に識別します。（NTFSやFAT32はUUIDを使用せず、代わりに短いUID（一意の識別子）を使用します。）[ 29 ]
ファイルシステムのユーザー空間ツール[ 30 ]は、そのほとんどはTheodore Ts'oによるオリジナルの実装[ 14 ]から派生しているため、UUIDを使用します。
ファイルは、これらのUUID（またはFAT32 EFIシステムパーティション（ESP）/etc/fstabのUID）に基づいてマウントポイントを割り当てる場合があります。
# device-uuid mount-point fs-type options dump pass UUID = b18e3b6c-ccb7-4308-b527-35e5e6ee2145 / btrfs defaults 0 0 UUID = 103C-86D6 /efi vfat utf8 0 2 UUID = 64f3cb6a-e70e-45e5-8b90-d86cddbab7bb swap swap defaults 0 0 UUID = eda746c6-1f1b-4cf1-9225-d8b0b46511cc /mnt/Stuff btrfs defaults 0 0GUIDパーティションテーブル（GPT）は、UUID（ここでは「GUID」と呼ばれます）を使用してパーティションとパーティションタイプを識別します。一意のパーティションIDは、オペレーティングシステムによってローカルに割り当てられます。パーティションタイプIDは既知の数値であり、通常はオペレーティングシステムまたはハードウェアベンダーによって割り当てられます。
Microsoftのコンポーネントオブジェクトモデル（COM）では、いくつかの種類のGUIDが使用されています。
[HKEY_CLASSES_ROOT\Interface][ 31 ]に保存されます）[HKEY_CLASSES_ROOT\CLSID]）。実際には、インターフェースをリモート処理するにはプロキシ/スタブオブジェクトが必要になる場合があり、一部のツールセットでは、インターフェースのIIDと同じCLSID を持つプロキシ/スタブオブジェクトを作成していました。[HKEY_CLASSES_ROOT\TypeLib][ 32 ]に格納）[HKEY_CLASSES_ROOT\Component Categories][ 33 ]に記載されている特定のクラスカテゴリに属していることが識別されます。）UUID は、データベーステーブルで一意のキーとしてよく使用されます。Microsoft SQL Serverバージョン 4 Transact-SQLのNEWID関数は、標準のランダムなバージョン 4 UUID を返しますが、NEWSEQUENTIALID関数は、次のシステム再起動まで順番に昇順になるようにコミットされる UUID に似た 128 ビットの識別子を返します。[ 34 ] Oracle Database のSYS_GUID関数は、その名前にもかかわらず、標準の GUID を返しません。代わりに、ホスト識別子とプロセスまたはスレッド識別子に基づいて、GUID に多少似た 16 バイトの 128 ビット RAW 値を返します。[ 35 ] PostgreSQL にはUUIDデータ型が含まれており[ 36 ]、モジュールの関数を使用してほとんどのバージョンの UUID を生成できます。[ 37 ] [ 38 ] MySQL には、標準のバージョン 1 UUID を生成するUUID関数があります。 [ 39 ]
バージョン 3、4、5 の標準 UUID のランダムな性質と、標準バージョン 1 および 2 内のフィールドの順序により、UUID を主キーとして使用する場合にデータベースの局所性やパフォーマンスに問題が生じる可能性があります。たとえば、2002 年に Jimmy Nilsson は、キーとして使用されているバージョン 4 UUID をシステム時間に基づく非ランダムな接尾辞を含むように変更すると、Microsoft SQL Server のパフォーマンスが大幅に向上したと報告しました。バージョン 1 および 2 の UUID を並べ替えてエンコードし、タイムスタンプが最初に来るようにすることで、挿入パフォーマンスの低下を回避できます。[ 40 ]これが、RFC 9562 [ 9 ]で標準化されたバリアント 1 (DCE) バージョン 6 および 7 の根拠です。
様々な標準化プロジェクトに参加している…。
実行時に、グローバルに一意なインターフェイス識別子 (IID) を使用してインターフェイスを参照します。
この
IID
は、COM でサポートされているグローバルに一意な識別子 (
GUID
)の特定のインスタンスであり
、不要なオーバーヘッドや、同じ名前の同じインターフェイスの複数のバージョンが存在することによってシステムに発生する可能性のある混乱なしに、オブジェクトがインターフェイスのセマンティクスをサポートしているかどうかを正確に問い合わせることができます。
レジストリのよく知られた場所に保存されています。