UUID 生成(v4・v7)
最大 1000 件の UUID をまとめて生成します。v4 は完全にランダム、v7 はタイムスタンプを含むため生成順に並び、データベースのインデックスに優しい形式です。
v4:ランダムで、迷ったらこれ
バージョン 4 の UUID はブラウザの暗号論的乱数から 122 ビットのランダム性を得ます。独立したシステム間でも衝突の確率は無視できるほど小さく、複数の場所で ID を生成する場合の既定の選択肢になっています。
v7:ソート可能で、データベース向き
バージョン 7 の UUID は先頭 48 ビットがミリ秒単位の UNIX タイムスタンプなので、後から生成した ID ほど後ろに並びます。この局所性により B-tree インデックスがコンパクトに保たれ、MySQL や PostgreSQL でランダムな v4 を主キーにしたときの書き込み増幅を避けられます。ID から生成時刻を読めるという利点もあります。
出力先に合わせた書式
大文字・ハイフンなし・波括弧付きは、いずれも同じ 128 ビット値の書き方の違いです。Windows のツールや .NET の `Guid` は波括弧付きを好み、データベースによっては 32 文字の 16 進形式で保存します。必要な形式を選んでまとめてコピーしてください。
よくある質問
サーバーで生成しているのですか?
いいえ。貼り付けた内容がブラウザの外に出ることはありません。ページは小さな JavaScript を読み込むだけで、計算はすべて手元の端末で行われます。送信先のサーバーそのものが存在しません。 ID はブラウザ自身の暗号論的乱数生成器から作られるため、送信も記録もされず、他の誰かと重複することもありません。
本当に一意ですか?
数学的な保証はありませんが、実用上は安全です。122 ビットのランダム性があるため、衝突が現実味を帯びるには数十億個の v4 を生成する必要があります。現実的な用途では一意として扱って問題ありません。
主キーには v4 と v7 のどちらが良いですか?
v7 をおすすめします。ランダムな v4 は挿入位置がインデックス全体に散らばるため B-tree が断片化し、大きなテーブルでは書き込み性能が落ちます。v7 なら新しい行がまとまります。生成時刻を ID から推測されたくない場合のみ v4 を選んでください。
UUID は秘密情報になりますか?
認証情報ではなく識別子として扱ってください。v4 は推測が困難なため非公開 URL には使えますが、ログ・リファラ・ブラウザ履歴に残る可能性があります。本当に保護が必要なものには認証の仕組みが必要です。