データベースのキー、分散サービス、テストデータ、アプリの識別子に使う UUID を生成します。入力: 生成する個数（1〜100）と大文字・小文字の指定。出力: 標準形式の UUID 文字列。
生成する個数（1〜100）と大文字・小文字を選ぶと、サーバー側で生成した一覧が1行に1つずつ返ります。値は 128 ビットのバージョン 4 UUID で、8-4-4-4-12 の標準形式のまま、テストデータ、シード値、データベースのキーに貼り付けられます。
バージョン 4 はランダムなビットで構成され、タイムスタンプ・MAC アドレス・名前のハッシュを含みません。どのマシンでいつ作られたかが値から分からないため、意味を持たない識別子として使えます。その代わり、作成日時で並べ替える用途には向きません。
UUID は 128 ビットを 32 桁の16進数で表し、ハイフンで 5 つのグループに分けます。バージョン 4 では 122 ビットがランダムで、3 番目のグループの先頭 4 ビットはバージョンを示す 4 に、4 番目のグループの上位 2 ビットは RFC 4122 のバリアントを示す 10 に固定されます。
この 6 ビットが固定されるため、正しい v4 は単なる 32 桁のランダムな16進数ではありません。バージョンを検査する厳密なバリデーターやライブラリは、ハッシュや連番をそのまま16進数にした値を不正として弾きます。
122 ビットがランダムなので取り得る値は約 5.3×10^36 通りあり、現実的な規模では同じ値に当たる確率は無視できます。さらにこのページは同じ送信内の重複を検査し、重複した値は再生成するため、100 個の一括生成でも重複は含まれません。
実務で問題になるのはデータ側の衝突です。データベースの照合順序によっては、大文字と小文字を別の値として扱うことがあり、同じ UUID が 2 行に分かれてしまいます。保存する形式を小文字などに統一するか、バイナリ列に格納してください。
順序が重要でなければ v4 はよい主キーです。16 バイトの推測できない値になります。インデックスの局所性が問題になる（挿入位置が木全体に散る）場合は、並べ替え可能なタイムスタンプを持つ UUID v7 や ULID を検討してください。保存は CHAR(36) が読みやすく、BINARY(16) は容量を節約できます。
秘密情報には使わないでください。値はサーバーで生成されページに返るため、公開の識別子として扱います。セッショントークンや鍵が必要な場合は、自前のバックエンドで暗号学的に生成し、保管はハッシュのみにします。
ランダムです。バージョン 4 はバージョン 1 と違い、タイムスタンプも MAC アドレスも名前も符号化しません。122 ビットのランダム値と、バージョンとバリアントを示す 6 ビットの固定値だけで構成されます。
はい。RFC 4122 は UUID の大文字・小文字を区別しないため、0BC4… と 0bc4… は同じ値です。データベースや比較ではどちらかの形式に統一してください。特に照合順序がバイナリの列では重要です。
1回の送信で 1〜100 個です。フォームを書き換えて範囲外の値を送っても、サーバー側で補正されます。0・負の数・数値でない文字列は 1 に、100 を超える値は 100 になります。
生成はリクエストごとにサーバー側で行われ、最初の表示でも既定で 1 個の UUID が付きます。キャッシュや事前生成された値はないため、再読み込みすると別の識別子になります。
はい、よくある用途です。重複せず、内部情報も漏らしません。インデックスへの挿入順が問題になる場合は UUID v7 や ULID を、容量が気になる場合は 36 文字の文字列ではなく BINARY(16) を検討してください。
このツールの想定外です。値はサーバーで生成されてページに表示されるため、公開の識別子として扱ってください。トークンや鍵は自前のバックエンドで生成し、ハッシュとして保管します。