UUID v2ジェネレーター

Generate DCE Security UUID v2 with local domain and ID

「生成」をクリックして UUID を作成
注意:UUID v2 はローカルドメインと ID を UUID 構造に埋め込みます
Note:UUID v2 はレガシーフォーマットで、DCE セキュリティコンテキスト用に定義されています。現代のアプリケーションではほとんど必要ありません。汎用の一意 ID には UUID v4 が推奨されます。

UUID v2 とは何ですか?

UUID v2 は DCE セキュリティ UUID バージョンで、Distributed Computing Environment(DCE)仕様の一部として標準化され、RFC 4122 で参照されています。POSIX ユーザーまたはグループ識別子(UID/GID)をタイムスタンプフィールドに埋め込むことで UUID v1 を拡張します。

構造は UUID v1 に似ていますが、32 ビットの time_low フィールドが 32 ビットのローカル識別子(例:POSIX UID)に置き換えられ、1 バイトの local_domain フィールドがどの種類のローカル ID かを識別します。結果として、タイムスタンプが切り詰められ、精度と一意性の保証が低下します。

UUID v2 は現代のソフトウェアでは極めてまれです。ほとんどの開発者はこれを生成する必要はありません。このページはフォーマットを完全性のために文書化し、レガシーシステムで遭遇する UUID v2 値のデコードを支援します。

UUID v2 の構造

UUID v2 は他の UUID バージョンと同じ 128 ビットのハイフン付きフォーマットを持ちます。フィールドは UUID v1 と次のように異なります:

フィールドビット目的
local_id32<code>local_id</code>——32 ビットローカルドメイン識別子(例:<code>/etc/passwd</code> からの POSIX UID)、UUID v1 の time_low フィールドを置き換える
time_mid16<code>time_mid</code>——切り詰められた UUID v1 タイムスタンプの中間 16 ビット
time_hi+version16<code>time_hi_and_version</code>——最上位 12 ビットのタイムスタンプ、バージョンニブルを <code>2</code> に設定
variant+clock_hi8<code>clock_seq_hi_and_reserved</code>——バリアントビットとクロックシーケンスの上位部分
local_domain8<code>local_domain</code>——ドメイン識別子:<code>0</code> = POSIX ユーザー(UID)、<code>1</code> = POSIX グループ(GID)、<code>2</code> = 組織
node48<code>node</code>——生成ホストの 48 ビット MAC アドレス

例:000003e8-92e0-21ef-8000-325096b39f47——local_id 0x000003e8 = UID 1000、local_domain 0x00 = POSIX ユーザー

Note:local_id フィールドが time_low フィールドを置き換えるため、UUID v2 のタイムスタンプは 28 ビット幅しかありません(UUID v1 の 60 ビットと比較して)。これによりタイムスタンプ精度が約 7.2 分に低下します——同じ 7 分間のウィンドウ内で同じホスト/ドメイン/local_id の組み合わせから生成された UUID は一意でない場合があります。

ローカルドメイン値

local_domain バイトは UUID に埋め込まれたローカル識別子の種類を指定します:

0POSIX_UID
POSIX ユーザー ID——<code>/etc/passwd</code> からの数値 UID、<code>os.getuid()</code> で取得可能
1POSIX_GID
POSIX グループ ID——<code>/etc/group</code> からの数値 GID、<code>os.getgid()</code> で取得可能
2ORG
組織——カスタム 32 ビット組織識別子;セマンティクスはアプリケーション定義

ドメイン値は DCE 仕様で定義されています。値 3–255 は予約済みです。実際には、実際の UUID v2 値で一般的に見られるのはドメイン 0(人物/UID)のみです。

UUID v2 がほとんど使用されない理由

3 つの特性が UUID v2 を最新のほとんどのアプリケーションで非実用的にします:

粗いタイムスタンプ解像度

タイムスタンプは 28 ビットに切り詰められます(約 7.2 分の粒度)。そのウィンドウ内では、同じ local_id とドメインを持つ同じホスト上の UUID は一意ではありません——仕様は clock_seq フィールドを使用してそれらを区別し、7 分間のウィンドウあたり 64 値に一意性を制限します。

標準ライブラリのサポートなし

UUID v1 および v4 とは異なり、UUID v2 はほとんどの UUID ライブラリでサポートされていません。uuid npm パッケージ、Python の uuid モジュール、Java の java.util.UUID はすべて v2 を省略しています。カスタム実装が必要です。

POSIX 固有のセマンティクス

ローカルドメインの概念(UID/GID)は本質的に POSIX 固有であり、POSIX ユーザー ID の概念が存在しない Windows、組み込みシステム、またはクラウド環境では意味を持ちません。

Warning:新しいプロジェクトで UUID v2 を使用しないでください。このフォーマットは汎用の一意 ID に対して UUID v4 または v7 に比べて何の優位性も提供しません。レガシーシステムで UUID v2 に遭遇した場合は、このツールを使用してフィールドをデコードしてください。新規開発には UUID v4 を使用してください。

歴史的背景

UUID v2 は 1990 年代初頭に Open Software Foundation の Distributed Computing Environment(DCE/RPC)の一部として定義されました。目標は認可コンテキストを持つ UUID を作成することでした——具体的には、RPC サーバーが別の認証ステップなしに呼び出しユーザーを識別できるようにすることです。

DCE セキュリティモデルは、すべてのノードが共有の UID/GID 名前空間に参加する同質の POSIX 環境を想定していました。埋め込まれた UID により、サーバーはディレクトリサービスへのラウンドトリップなしにアクセス制御リストを迅速に確認できます。

  • インターネットが同質の POSIX 環境から異質なクラウドアーキテクチャへ移行した
  • 現代の認証は識別子に埋め込まれた UID ではなくトークン(JWT、OAuth)を使用する
  • UUID v4(完全ランダム)と UUID v7(時間順)が一意識別子の実際のユースケースをカバーする
  • DCE/RPC 自体が広く使用されなくなった

RFC 4122(2005 年)は DCE 仕様への参照によって UUID v2 を含みましたが、詳細な生成アルゴリズムを意図的に省略しました——それが IETF ではなく DCE によって定義されたことを指摘しながら。

UUID 標準を更新した RFC 9562(2024 年)は歴史的な完全性のために UUID v2 を保持しましたが、その POSIX 固有の性質と IETF 標準での完全な生成アルゴリズムの欠如を引き続き指摘しました。

UUID v2 vs UUID v1

UUID v2 は UUID v1 から派生しています。比較を示します:

側面UUID v1UUID v2
タイムスタンプビット数60 ビット(〜100 ナノ秒精度)28 ビット(〜7.2 分精度)
ローカル識別子なし32 ビット POSIX UID/GID
ローカルドメイン存在しない0=UID、1=GID、2=組織
ノードフィールドMAC アドレスMAC アドレス
ライブラリサポート広くサポートされているほとんどサポートされていない
標準RFC 4122 / RFC 9562DCE 仕様(RFC 4122 で参照)
実際の用途レガシータイムスタンプ順 ID(Cassandra)DCE セキュリティコンテキストのみ

UUID v2 は汎用用途で UUID v1 に対して何の優位性も提供せず、ほとんどの面で厳密に劣っています。新規開発で UUID v2 を選択する理由はありません。

コード例

UUID v2 は標準ライブラリでネイティブサポートがありません。次の例は UUID v2 値の操作方法を示します:

Python——手動実装

Python
import uuid, struct, time

def uuid_v2(local_id: int, local_domain: int = 0) -> str:
    """
    Generate a DCE Security UUID (v2).
    local_domain: 0 = POSIX UID, 1 = POSIX GID, 2 = Org
    local_id: 32-bit unsigned integer (e.g. os.getuid())
    """
    # Get a v1 UUID for the time and node fields
    v1 = uuid.uuid1()
    fields = list(v1.fields)  # [time_low, time_mid, time_hi_version, clock_seq_hi_variant, clock_seq_low, node]

    # Replace time_low with local_id
    fields[0] = local_id & 0xFFFFFFFF

    # Replace version nibble: clear lower 12 bits of time_hi, set version 2
    fields[2] = (fields[2] & 0x0FFF) | 0x2000

    # Replace clock_seq_low with local_domain
    fields[4] = local_domain & 0xFF

    return str(uuid.UUID(fields=tuple(fields)))


import os
print(uuid_v2(os.getuid(), local_domain=0))   # POSIX UID
print(uuid_v2(os.getgid(), local_domain=1))   # POSIX GID

Go——注意

Go
// The standard "github.com/google/uuid" package does NOT support v2.
// You would need to implement it manually, similar to the Python example above.
// Most Go developers use v4 or v7 for new projects.
import "github.com/google/uuid"

v4 := uuid.New()          // v4 — recommended for most use cases
v7, _ := uuid.NewV7()     // v7 — time-ordered, ideal for database primary keys

JavaScript——フィールドの抽出

既存の UUID v2 文字列から local_id とドメインを抽出するには:

JavaScript
// Extracting fields from a UUID v2 string
const uuidStr = '000003e8-1234-2abc-8200-a1b2c3d4e5f6'
//               ^^^^^^^^ ^^^^ ^    ^^
//               local_id      ver  variant+clockSeqHi
//                                  ^^ = local_domain (00 = POSIX UID)

const parts = uuidStr.split('-')

const localId     = parseInt(parts[0], 16)       // → 1000 (0x3e8)
const version     = parseInt(parts[2][0], 16)    // → 2
const localDomain = parseInt(parts[3].slice(2), 16) // low byte of octet pair

const DOMAIN_NAMES = ['POSIX UID', 'POSIX GID', 'Org']
console.log(`Local ID: ${localId}`)                       // Local ID: 1000
console.log(`Version:  ${version}`)                       // Version:  2
console.log(`Domain:   ${DOMAIN_NAMES[localDomain]}`)     // Domain:   POSIX UID
Note:google/uuid Go パッケージは uuid.NewDCEGroup()uuid.NewDCEPerson() を通じて UUID v2 生成をサポートしています——これをサポートする数少ないメインストリームライブラリの 1 つです。

よくある質問

JavaScript で UUID v2 を生成できますか?
標準ライブラリは JavaScript での UUID v2 生成をサポートしていません。手動でバイトを構築する必要があります:UUID v1 を取り、time_low フィールド(バイト 0–3)をローカル識別子に置き換え、バイト 9 をドメイン値に設定し、バージョンニブルを 2 に設定します。このツールは UUID v2 を生成しません——デコードするだけです。
local_id フィールドには何が含まれますか?
local_id は 32 ビットの符号なし整数で、その意味は local_domain バイトによって異なります。ドメイン 0 の場合、プロセスを実行しているユーザーの POSIX UID です(例:Linux システムの最初の非 root ユーザーは 1000)。ドメイン 1 の場合は POSIX GID です。ドメイン 2 の場合、意味はアプリケーション定義です。
UUID v2 のタイムスタンプは信頼できますか?
粗い指標としてのみです。60 ビットの UUID v1 タイムスタンプのうち 28 ビットしか保持されないため、実効精度は約 7.2 分です。おおよその生成時刻をデコードできますが、正確ではありません。7 分間のウィンドウ内で、同じ local_id とドメインを持つ同じホストからの複数の UUID v2 値は同一のタイムスタンプを持ちます。
まだ UUID v2 を使用しているシステムはありますか?
UUID v2 は主に 1990 年代のレガシー DCE/RPC システム、一部のバージョンの Microsoft DCOM(DCE/RPC に基づく)、および古い分散コンピューティングミドルウェアで見られます。現代のシステムはほぼ普遍的に UUID v4 または v7 を使用します。
なぜ RFC 4122 に UUID v2 アルゴリズムが含まれていないのですか?
RFC 4122 は UUID v2 生成アルゴリズムが IETF ではなく DCE 仕様によって定義されていることを明示的に述べています。IETF は DCE 仕様に対して権限を持たないため、参照のみを含めました。これが、RFC 4122 に従うほとんどの UUID ライブラリが UUID v2 サポートを省略している理由です。
UUID v2 は GUID と同じですか?
いいえ。GUID(Globally Unique Identifier)は UUID 標準の Microsoft の実装です。Microsoft COM は内部で UUID v1 および v4 GUID を使用します。UUID v2 と Windows GUID インフラストラクチャはどちらも同じ DCE/RPC ルーツから派生していますが、UUID v2 は Windows GUID インフラストラクチャによって使用されていません。