すべての V4 UUID

 (everyuuid.com)
3 ポイント 投稿者 GN⁺ 2024-12-07 | 2件のコメント | WhatsAppで共有
  • everyuuid.com は、数値インデックスと UUID 文字列を並べて表示するシンプルな一覧ページである
  • 各項目は、長い 0 埋めの数字とインデックス、次の行のハイフン付き UUID で構成される
  • UUID 文字列は、3 番目のグループが 4 で始まる V4 UUID 形式に従っており、497dcba3-ecbf-4587-a2dd-5eb0665e6880 のような値が表示される
  • 本文には 生成方式、使い方、API、コードの説明はなく、一覧そのものを閲覧する形式に近い
  • 確認できた範囲は 0 から 49 までで、ページの実質的な情報はタイトルと UUID 一覧に集中している

数字と UUID を並べて表示する構成

  • タイトルは Every UUID V4 である
  • 本文は数値項目と UUID 文字列が繰り返される一覧で構成される
  • 要約された範囲は 0 から 49 までである

項目の表示方法

  • 各項目は 2 行構成である
    • 1 行目: 長い 0 の文字列の後にインデックス番号が付く
    • 2 行目: ハイフンで区切られた UUID 文字列が表示される
  • 冒頭の例は次のとおり
    • 000000000000000000000000000000000000 0
    • 497dcba3-ecbf-4587-a2dd-5eb0665e6880
  • 最後に確認された項目は次のとおり
    • 00000000000000000000000000000000000 49
    • 08716598-71f7-4e8b-9fff-e36d2c5d21fe

説明よりデータ一覧に近いページ

  • UUID 文字列は、ハイフンで区切られた UUID 表記形式を使用している
  • UUID の生成原理、並び順の基準、全体範囲、検索機能、ライセンス、実装方式に関する説明はない
  • 技術解説や利用案内なしに データ一覧のみが提供されている

関連記事

2件のコメント

 
nemorize 2024-12-13

私が思いつける中で、leet speak/hexspeakで最もひどい文はこれです:
fe11a710-babe-4150-ace5-b19b1accd1cc
（はい、これは有効なUUIDです）
（本当にすみません）

おお… 👀
 
GN⁺ 2024-12-07
Hacker News の意見

  • 検索が実際に動作する点がいちばん印象的。優れたマジックがたいていそうであるように、説明を聞くととても単純に見えもする
    気になる人向けのプロジェクトの仕組み解説記事: https://eieio.games/blog/writing-down-every-uuid/
    最初は正確な UUID だけを検索してみたが、全文検索まで対応していると知ってさらに驚いた

    • そのトリックがマジックのように感じられたなら本当にうれしい。これが可能だと気づいたとき、自分も驚いて楽しかったが、他の人も同じ気持ちになるかは確信がなかった
      もちろん、これほど多くの実用性を提供できることも誇らしい。ついに必要にぴったり合う UUID を見つけて使えるようになった
    • Teller が言った「マジックとは、ときに誰かが合理的に期待しうるよりもはるかに多くの時間を、あることに費やしただけのものだ」という観察のよい例
    • 全文検索の説明は、最初に予想していたより少し賢かった。最初は次/前ボタンの検索方向に合う UUID が出るまで生成しているのだと思ったが、実際には可能な結果を複数作って、その中から最良のものを選ぶ方式だった
      検索結果を前後に移動するたびに別の結果が出るのを見てそう推測したが、実際にいくつ生成しているのか気になる
    • 全文検索は最初は順番に検索しているように見えるが、実際にはそうではないので少し混乱する。「next」を何度か押したあと同じ回数だけ「prev」を押しても、必ずしも元の UUID に戻るわけではない
      それでもかなり格好いいトリックに見える
    • 検索方式は、単純なスペルチェッカーを作る一般的なアプローチととても似ている。入力値が与えられると、その入力が含まれうるすべての一致候補を生成する方式
      コーパスから検索するのではなく、入力を使ってコーパスのインデックスを生成するようなもの。ここでは UUID のリストで、スペルチェッカーでは辞書の単語リストにあたる

  • どこかのハッカーがすべての UUIDを流出させたらしい
    自分の UUID が流出リストに含まれているか確認しないと

    • すべての ATM PIN が流出して以来最大のハッキング: https://pastebin.com/SmJRB8eQ
    • これをセキュリティ部門に知らせたら、間違いなくすぐ飛びつきそう
    • 「havemyuuidsbeenpwned.com」サービスに期待
    • 10b82756-f8b4-4fee-a508-adeadbeef5eb
      仕方ない、もうフォーマットする時間だ
    • 今の会社の仕事がこんな状態なので、個人データのセキュリティでこの流出を緩和する時間がまったくない。正式に諦める

  • とても便利。UUID を忘れたら参照することにする。ビットコインの秘密鍵を思い出すときも、このサイトをいつも使っている: https://privatekeys.pw/keys/bitcoin/1

    • ランダムな鍵: 残高 0
      本物の鍵: 残高が今や 0
    • 人々が遊びで弱い BTC 鍵を作るとは知らなかった。一部はボットをおびき寄せる罠としても使われていそう
    • 実際の秘密鍵を検索して、潜在的に漏らしてしまう人もきっといると思う
    • これも参考: https://keys.lol/

  • ときどき UUID を生成しておいてどこにも使わないと、なんとなく申し訳ない気分になる。無駄にしたように感じる

    • そう感じるのはあなただけではない: https://wasteaguid.info/
    • UUID は十分にたくさんあるので、どこかに記録しないことで、むしろもっと希少な資源を節約しているともいえる
    • 生成しなかったために生まれることすらできなかった UUID たちについては、どれくらい申し訳なく思う？
    • 会社のクリックストリームデータには event_uuid カラムがあり、UUID、大きな整数、アカウント番号、そのほか10個ほどの識別子を合わせた形になっている
      どのカラムで JOIN すべきか分からないとき、JOIN がとても楽になる
    • 以前、数百万件のテーブルからレコードを1つ選ぶために SELECT TOP 1 ... ORDER BY NEWID() を使ったことがある
      UUID が数百万個生成され、そのうち1つが偶然もっとも低い値として選ばれ、紐づいたレコードが返された。とんでもない無駄だ

  • 「ブラウザは1兆の1兆ピクセルより高いウィンドウをレンダリングしたがらないので、スクロールとレンダリングを自前で処理する必要があった」という部分が面白い。実際にこういうことを試すとかなり期待外れで、1兆ピクセルには遠く及ばない
    5年前 Fastmail で働いていたとき、IE ユーザーの顧客がメールボックスに約20万通のメールを入れたらスクロールバーが壊れたので確認した限界は次の通りで、いくつかは今さっき再確認した
    Firefox は以前、17,895,697ピクセルより大きい値として解釈される宣言を無視していた。今はその地点でクランプするが、3ピクセルほど差があり、正確に何が起きているのかはすぐには分からない
    IE は 10,737,418.23ピクセル以上として解釈される宣言を無視する。WebKit はおよそ 2²⁵、つまり 33,554,432ピクセル付近で値をクランプする
    Chromium は以前のテストでは WebKit と同じだったが、今は約 22,360,882ピクセル付近でクランプする。現在は1.5倍スケールのディスプレイなので 2²⁵ がデバイスピクセルと関係している可能性もあるが、最初にテストしたときは2倍スケールのディスプレイだった気がする
    関連するソースコードリンクとあわせて、より詳しく書いた投稿もある: https://news.ycombinator.com/item?id=34299569

    • これはいい。記事を書きながら、比較的新しいブラウザの最大高さの一覧を探そうとしていた。アップデートでこのコメントにリンクしてもよいか気になる
      また、その数字がどう決まったのか、限界がないと何が壊れ始めるのかもとても気になる。clientHeight 周辺の奇妙な挙動の例が、そのヒントかもしれない
    • 要素の幅にも似たような限界がある。最近、幅を 45678910px に設定しようとして知った: https://thewisenerd.com/works/45678910px.html

  • 新しい npm パッケージ get-uuid を発表したい。内部では everyuuid.com を呼び出し、ランダムな行番号を選んでその UUID を返す

    • 素晴らしいアイデアだ。私もそのパッケージを使う npm パッケージを作って、数字の間の - を取り除いた GUID を返すようにしよう。コード再利用万歳
    • ライブラリの API 互換性 は、壊すのを月5回までにしてくれるとうれしい。それ以上は多すぎる
      それと、君のパッケージが自分の望むことを正確にはしてくれないと気づいて、私がフォークする日も楽しみにしていてほしい
    • AI が美的に見栄えのよい UUID を選んでくれるとさらに良い。望むなら PR を出せる
    • UUID が存在するか確認する関数も追加してくれる？

  • https://libraryofbabel.info/ を思い出す。今は落ちているようなので、Archive を試せる: https://web.archive.org/web/20241112121646/https://libraryof...
    短編 https://en.wikipedia.org/wiki/The_Library_of_Babel に着想を得た面白い実装で、「現在可能なすべての3200文字のページを含んでいる」という。ただし文字セットが限定されていてハイフンがないため、これらの UUID は見つからない

    • Steven L. Peck の A Short Stay in Hell（2009）という変奏もある
      とてつもなく大きな数を理解しているなら、面白くも恐ろしい読み物だ

  • 有効な UUID であるすべての .com ドメインの一覧だと思った。実際にそういうドメインがどれくらいあるのか気になった
    更新: 別のコメントですでに共有されていた: https://news.ycombinator.com/item?id=42342653

  • 圧縮技術が発達しすぎて、今や 340アンデシリオンバイト を超える Web ページを閲覧できる
    本当に驚異的な時代に生きている

    • これは Weissman スコア の最高記録を更新したのはほぼ確実だ
    • 大したことではない。数年前、Cookie Clicker で私のベーカリーはアンデシリオン単位の生産も問題なくこなしていた

  • 1画面を超える分量の内容が一度に入っているのに、スクロール時に数秒のローディングアニメーションが出ない Web サイトだなんて驚きだ
    現代の Web アプリケーション開発者たちがこの技術を何らかの形で活用できるのか気になる

    • 完全に同意する。私もすぐに「わあ、速くて滑らかで反応がいい！」と思った
      コンピュータハードウェアは1995年、つまり30年前より1000倍速くなっているのに、ソフトウェアは肥大化しすぎて今なお遅いというのは馬鹿げている
      関連動画: “Will Software Stop Getting Slower?” Jonathan Blow
      https://www.youtube.com/watch?v=4ka549NNdDk