UUID生成
データベースの主キー、API のテスト用 ID、設定ファイルの識別子に。必要な数だけ一度に生成します。
🔒 入力内容はお使いのブラウザ内だけで処理され、サーバーには送信されません。
UUID を解析する(種類と v7 の時刻を調べる)
使い方
- 種類(v4 / v7 / NIL / Max)と個数を選びます。ページを開いた時点で v4 を5個生成しています。
- 必要に応じて大文字、ハイフンなし、波括弧、クォートの各オプションと、出力形式(1行ずつ、カンマ区切り、JSON 配列、SQL の IN 句)を選びます。選び直すと結果も更新されます。
- 「生成する」を押すと新しい UUID に入れ替わります。「結果をコピー」または「ダウンロード」で取り出します。
- 手元の UUID の種類や、v7 に含まれる時刻を調べたいときは、下の「UUID を解析する」に貼り付けてください。
仕様
UUID は 128 ビットの識別子で、16進数 32 桁を 8-4-4-4-12 に区切って表記します。3つ目のブロックの先頭の文字がバージョンです。
| 種類 | 内容 |
|---|---|
| v4 | 122 ビットが乱数です。ブラウザの crypto.randomUUID(なければ crypto.getRandomValues)で生成します |
| v7 | 先頭 48 ビットが生成時刻(Unix 時間のミリ秒)、残りが乱数です。2024年に RFC 9562 で定められました。文字列として並べ替えると生成順になります |
| NIL | 00000000-0000-0000-0000-000000000000。「値がない」ことを表すために使います |
| Max | ffffffff-ffff-ffff-ffff-ffffffffffff。範囲の上限などに使う特殊な値です |
大文字は a〜f を A〜F にします(規格上は小文字が標準で、比較では区別しません)。波括弧 {…} は Windows のレジストリや COM で使う GUID 表記です。
v4 と v7 の違い
v4 は完全にランダムなので、ID から何の情報も読み取れません。一方、データベースの主キーにすると挿入位置がばらばらになり、件数が増えると索引(インデックス)の更新が重くなることがあります。
v7 は先頭が時刻なので、新しい ID ほど後ろに並びます。索引の末尾に追加されていくため主キーに向いており、作成日時の列がなくても順番が分かります。その代わり ID から生成時刻が分かるため、作成時刻を知られたくない場面(公開 URL に使う ID など)では v4 を選んでください。同じミリ秒内に複数の v7 を生成した場合、このツールは 12 ビットの連番で順番を保ちます。
こんな時に
- テスト用のデータベースに入れるダミーのレコード ID をまとめて作る。
- API のリクエスト ID や、ファイルのアップロード先の一意なフォルダ名を決める。
- 設定ファイルやマニフェストに必要な GUID を1つ作る。
- v7 の UUID をログから拾って、いつ作られたものか確かめる。
よくある質問
v4 と v7 はどちらを使えばよいですか?
特に理由がなければ v4 で問題ありません。データベースの主キーのように、作成順に並ぶと都合がよい(索引の性能が上がる、並べ替えに使える)場合は v7 が向いています。v7 は先頭に生成時刻が入るため、ID からおおよその作成日時が分かる点には注意してください。
UUID と GUID は同じものですか?
同じ形式です。GUID は Microsoft 製品での呼び方で、Windows や .NET の文書に多く出てきます。波括弧付きの {xxxxxxxx-...} は Windows のレジストリや COM で使われる表記で、このツールの「波括弧で囲む」で出力できます。
生成した UUID が他と重複する心配はありますか?
v4 は122ビットの乱数なので、現実的には重複しません(10億個作っても衝突確率は10兆分の1未満)。v7 も74ビットの乱数と時刻を組み合わせます。乱数はブラウザの暗号用乱数(crypto.randomUUID / getRandomValues)を使っています。
NIL UUID は何に使いますか?
すべて 0 の 00000000-0000-0000-0000-000000000000 です。「値がない」ことを表す初期値やダミーとして、UUID 型の列に入れる用途があります。識別子としては使えません。