UUIDジェネレーター

Universally Unique Identifier (UUID) は、Globally Unique Identifier (GUID) とも呼ばれ、コンピュータシステムで広く使用されています。

これは、現在時刻、MAC アドレス、SHA-1 ハッシュ、MD5 名前空間などの変数と定数に基づいてシステムによって生成される 128 ビットコードです。 UUID 生成の最終結果は、ハイフンで区切られた 32 文字の英数字コードとして表示され、任意に見えるかもしれませんが、実際には複雑な計算の結果です。したがって、コンピュータはコードを「発明」するのではなく、その時点で関連する特定の技術量からコードを形成します。

同じ UUID が異なる時間に 2 台の異なるコンピューター上で生成される確率はゼロに近づく傾向があるため、調整センターを参照せずに、結果として得られるコードをポイント/ローカルデータ識別に使用することが可能になります。現在、UUID/GUID はオンラインネットワークとオフラインネットワークの両方で普及しており、グローバルなインターネット空間だけでなく、スタンドアロンコンピュータシステムでも効果的に機能します。

UUID 履歴

128 ビット UUID コードは、1980 年代にアメリカの会社 Apollo Computer によって初めて使用されました。これらは、ドメイン/OS で使用される単純な 64 ビットコードに基づいており、Open Software Foundation コンピューティング環境で広く使用されています。

最初の Windows プラットフォームの出現により、グローバルに一意な識別子が一般化され、標準化されました。 Microsoft は、Apollo Computer の DCE 設計を採用し、URN 名前空間を RFC 4122 に登録しました。2005 年に、後者は IETF によって新しい標準として提案され、UUID は ITU 内で標準化されました。

2002 年の初めに、UUID をローカルデータベースの主キーとして使用する場合にシステムパフォーマンスの問題が確認されました。これらは、コンピュータのシステム時間に基づいて非ランダムなサフィックスを追加することにより、バージョン 4 で修正されました。いわゆる COMB (Combined GUID Time Identifier) アプローチにより、コード重複のリスクが増加しましたが、同時に Microsoft SQL Server での作業時のパフォーマンスが大幅に向上しました。

IT テクノロジーの発展により、ユニバーサル固有 ID は高度に専門化された技術ツールではなくなり、今日では誰もがそれを使用できるようになりました。生成されたコードの反復確率はゼロではありませんが、その傾向があり、デジタル情報はそれらによって識別され、その後、反復のリスクを最小限に抑えながら単一のデータ配列に結合できます。

UUID の利点

グローバル固有コードのジェネレーターは、一元的なデータ調整/同期を必要とせず、すべてのユーザーが自由に利用できます。 UUID の主な利点は次のとおりです。

コードの「衝突」（繰り返し）のリスクを最小限に抑えます。大量に使用されているにもかかわらず、繰り返される可能性はゼロになる傾向があります。
UUID を主（一意）キーとして使用して、さまざまなデータ配列を結合する機能
複数の分散サーバー間でのデータの分散の簡素化
オフラインでコードを生成できる機能

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx の形式で記述された固有の識別コードにより、分散システムは単一のデータセンターからの調整なしで、エラーや反復の可能性がほぼゼロで情報を認識できます。この機能は、使いやすさとコンピューターのパフォーマンス要件の低さに加えて、UUID の需要を高め、さまざまな IT 業界や自律型コンピューティングシステムで不可欠なものとなっています。

UUID は、さまざまなアルゴリズムと変数/定数値を使用してコードを生成できます。

識別子には合計 5 つのバージョンがあり、生成時にシステムの日付/時刻と MAC アドレス、DCE セキュリティプロトコル、MD5 ハッシュ、SHA-1 ハッシュ、および名前空間を使用します。

いずれの場合も、最終結果は xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx (ラテン語の小文字と数字で構成され、ハイフンで 5 つのブロックに分割された 16 進表記の数値: 8-4) の形式で表示されます。 -4-4- 12)、M はバージョンを表し、N は UUID バリアントを表します。

したがって、システムは一度に 36 文字 (26 文字と 10 数字) を使用するため、世界中の何百万ものユーザーによって毎日生成されているにもかかわらず、32 桁のコードが繰り返される確率はゼロになる傾向があります。

UUID バージョン

バージョン 1

コードを生成するときの一意の識別子の最初のバージョンは、コンピューターの MAC アドレスとそのシステム時間に基づいており、その数値は 1 秒あたり 1 回変更されます。生成プロセスは 5 つの段階で構成されます。

情報の下位 32 ビットは UTC タグから取得されます。これらは 8 つの 16 進文字に変換され、4 バイトを占めます。
平均 16 ビットの情報が同じ UTC ラベルから取得され、2 バイトを占める 4 つの 16 進文字に変換されます。
UTC タグからの上位 12 ビットの情報が取得され、さらに 4 つの 16 進文字に変換されます。
さらに 1 ～ 3 ビットがクロックシーケンスに含まれ、ある程度のランダム性/不確実性を導入することで衝突のリスクを軽減します。システム時間は、同じコンピュータ上で同時に動作する 2 つ以上の識別子が「交差」しないように、条件に応じて遅くされるか、逆に設定されます。
残りの 6 バイトは、デバイスの MAC アドレスに基づいて生成される定数値です。 12 個の 16 進文字で構成され、サイズは 48 ビットです。

UUID の最初のバージョンのアルゴリズムはシステム時間と密接に関係しているため、クロックシーケンスの使用は必須です。そうしないと、システム時間が何らかの値で「フリーズ」した瞬間に、同じコードが生成されるリスクが何倍にも増加します。

バージョン 2

2 番目のバージョンは最初のバージョンとほとんど異なり、実際にはほとんど使用されません。クロックシーケンスの代わりに、ユーザーデータに関連付けられたシステム識別子、または他のコンピューターで繰り返されないか、またはほとんど繰り返されないその他の一意の値が使用されます。 2 番目のバージョンではランダム性の影響が最小限に抑えられており、分散コンピューティング環境のセキュリティを向上させるために使用できます。

バージョン 3 および 5

これらには多くの共通点があります。コード、つまり非ランダムな値を作成するために、一意の名前と名前 (MD5 空間からの) を使用します。バージョン 3 のみが標準ハッシュを使用し、バージョン 5 は SHA-1 ハッシュを使用します。このような識別子は、確率変数への依存度が低くなります。

バージョン 4

この UUID バージョンの生成は 90% 以上ランダムです。定数値には 6 ビット、任意の値には 122 ビットがあります。アルゴリズムの実装では、最初に 128 ビットの情報がランダムに生成され、そのうちの 6 ビットがバージョンデータとバリアントデータに置き換えられます。

第 4 版の擬似乱数生成器の役割は最大限であり、アルゴリズムが単純すぎると反復/衝突のリスクが大幅に増加します。それにもかかわらず、これは最も一般的であり、実際によく使用されるのは 4 番目のバージョンです。

UUID オプション

一意の UUID は、コンピューター技術の発展に伴って何度も改良され、現在ではいくつかのバージョンで提供されています。

オプション 0

従来の Apollo Network Computing System 1.5 1988 形式のデータベースで動作するように設計されています。このオプションはそれらと下位互換性があり、NCS の過去の UUID と競合しません。

オプション 1 と 2

最新のデータブロックと配列を識別するために使用され、正規のテキスト形式では、バリアントビットの書き込み順序を除いて、互いに違いはありません。したがって、オプション 1 はビッグエンディアンのバイトオーダーを使用し、オプション 2 はタイトルエンディアンを使用します。 1 つ目はメインのもので、2 つ目は Microsoft Windows の初期の GUID を操作するために予約されています。

オプション 3

現在は使用されていません。これは、以前のオプションの可能性がなくなった場合に将来使用するために予約されたバージョンです。

ほとんどのシステムは識別子をビッグエンディアンでエンコードしますが、例外もあります。たとえば、Microsoft COM/OLE ライブラリのマーシャリングでは、タイトルエンディアンブロックとビッグエンディアンブロックからコードを生成する際に混合エンディアンが使用されます。 1 つ目は UUID の最初の 3 つのコンポーネントであり、2 つ目は最後の 2 つのコンポーネントです。

{$ subpageListHide ? ('Show' | translate) : ('Hide' | translate) $}