分析と広告のためのCookie
分析と広告のためにCookieを使っており、どちらもGoogleに送られます。拒否しても、目に見える動作は何も変わりません。プライバシーポリシーを読む
ボタンを押すと、頼んだ数だけバージョン 4 の UUID が出てきます。乱数のビットは、ブラウザーに組み込まれた暗号乱数生成器から来ます。`Math.random()` ではありません。その差は見た目より重く、予測可能な生成器は、どんな検証も通り抜けて、しかも誰かに当てられる識別子を作ります。
処理される場所
ファイルがないので、何もアップロードされません。計算はこのページの中で行われます。
順番待ちもアカウントもなし
お使いの機械の速さで答え、あなたが誰かを尋ねることはありません。
何度でも
回数は数えず、上限もありません。もう一度答えることに費用はかからないからです。
`crypto.getRandomValues` を使います。ブラウザーの暗号乱数生成器で、エントロピーをオペレーティングシステムから取ります。`Math.random()` ではありません。あちらの出力は内部状態から再現でき、当てられては困る識別子を作らせてはならないものです。
違いは結果には現れません。どちらも正しい見た目の文字列を出し、どちらも形式の検証を通ります。気づくのは誰かが次の識別子を予測した日で、そのときにはもう本番に入っています。ブラウザーが暗号乱数生成器を提供していない場合、ここでは弱いほうへ切り替えずに処理を止めます。
UUID は 128 ビットですが、バージョン 4 ではそのうち 4 ビットがバージョン番号に、2 ビットがバリアントに固定されています。残る 122 ビットが乱数で、それでもなお、何十億個生成しても衝突の確率は無視できます。
この余裕があるからこそ、調整なしの分散生成ができます。互いに口をきかない 2 つのサービスが、何も取り決めずに同時に識別子を作れる。UUID が存在する理由である性質であり、複数の機械が書き込む瞬間に自動採番が使えなくなる理由でもあります。
バージョンは 3 つめのグループの先頭、つまり 13 桁目の 16 進数字です。ここでは常に `4` です。バリアントは 4 つめのグループの先頭で、`8`、`9`、`a`、`b` のいずれかでなければなりません。この 4 つの数字は先頭ビット `10` を共有し、それが RFC 4122 が自らのために確保したバリアントだからです。
目視で確認でき、自作の生成器を見抜く最速の方法です。16 進 32 桁をただ乱数で並べ、この 2 か所を固定しない人は、UUID に見えて形式上はそうでない識別子を作ります。そしてそれは、何かが本気で検証する日まで何年も動き続けます。
バージョン 1 の UUID は、100 ナノ秒精度の生成時刻と、伝統的にはネットワークカードの MAC アドレスを含みます。どちらも識別子を持つ人が復元でき、外から見えるデータベースのキーが、その機械と時刻についての手がかりになります。
机上の懸念ではありません。1999 年に Melissa ウイルスの作者が特定された経路がこれでした。Word が文書の識別子に MAC アドレスを書いていたからです。識別子が外から見える場所では、バージョン 4 が正しい選択です。
バージョン 7 は先頭にミリ秒のタイムスタンプを置き、残りを乱数で埋めます。識別子が自身の値で時間順に並びます。多くのチームが UUID を主キーとして避けてきた問題を、これが解決します。
理由は索引です。乱数のキーは B ツリーの中の絶えず変わる位置に書き込み、ページを分割してキャッシュを無駄にします。大きなテーブルでは測定できるほど書き込み性能を損ないます。増加するキーは常に末尾へ書きます。代償は、生成時刻がまた読めるようになることです。
ここでは小文字で、飾りなしで生成します。仕様が生成時に求める形です。読むときは大文字も受け入れる必要があり、実際 .NET と多くの Windows の道具は伝統的にそう書きます。
2 種類の包みも出回っています。波かっこは Windows のレジストリの記法から、`urn:uuid:` の接頭辞は URN の名前空間から来ています。どちらも識別子の一部ではありません。自分で比較する人は小文字に正規化し、包みを外すべきです。さもないと、同じ 2 つの識別子が書き方の違いで比較に失敗します。
バージョン 4 の識別子は実用上当てられません。そこからアクセストークンとして使うまでの距離は 1 歩で、その 1 歩は踏まれすぎています。URL に UUID が入っていることだけが保護になっている「非公開」リンクです。
問題はエントロピーではなく、その URL がどこへ行き着くかです。履歴、次のクリックのリファラーヘッダー、プロキシのログ、誰かが転送するメッセージ。トークンは失効し、無効化できるべきです。UUID はそのどちらもしません。
UUID を API で返すサービスがあります。それを使うということは、あなたのデータベースに入れる識別子そのものを、ほかの誰かが見たということです。壊滅的ではありませんが、必要でもありません。生成は数行のローカルな処理です。
ここではあなたのタブの中で、ブラウザーの暗号機能を使って行われます。関与するリクエストは 1 本もないので、ページを読み込んだあとは接続がなくても同じように動きます。新幹線の中でも、社内プロキシの背後でも、隔離された機械の上でも。
生成したばかりの UUID は個人データを含みません。乱数のビットです。あなたのシステムの中で人と結びついた瞬間に識別子になり、そこから先の扱いは、ほかのどの利用者 ID とも同じになります。
このページが保証するのはその手前です。識別子はあなたの端末で生まれ、途中のどのサービスも通りません。小さく、そして本物の差です。実データの移行のためにまとめて生成するときには特に。
crypto.getRandomValues で生成しています。ブラウザーの暗号乱数生成器で、エントロピーをオペレーティングシステムから取ります。Math.random() ではありません。あちらの出力は内部状態から再現できます。
バージョン 4 は 122 ビットが乱数なので、何十億個生成しても確率は無視できます。調整なしの分散生成を可能にしているのが、まさにこの性質です。
バージョン 1 は生成時刻と、伝統的には機械の MAC アドレスを内部に持つからです。識別子が外から見えるなら、それは外へ出るべきでない情報です。
やめたほうがよいです。エントロピーは足りますが、URL は履歴とリファラーヘッダーとプロキシのログに行き着きます。そして UUID は失効せず、無効化もできません。トークンはその両方をすべきです。
いいえ。ブラウザーの暗号機能を使って、あなたのタブの中で生成されます。リクエストは 1 本も関与しません。ページを読み込んだあとは接続がなくても動きます。