普遍的に一意の識別子

フリー百科事典ウィキペディアより
ナビゲーションにジャンプ 検索にジャンプ

普遍的に一意の識別子
Linux の UEFI 変数 screenshot.png
UEFI変数で使用される UUID/GUID
頭字語UUID
組織
 数32
123e4567-e89b-12d3-a456-426614174000
WebサイトRFC4122  _

Universally Unique Identifier ( UUID ) は、コンピューター システムで情報に使用される128 ビットの ラベルです。グローバル一意識別子( GUID )という用語も使用されます。[1]

標準的な方法に従って生成された場合、UUID は実用上は一意です。それらの一意性は、他のほとんどの番号付けスキームとは異なり、中央の登録機関やそれらを生成する当事者間の調整に依存しません。UUID が重複する確率はゼロではありませんが、無視できるほどゼロに近い値です。[2] [3]

したがって、誰でも UUID を作成し、それを使用して、何かを識別するために既に作成された、または作成される識別子と重複しないことをほぼ確実に識別できます。したがって、独立した関係者によって UUID でラベル付けされた情報は、後で単一のデータベースに結合したり、同じチャネルで送信したりすることができ、重複の可能性はほとんどありません。

UUID の採用は広く行われており、多くのコンピューティング プラットフォームが UUID の生成とテキスト表現の解析をサポートしています。

歴史

1980 年代に、Apollo Computerは当初Network Computing System (NCS) でUUID を使用し、その後Open Software Foundation (OSF) のDistributed Computing Environment (DCE) で使用しました。DCE UUID の初期設計は、NCS UUID に基づいていました[4] 。その設計は、 Apollo Computer によって設計されオペレーティング システムであるDomain/OSで定義され、広く使用されている ( 64 ビット) 一意の識別子に触発されました。その後、[いつ?] Microsoft Windowsプラットフォームは、DCE 設計を「グローバル一意識別子」(GUID) として採用しましたRFC 4122 はURNを登録しましたUUID の名前空間[1]を参照し、以前の仕様を同じ技術的内容で要約しました。[要出典] 2005 年 7 月に RFC 4122 が提案されたIETF規格として公開されたとき、ITUは以前の規格と RFC 4122 の初期バージョンに基づいて、UUID も規格化しました。[要出典]

基準

UUID は、分散コンピューティング環境(DCE)の一部として Open Software Foundation (OSF) によって標準化されています。[5] [6]

UUID は、ISO / IEC 11578:1996「情報技術 – オープン システム相互接続 –リモート プロシージャ コール(RPC)」の一部として文書化されており、最近では ITU-T Rec. X.667 | ISO / IEC 9834-8:2005。[7]

Internet Engineering Task Force (IETF) は、 ITU-T Rec と技術的に同等Standards-Track RFC 4122 [1]を発行しました。X.667 | ISO/IEC 9834-8。

フォーマット

正規のテキスト表現では、UUIDの 16オクテットは 32 桁の 16進数(base-16) で表され、ハイフンで区切られた 5 つのグループに分けられ、8-4-4-4-12 の形式で合計 36 文字になります。 (32 個の 16 進数文字と 4 個のハイフン)。例えば:

123e4567-e89b-12d3-a456-426614174000
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

4 ビットのMフィールドと 1 ~ 3 ビットのNフィールドは、UUID 自体の形式をコード化します。

数字の 4 ビットはMUUID バージョンであり、数字の最上位 1 ~ 3 ビットはNUUID バリアントをコードします。(以下を参照してください ) 例では、M1であり、Na(10xx 2 ) です。これは、これがバージョン 1、バリアント 1 の UUID であることを意味します。つまり、時間ベースの DCE/RFC 4122 UUID です。

正規の 8-4-4-4-12 フォーマット文字列は、UUID の 16 バイトのレコード レイアウトに基づいています: [1]

UUID レコードのレイアウト
名前 長さ (バイト) 長さ (16 進数) 長さ (ビット) コンテンツ
time_low 4 8 32 時刻の下位 32 ビットを示す整数
time_mid 2 4 16 時刻の中央の 16 ビットを示す整数
time_hi_and_version 2 4 16 最上位ビットの 4 ビットの「バージョン」、その後に時刻の上位 12 ビット
clock_seq_hi_and_res clock_seq_low 2 4 16 最上位ビットの 1 ~ 3 ビットの「バリアント」と、それに続く 13 ~ 15 ビットのクロック シーケンス
ノード 6 12 48 48 ビットのノード ID

これらのフィールドは、バージョン 1 および 2 の UUID (つまり、時間ベースの UUID) のフィールドに対応しますが、UUID の構成が異なっていても、すべての UUID に同じ 8-4-4-4-12 表現が使用されます。

RFC 4122 セクション 3では、入力時に大文字と小文字を区別せずに、文字を小文字で生成する必要があります。

Microsoft GUID は、周囲の中括弧で表される場合があります。

{123e4567-e89b-12d3-a456-426652340000}

この形式を、中かっこの形式を指す" Windows レジストリ形式"と混同しないでください。[8]

RFC 4122 は、UUID のUniform Resource Name (URN) 名前空間を定義します。URN として提示される UUID は次のように表示されます: [1]

urn:uuid:123e4567-e89b-12d3-a456-426655440000

エンコーディング

UUID のバイナリ エンコーディングは、システムによって異なります。バリアント 1 UUID は、現在最も一般的なバリアントであり、ビッグエンディアン形式でエンコードされています。たとえば00112233-4455-6677-8899-aabbccddeeff、バイトとしてエンコードされます00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff[9] [10]

Variant 2 の UUID は、歴史的に Microsoft のCOM/OLE ライブラリで使用されており、混合エンディアン形式を使用します。これにより、UUID の最初の 3 つの構成要素はリトルエンディアンであり、最後の 2 つはビッグエンディアンです。たとえば00112233-4455-6677-c899-aabbccddeeff、バイトとしてエンコードされます33 22 11 00 55 44 77 66 c8 99 aa bb cc dd ee ff[11] [12]バリアント 2 で「88」バイトが「c8」になる理由の詳細については、バリアントのセクションを参照してください。

バリアント

UUID の「バリアント」フィールド、またはN位置は、その形式とエンコードを示します。RFC 4122 では、長さが 1 ~ 3 ビットの 4 つのバリアントが定義されています。

  • バリアント 0 (1 ビット パターン 0xxx 2 , N  = で示される) は、現在は廃止された Apollo Network Computing System0..7との後方互換性のためのものです。1.5 UUID 形式は 1988 年頃に開発されました。UUID の最初の 6 オクテットは 48 ビットのタイムスタンプ (1980 年 1 月 1 日 UTC からの 4 マイクロ秒単位の時間数) です。次の 2 オクテットは予約されています。次のオクテットは「アドレス ファミリー」です。最後の 7 オクテットは、アドレス ファミリで指定された形式の 56 ビットのホスト ID です。詳細は異なりますが、最新のバージョン 1 UUID との類似性は明らかです。現在の UUID 仕様のバリアント ビットは、NCS UUID のアドレス ファミリ オクテットの上位ビットと一致します。アドレス ファミリは 0..255 の範囲の値を保持できますが、定義されたのは 0..13 の値だけです。したがって、Variant-0 ビット パターン0xxxは、データベースにまだ存在する場合に、過去の NCS UUID との競合を回避します。[13]
  • バリアント 1 (10xx 2N  =  、2 ビット) は、RFC 4122/DCE 1.1 UUID、または元のInternet Draft8..bの作成者にちなんで「Leach–Salz」UUID と呼ばれます
  • バリアント 2 (110x 2N  =  c..d、3 ビット) は、RFC で「予約済み、Microsoft Corporation 下位互換性」として特徴付けられ、Microsoft Windowsプラットフォームの初期の GUID に使用されました。バリアント 1 とは、バイナリ ストレージまたは転送のエンディアンのみが異なります。バリアント 1 UUID は「ネットワーク」(ビッグ エンディアン) バイト オーダーを使用しますが、バリアント 2 GUID は一部のサブフィールドに「ネイティブ」(リトル エンディアン) バイト オーダーを使用します。 UUIDの。
  • 予約済みは、3 ビットのバリアント ビット パターン 111x 2 ( N  =  e..f) として定義されます。

バリアント 1 と 2 は、現在の UUID 仕様で使用されています。テキスト表現では、バリアント 1 と 2 は、バリアント ビットを除いて同じです。バイナリ表現では、エンディアンの違いがあります。[1]バリアント 1 のビッグ エンディアン バイト順とバリアント 2 のリトル エンディアン バイト順の間で変換するためにバイト スワッピングが必要な場合、上記のフィールドはスワッピングを定義します。最初の 3 つのフィールドは符号なしの 32 ビットおよび 16 ビット整数であり、スワッピングの対象となりますが、最後の 2 つのフィールドは未解釈のバイトで構成されており、スワッピングの対象ではありません。このバイト スワッピングは、正規フィールドが UUID の内容に対応しないバージョン 3、4、および 5 にも適用されます。[1]

Component Object Model IUnknownインターフェイスの識別子など、一部の重要な GUIDは名目上バリアント 2 UUID ですが、Microsoft Windows ソフトウェアで生成および使用され、「GUID」と呼ばれる多くの識別子は標準のバリアント 1 RFC 4122/DCE 1.1 です。リトル エンディアンのバリアント 2 UUID ではなく、ネットワーク バイト オーダーの UUID。Microsoft ツールの現在のバージョンは、guidgen標準のバリアント 1 UUID を生成します。一部の Microsoft ドキュメントでは、「GUID」は「UUID」の同義語であると記載されています[14]。RFC 4122 で標準化されています。RFC 4122 自体には、UUID は「GUID とも呼ばれる」と記載されています。これはすべて、Microsoft が使用する UUID のバリアントを指す「GUID」が、単に UUID の代替名になり、バリアント 1 とバリアント 2 の両方の GUID が存在することを示唆しています。

バージョン

バリアント 1 と 2 の両方について、5 つの「バージョン」が標準で定義されており、特定のユース ケースでは、各バージョンが他のバージョンよりも適切な場合があります。バージョンはM文字列表現の で示されます。

バージョン 1 UUID は、時刻とノード ID (通常はMAC アドレス) から生成されます。バージョン 2 UUID は、識別子 (通常はグループまたはユーザー ID)、時刻、およびノー​​ド ID から生成されます。バージョン 3 および 5 は、名前空間の識別子と名前をハッシュすることによって生成される決定論的な UUID を生成します。バージョン 4 の UUID は、乱数または疑似乱数を使用して生成されます。

ゼロ UUID

特殊なケースである「nil」UUID は UUID00000000-0000-0000-0000-000000000000です。つまり、すべてのビットがゼロに設定されます。[1]

バージョン 1 (日時と MAC アドレス)

バージョン 1は、「ノード」(つまり、UUID を生成するコンピューター)の 48 ビットMAC アドレスを、 1582 年 10 月 15 日の午前 0 時からの 100ナノ秒間隔の数である 60 ビットのタイムスタンプと連結します。協定世界時(UTC) )、グレゴリオ暦がカトリック教会と教皇領以外で最初に採用された日付。RFC 4122 は、使用されるアルゴリズムに応じて、時間値が AD 3400 年頃[1] :  3ロールオーバーすると述べています。これは、60 ビットのタイムスタンプが署名された量であることを意味します。ただし、libuuid ライブラリなどの一部のソフトウェアは、タイムスタンプを署名なしとして扱い、ロールオーバー時間を 5236 AD に設定します。[15]ITU-T Rec で定義されているロールオーバー時間。X.667 は 3603 AD です。[16] :  v

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

他の UUID バージョンとは対照的に、ネットワーク カードの MAC アドレスに基づくバージョン 1 およびバージョン 2 の UUIDは、その一意性を中央登録機関によって発行された識別子、つまり MAC アドレスの組織固有識別子(OUI) 部分に部分的に依存しています。は、 IEEEによってネットワーク機器の製造元に発行されます。[17]ネットワーク カードの MAC アドレスに基づくバージョン 1 およびバージョン 2 の UUID の一意性は、ネットワーク カードの製造元がカードに一意の MAC アドレスを適切に割り当てているかどうかにも依存します。さらに、一部のオペレーティング システムでは、エンド ユーザーが MAC アドレス (特にOpenWRT ) をカスタマイズできます。[18]

ノード ID にノードのネットワーク カード MAC アドレスを使用することは、バージョン 1 の UUID を追跡して、それを作成したコンピューターまで遡ることができることを意味します。ドキュメントは、ワープロソフトウェアによってドキュメントに埋め込まれた UUID を介して、ドキュメントが作成または編集されたコンピュータまでたどることができます。このプライバシーホールは、Melissa ウイルスの作成者を特定する際に使用されました。[19]

RFC 4122 では、バージョン 1 (または 2) UUID の MAC アドレスをランダムな 48 ビット ノード ID に置き換えることが許可されています。これは、ノードに MAC アドレスがないか、またはそれを公開することが望ましくないためです。その場合、RFC では、ノード ID の最初のオクテットの最下位ビットを 1 に設定する必要があります。通常、ユニキャストMAC アドレスを持つネットワーク カードの MAC アドレスに基づいて、UUID からランダムに生成されます。[1]

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

RFC 4122 は、「DCE セキュリティ」UUID 用にバージョン 2 を予約しています。しかし、それは詳細を提供しません。このため、多くの UUID 実装ではバージョン 2 が省略されています。ただし、バージョン 2 UUID の仕様は、DCE 1.1 Authentication and Security Services 仕様で提供されています。[6]

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

UUID に 40 ビットのドメイン/識別子を含める機能にはトレードオフがあります。一方で、40 ビットでは、ノード ID ごとに約 1 兆のドメイン/識別子の値が許可されます。一方、クロック値が最上位 28 ビットに切り捨てられた場合、バージョン 1 の 60 ビットと比較して、バージョン 2 UUID のクロックは 429.49 秒ごとに 1 回だけ「カチカチ」と、7 分強になります。バージョン 1 の 100 ナノ秒ごとではなく、バージョン 1 の 14 ビットと比較してわずか 6 ビットのクロック シーケンスでは、16,384 と比較して、ノード/ドメイン/識別子ごとに 64 の一意の UUID しか生成できません。バージョン1のクロックシーケンス値。[20]したがって、バージョン 2 は、ノード/ドメイン/識別子ごとに、7 分ごとに約 1 つを超える速度で UUID が必要な場合には適していない可能性があります。

バージョン 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など)、および 2 ビットまたは 3 ビットの UUID "バリアント" ( RFC 4122 UUID を示す10 2 、または 110 2など) に置き換えられます。レガシ Microsoft GUID を示します)。このように 6 ビットまたは 7 ビットが事前に決定されているため、121 ビットまたは 122 ビットのみが UUID の一意性に寄与します。

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

バージョン 3 とバージョン 5 の UUID には、同じ名前空間と名前が同じ UUID にマップされるというプロパティがあります。ただし、名前空間と名前のいずれかが指定されていても、力ずくで検索しない限り、UUID から名前空間と名前を特定することはできません。RFC 4122 は、バージョン 3 (MD5) よりもバージョン 5 (SHA-1) を推奨しており、どちらのバージョンの UUID もセキュリティ資格情報として使用しないよう警告しています。[1]

バージョン 4 (ランダム)

バージョン 4 の UUID がランダムに生成されます。他の UUID と同様に、バージョン 4 を示すために 4 ビットが使用され、バリアントを示すために 2 または 3 ビットが使用されます (バリアント 1 および 2 に対してそれぞれ 10 2または 110 2 )。したがって、バリアント 1 (つまり、ほとんどの UUID) の場合、ランダム バージョン 4 UUID には 6 つの事前定義されたバリアントおよびバージョン ビットがあり、ランダムに生成された部分に 122 ビットが残り、合計で 2 122または 5.3 × 10になります。36 (5.3  10 億) の可能なバージョン 4 バリアント 1 UUID。バージョン 4 のバリアント 2 の UUID (レガシー GUID) の数は、利用可能なランダム ビットが 1 つ少なくなり、バリアントに 3 ビットが消費されるため、半分の数になります。

衝突

同じ UUID が複数回生成され、異なる参照先に割り当てられると、衝突が発生します。ネットワーク カードからの一意の MAC アドレスを使用する標準のバージョン 1 およびバージョン 2 UUID の場合、競合が発生する可能性は低く、実装が不注意または意図的に標準と異なる場合にのみ可能性が高くなります。

MAC アドレスを使用して生成されたバージョン 1 およびバージョン 2 の UUID とは対照的に、バージョン 1 およびバージョン 2 の UUID はランダムに生成されたノード ID、ハッシュベースのバージョン 3 およびバージョン 5 の UUID、およびランダムなバージョン 4 の UUID を使用します。衝突は実装上の問題がなくても発生する可能性がありますが、確率は非常に小さいため通常は無視できます。この確率は、誕生日問題の分析に基づいて正確に計算できます[21]

たとえば、少なくとも 1 回の衝突を 50% の確率で発生させるために生成する必要があるランダムなバージョン 4 UUID の数は、2.71 京であり、次のように計算されます: [22]

この数は、約 85 年間、毎秒 10 億の UUID を生成することに相当します。UUID あたり 16 バイトで、これだけ多くの UUID を含むファイルは、約 45 エクサバイトになります。

衝突を検出する確率がpになるように生成する必要があるバージョン 4 UUID の最小数は、次の式で概算されます。

したがって、103 兆のバージョン 4 UUID 内で重複を見つける確率は 10 億分の 1 です。

[

ファイルシステム

重要な用途には、ext2 / ext3 / ext4ファイルシステム ユーザー空間ツール ( e2fsprogsはutil-linuxによって提供される libuuid を使用)、LVMLUKS暗号化パーティション、GNOMEKDE ​​、およびmacOSが含まれます[23]。これらのほとんどは、 Theodore Tsによる元の実装から派生したものです。'o . [15]

Solarisでの UUID の使用(Open Software Foundation 実装を使用) の 1 つは、カーネル パニックの場合にクラッシュ ダンプ データと障害管理イベントをペアリングする目的で、実行中のオペレーティング システム インスタンスを識別することです。[24]

「パーティション ラベル」と「パーティション UUID」はどちらもスーパーブロックに格納されます。どちらもパーティションではなく、ファイル システムの一部です。たとえば、ext2–4 には UUID が含まれていますが、NTFS または FAT32 には含まれていません。

スーパーブロックはファイル システムの一部であるため、パーティション内に完全に含まれていますdd if=/dev/sda1 of=/dev/sdb1

COM

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

  • IID – インターフェイス識別子; (システムに登録されたものは[25]のWindows レジストリ保存されます)[HKEY_CLASSES_ROOT\Interface]
  • CLSID – クラス識別子; ( に保存[HKEY_CLASSES_ROOT\CLSID])
  • LIBID – タイプ ライブラリ識別子; [HKEY_CLASSES_ROOT\TypeLib]( [26]に格納)
  • CATID – カテゴリ識別子; [HKEY_CLASSES_ROOT\Component Categories](クラスに存在することで、 [27]にリストされている特定のクラス カテゴリに属していると識別されます)

データベースキーとして

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

バージョン 3、4、および 5 の標準 UUID のランダムな性質と、標準バージョン 1 および 2 内のフィールドの順序により、 UUID が主キーとして使用される場合、データベースの局所性またはパフォーマンスに問題が生じる可能性がありますたとえば、2002 年に Jimmy Nilsson は、キーとして使用されているバージョン 4 の UUID が変更され、システム時間に基づく非ランダム サフィックスが含まれるように変更されたとき、Microsoft SQL Server のパフォーマンスが大幅に向上したことを報告しました。このいわゆる「COMB」(時間と GUID の組み合わせ) アプローチにより、UUID が非標準になり、重複する可能性が大幅に高くなったと Nilsson は認めていますが、Nilsson が必要としたのはアプリケーション内での一意性のみでした。[34]タイムスタンプが最初になるようにバージョン 1 と 2 の UUID を並べ替えてエンコードすることで、挿入パフォーマンスの低下を回避できます。[35]

Laravelなどの一部の Web フレームワークは、インデックス化されたデータベース列に効率的に格納できる「タイムスタンプ ファースト」UUID をサポートしています。これにより、バージョン 4 形式を使用して COMB UUID が作成されますが、最初の 48 ビットが UUIDv1 のようにレイアウトされたタイムスタンプを構成します。[36] [37] COMB UUID の考え方に基づく、より具体的な形式には次のものがあります。

  • バージョン 4 を示すために使用される 4 ビットを捨て、デフォルトで base32 エンコーディングを使用する「ULID」。[38]
  • UUID バージョン 6 から 8、3 つの COMB UUID 形式の正式な提案。[39]

も参照

参考文献

  1. ^ a b c d e f g h i j k l m n リーチ、P.; ミーリング、M。Salz、R.(2005)。Universally Unique IDentifier (UUID) URN Namespaceインターネット エンジニアリング タスク フォースドイ: 10.17487/RFC4122 . RFC 4122 2017年1月17日閲覧
  2. ^ 「ユニバーサル一意識別子 (UUID)」 . H2 . 2021年3月21日閲覧
  3. ^ ITU-T 勧告X.667 : Universally Unique Identifier (UUID) の生成と登録、および ASN.1 オブジェクト識別子コンポーネントとしてのそれらの使用. 標準。2012 年 10 月。
  4. ^ ザーン、リサ (1990). ネットワーク コンピューティング アーキテクチャプレンティスホールp。10.ISBN _ 978-0-13-611674-5.
  5. ^ "CDE 1.1: リモート プロシージャ コール" . オープングループ。1997年。
  6. ^ a b c "DCE 1.1: 認証およびセキュリティ サービス" . オープングループ。1997年。
  7. ^ 「ITU-T 研究グループ 17 - オブジェクト識別子 (OID) および登録機関の推奨事項」 . ITU.int . 2016年 12 月 20 日閲覧
  8. ^ "タイプ 1 オンライン ストアのレジストリ キーとエントリ" . マイクロソフト開発者ネットワークマイクロソフト
  9. ^ スティール、ニック. 「UUID の分類」 .
  10. ^ "UUID バージョンの説明" .
  11. ^ リーチ、ポール. 「UUID と GUID」 .
  12. ^ "Guid.ToByteArray メソッド" .
  13. ^ "uuid.c" .
  14. ^ "グローバルに一意の識別子" . マイクロソフト開発者ネットワークマイクロソフト
  15. ^ a b "ext2/e2fsprogs.git - Ext2/3/4 ファイルシステム ユーザー空間ユーティリティ" . Kernel.org . 2017年1月9日閲覧
  16. ^ 「ITU-T X.667 勧告」 . www.itu.int2012 年 10 月2020年12月19日閲覧
  17. ^ 「登録機関」 . IEEE 規格協会
  18. ^ 「MAC アドレスの設定」 . オープンワート2021 年 9 月 15 日。{{cite web}}: CS1 maint: url-status (リンク)
  19. ^ ライター、ルーク (1999 年 4 月 2 日). 「メリッサの分身追跡」 . ZDネット2017年1月16日閲覧
  20. ^ Kuchling, AM "What's New in Python 2.5" . Python.org 2016年 1 月 23 日閲覧
  21. ^ イエス、パウロ。バケロ、カルロス。アルマイダ、パウロ。「モバイル環境での ID 生成」(PDF) . Repositorium.Sdum.Uminho.pt .
  22. ^ マティス、フランク H. (1991 年 6 月)。「一般化された誕生日の問題」. サイアムレビュー33 (2): 265–270. CiteSeerX 10.1.1.5.5851 . ドイ10.1137/1033051ISSN 0036-1445 . JSTOR 2031144 . OCLC 37699182    
  23. ^ Apple の Libc-391 の gen_uuid.c、Mac OS X 10.4 に対応
  24. ^ 「Solaris でのクラッシュダンプの再構築」 . Blogs.Oracle.comオラクル2017年1月9日閲覧
  25. ^ "インターフェイス ポインターとインターフェイス" . Windows デベロッパー センター - デスクトップ アプリ テクノロジマイクロソフト2015年 12 月 15 日閲覧グローバルに一意のインターフェイス識別子 ( IID )を使用して、実行時にインターフェイスを参照しますこのIIDは、COM でサポートされているグローバル一意識別子 ( GUID ) の特定のインスタンスであり、クライアントは、オブジェクトがインターフェイスのセマンティクスをサポートしているかどうかをオブジェクトに正確に問い合わせることができます。不必要なオーバーヘッドや、システムで発生する可能性のある混乱はありません。同じ名前の同じインターフェイスの複数のバージョンを持つことから。
  26. ^ 「タイプ ライブラリの登録」 . マイクロソフト開発者ネットワークマイクロソフト2015年 12 月 15 日閲覧
  27. ^ 「コンポーネント機能による分類」 . Windows デベロッパー センター - デスクトップ アプリ テクノロジマイクロソフト2015年 12 月 15 日閲覧CATID と人間が判読できる名前のリストは、レジストリ内の既知の場所に保存されます。
  28. ^ "NEWSEQUENTIALID (Transact-SQL)" . マイクロソフト開発者ネットワークマイクロソフト2015 年 8 月 8 日2017年1月14日閲覧
  29. ^ 「Oracle データベース SQL リファレンス」 . オラクル
  30. ^ "セクション 8.12 UUID タイプ" . PostgreSQL 9.4.10 ドキュメントPostgreSQL グローバル開発グループ。2020 年 2 月 13 日。
  31. ^ "uuid-ossp" . PostgreSQL: ドキュメント: 9.6 . PostgreSQL グローバル開発グループ。2021 年 8 月 12 日。
  32. ^ "pgcrypto" . PostgreSQL: ドキュメント: 9.6 . PostgreSQL グローバル開発グループ。2021 年 8 月 12 日。
  33. ^ "セクション 13.20 その他の関数" . MySQL 5.7 リファレンス マニュアル. オラクル社
  34. ^ ニルソン、ジミー (2002 年 3 月 8 日). お知らせします。お知らせします。2012年 6 月 20 日閲覧
  35. ^ 「MySQL に UUID 値を保存する」 . ペルコナ。2014 年 12 月 19 日。2020年 11 月 29 日に元の場所からアーカイブされました2021年2月10日閲覧
  36. ^ "Helpers - Laravel - Web Artisans のための PHP フレームワーク" . Laravel.com .
  37. ^ カブレラ、イタロ バエサ (2020 年 1 月 31 日). 「Laravel: 謎の「Ordered UUID」」" .ミディアム.
  38. ^ 「普遍的に一意の辞書編集的にソート可能な識別子」 . GitHub . ULID。2021 年 5 月 10 日。
  39. ^ ピーボディ、ブラッド; Davis、Kyzer R. (2021 年 10 月 7 日)。"draft-peabody-dispatch-new-uuid-format-01" . tools.ietf.org

外部リンク

基準

ITU-T UUID ジェネレーター

技術記事

その他

さまざまな言語での実装