UUIDデコーダー

Decode and inspect UUID structure, version, and embedded data

サンプルを試す

UUID 入力

上に UUID を貼り付けて検査してください

UUID の構造

UUID(Universally Unique Identifier)は 128 ビットの値で、32 桁の 16 進数がハイフンで 5 つのグループに分割されて表されます:

フォーマット
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
xxxxxxxx (8)8 桁の 16 進数——32 ビット
xxxx (4)4 桁の 16 進数——16 ビット
Mxxx (4)4 桁の 16 進数——16 ビット。最初の数字 M が UUID バージョン(1–8)をエンコードします。
Nxxx (4)4 桁の 16 進数——16 ビット。最初の数字 N が UUID バリアント(RFC 4122、NCS、Microsoft、または予約済み)をエンコードします。
xxxxxxxxxxxx (12)12 桁の 16 進数——48 ビット

バージョンバリアントは、すべての UUID に必ず存在することが保証された 2 つのフィールドです。その他すべてのフィールドはバージョンによって異なります。

バージョンフィールド

バージョンニブルは 3 番目のグループの最初の 16 進数字(完全な文字列の位置 14)です。識別子を生成するために使用された UUID バージョンを識別します。

JavaScript
const hex = uuid.replace(/-/g, '')
const version = parseInt(hex[12], 16)  // single hex digit → 1, 2, 3, 4, 5, 6, 7, or 8

バージョン 7(UUID v7)は RFC 9562(2024 年)で導入された最新の広く使用されているバージョンです。ソート可能性のために上位ビットに Unix ミリ秒タイムスタンプをエンコードします。

バリアントフィールド

バリアントは 4 番目のグループの最初のバイトの上位ビットにエンコードされています。UUID が使用するレイアウトとバイト順序の規則を識別します。

上位ビット最初の 16 進数字の範囲バリアント説明
0xxx xxxx0x00–0x7FNCS 後方互換性レガシーネットワークコンピューティングシステム(NCS)UUID。後方互換性のために予約済み。
10xx xxxx0x80–0xBFRFC 4122 / RFC 9562標準 RFC 4122 / RFC 9562 UUID バリアント。すべての現代の UUID バージョン(v1–v8)で使用されます。
110x xxxx0xC0–0xDFMicrosoft 後方互換性異なるバイト順を持つレガシー Microsoft COM/DCOM GUID。Windows COM コンポーネントでまだ見られます。
111x xxxx0xE0–0xFF予約済み将来の定義のために予約済み。現在の UUID バージョンでは使用されていません。

実際には、遭遇するほぼすべてのUUIDはRFC 4122 / RFC 9562バリアント(10xx xxxxビットパターン、第4グループの最初のバイトが0x80–0xBFの範囲)を使用しています。NCS、Microsoft COM、およびReservedバリアントは、現代のシステムではほとんど見られないレガシー形式です。

UUID バージョンリファレンス

RFC 4122 はバージョン 1–5 を定義しました。RFC 9562(2024 年)はバージョン 6、7、8 を追加しました:

バージョン名前標準説明
v1時間ベースRFC 4122タイムスタンプ(グレゴリオ暦エポック、100 ナノ秒精度)+ MAC アドレス。ホストごとに順次ですが、ホスト ID を漏洩します。
v2DCE セキュリティRFC 4122time_low フィールドが POSIX UID/GID に置き換えられた UUID v1 に基づきます。レガシー DCE/RPC システム以外ではほとんど使用されません。
v3名前ベース MD5RFC 4122決定論的:名前空間 UUID + 名前文字列の MD5 ハッシュ。同じ入力は常に同じ UUID を生成します。v5 を優先してください。
v4ランダムRFC 4122122 ビットの暗号学的に安全なランダム性。最も一般的な汎用 UUID バージョン。
v5名前ベース SHA-1RFC 4122v3 と同様ですが SHA-1 を使用します。MD5 より衝突耐性が高いです。新しい名前ベース UUID には v3 より優先してください。
v6再順序付きタイムRFC 9562UUID v1 のタイムスタンプフィールドを再順序付けして UUID が時系列でソート可能になります。RFC 9562 で定義されています。
v7Unix タイムRFC 9562上位ビットの 48 ビット Unix ミリ秒タイムスタンプ + ランダムデータ。ソート可能で B ツリーインデックスフレンドリー。新しい時間順 ID に優先してください。
v8カスタムRFC 9562自由形式:バージョンとバリアント以外のすべてのビットがアプリケーション定義。生成アルゴリズムは指定されていません。

UUID v1 タイムスタンプのデコード

UUID v1 は 60 ビットのグレゴリオ暦タイムスタンプ(1582 年 10 月 15 日からの 100 ナノ秒間隔)を 3 つのフィールドに分割して埋め込みます:time_low(ビット 0–31)、time_mid(ビット 32–47)、time_hi(ビット 48–59)。このツールはそれらを再組み立てして標準 UTC 日付に変換します。

JavaScript
// UUID v1: 6ba7b810-9dad-11d1-80b4-00c04fd430c8
//           ^^^^^^^^ ^^^^ ^^^^ ^^^^^ ^^^^^^^^^^^^
//           time-low  mid  hi  clk   node (MAC)
//                          ^
//                          version nibble (1)

const hex = '6ba7b8109dad11d180b400c04fd430c8'

const tLow = parseInt(hex.slice(0, 8),  16)  // 0x6ba7b810
const tMid = parseInt(hex.slice(8, 12), 16)  // 0x9dad
const tHi  = parseInt(hex.slice(13, 16), 16) // 0x1d1 (skip version nibble at index 12)

// Reconstruct 60-bit timestamp (100-ns intervals since Oct 15, 1582)
const t = (BigInt(tHi) << 48n) | (BigInt(tMid) << 32n) | BigInt(tLow)

// Subtract Gregorian offset (Oct 15, 1582 → Jan 1, 1970 in 100-ns units)
const GREGORIAN_OFFSET = 122192928000000000n
const unixMs = (t - GREGORIAN_OFFSET) / 10000n

console.log(new Date(Number(unixMs)).toISOString())
// → 1998-02-04T22:13:53.578Z
Note:クロックシーケンスフィールド(14 ビット)はクロックが後退するときに重複を防ぎます。ノードフィールド(48 ビット)は通常、生成ホストの MAC アドレスです。

UUID v1 は機密として扱うべきです:埋め込まれた MAC アドレスと正確なタイムスタンプは生成マシンと生成時刻の両方を識別できます。

UUID v7 タイムスタンプのデコード

UUID v7 は最初の 48 ビット(最初のグループ + 2 番目のグループの最初の 4 桁)に 48 ビットの Unix ミリ秒タイムスタンプを埋め込みます。このツールはそれらのビットを読み取り、ミリ秒精度で UTC 日付に変換します。

JavaScript
// UUID v7: 018e4bc8-1000-7000-8000-000000000001
//           ^^^^^^^^^^^^
//           48-bit Unix ms timestamp

const hex = '018e4bc8100070008000000000000001'

// First 48 bits (12 hex chars) = Unix timestamp in milliseconds
const ms = parseInt(hex.slice(0, 12), 16)  // 0x018e4bc81000

console.log(new Date(ms).toISOString())
// → 2024-03-11T…Z

// Everything after byte 6 is random (except version/variant bits)

UUID v1 とは異なり、UUID v7 タイムスタンプは馴染みのある Unix エポック(1970 年 1 月 1 日)を使用し、ホスト情報を埋め込みません。残りの 74 ビットはランダムです。

このツールが UUID バージョンとバリアントを検出する方法

デコーダーは標準 UUID 文字列の位置 14(バージョンニブル)と位置 19(バリアントニブル)を読み取ります。外部の状態やコンテキストは不要です——すべての情報が UUID 文字列に自己完結しています。

JavaScript
// Detect UUID version from the 13th hex character (index 12)
function uuidVersion(uuid) {
  const clean = uuid.replace(/-/g, '')
  return parseInt(clean[12], 16)
}

uuidVersion('550e8400-e29b-41d4-a716-446655440000') // → 4
uuidVersion('018e4bc8-1000-7000-8000-000000000001') // → 7
uuidVersion('6ba7b810-9dad-11d1-80b4-00c04fd430c8') // → 1

// Detect variant from the 17th hex character (index 16, first char of 4th group)
function uuidVariant(uuid) {
  const clean = uuid.replace(/-/g, '')
  const b = parseInt(clean[16], 16)
  if ((b & 0x8) === 0)      return 'NCS'
  if ((b & 0xC) === 0x8)    return 'RFC 4122'
  if ((b & 0xE) === 0xC)    return 'Microsoft'
  return 'Reserved'
}

特殊な UUID

Nil UUID

Nil UUID 00000000-0000-0000-0000-000000000000 はすべてゼロです。RFC 4122 によって「UUID なし」を意味するセンチネル値として定義されています——null に似ています。有効に生成された UUID ではありません。

Max UUID

Max UUID ffffffff-ffff-ffff-ffff-ffffffffffff はすべて 1(すべてのバイトが 0xFF)です。RFC 9562 で定義され、Nil UUID の補数で、最大のセンチネル値として機能します。

よくある質問

UUID のバージョンをどうやって判断しますか?
標準 UUID 文字列の位置 14(3 番目のハイフン区切りグループの最初の文字)を見てください。その 1 桁の 16 進数がバージョン番号です:1、2、3、4、5、6、7、または 8。UUID をこのツールに貼り付けるとバージョンがデコードされます。
UUID をデコードして元のデータを復元できますか?
バージョンによります。UUID v1 と v7 には完全に復元できるタイムスタンプが埋め込まれています。UUID v1 には MAC アドレスも埋め込まれています。UUID v3 と v5 は一方向ハッシュです——UUID から元の名前を復元することはできません。UUID v4 は純粋にランダムです——復元するものは何もありません。
UUID の「バリアント」とは何を意味しますか?
バリアントフィールドは UUID のバイトレイアウトと解釈の規則を識別します。遭遇するほぼすべての UUID は RFC 4122 バリアント(上位ビット 10)を持ち、位置 19 の 16 進数字 8、9、a、または b としてエンコードされます。他のバリアント(NCS、Microsoft)は 1990 年代のレガシーフォーマットです。
なぜ一部の UUID は他のものと異なって見えますか?
視覚的な違いはバージョンニブル(位置 14)とバリアントニブル(位置 19)にあります。例えば、UUID v4 は位置 14 に常に 4 があり、UUID v7 は常に 7 があります。これらの制約内で、残りの数字はバージョンに応じてランダムまたはタイムスタンプ由来です。
Nil UUID は空の UUID と同じですか?
概念的にはそうです——Nil UUID(すべてゼロ)は null に似て UUID の不在を表すために使用されます。ランダムに生成された UUID ではなく、本物の識別子として保存すべきではありません。一部のシステムはデフォルトまたはプレースホルダー値として使用します。
UUID は無効になることはありますか?
UUID は構文的に有効(正しいフォーマット)でも意味的に珍しい場合があります——例えば、バージョンニブルが 0 またはバリアントが 11x(予約済み)の場合。Nil UUID と Max UUID は構文的に有効ですが、センチネル値です。このツールは存在するバージョンとバリアントニブルを表示し、認識されないバージョンにフラグを立てます。
UUID と GUID の違いは何ですか?
GUID(Globally Unique Identifier)は同じ概念の Microsoft の名前です。GUID は同じ RFC 4122 128 ビットフォーマットに従います。唯一の実際の違いは、レガシーの Microsoft GUID が RFC 4122 バリアントではなく Microsoft バリアント(上位ビット 110)を使用する場合があることです——これはバイナリ表現でのバイト順に影響します。テキスト表現は同一です。