UUID V4 ทั้งหมด

 (everyuuid.com)
3 คะแนน โดย GN⁺ 2024-12-07 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • everyuuid.com เป็นหน้าเว็บแบบรายการเรียบง่ายที่แสดง ดัชนีตัวเลขและสตริง UUID คู่กัน
  • แต่ละรายการประกอบด้วย ตัวเลขที่เติม 0 ด้านหน้าเป็นจำนวนมาก พร้อมดัชนี และบรรทัดถัดไปเป็น UUID ที่มีเครื่องหมายขีดกลาง
  • สตริง UUID ใช้ รูปแบบ V4 UUID โดยกลุ่มที่สามขึ้นต้นด้วย 4 และมีการแสดงค่าอย่าง 497dcba3-ecbf-4587-a2dd-5eb0665e6880
  • ในเนื้อหาไม่มีคำอธิบายเกี่ยวกับ วิธีสร้าง วิธีใช้งาน API หรือโค้ด ทำให้ลักษณะใกล้เคียงกับการเปิดดูรายการนั้นเอง
  • ช่วงที่ตรวจสอบได้คือ 0 ถึง 49 และข้อมูลหลักของหน้าเน้นที่ชื่อเรื่องกับรายการ UUID

โครงสร้างที่แสดงตัวเลขและ UUID เคียงกัน

  • ชื่อเรื่องคือ Every UUID V4
  • เนื้อหาประกอบด้วยรายการที่ทำซ้ำของตัวเลขและสตริง UUID
  • ช่วงที่สรุปไว้คือ 0 ถึง 49

วิธีการแสดงแต่ละรายการ

  • แต่ละรายการมีโครงสร้างสองบรรทัด
    • บรรทัดแรก: สตริง 0 ยาว ๆ ตามด้วยตัวเลขดัชนี
    • บรรทัดที่สอง: สตริง UUID ที่คั่นด้วยขีดกลาง
  • ตัวอย่างช่วงต้นมีดังนี้
    • 000000000000000000000000000000000000 0
    • 497dcba3-ecbf-4587-a2dd-5eb0665e6880
  • รายการสุดท้ายที่ให้มาคือ
    • 00000000000000000000000000000000000 49
    • 08716598-71f7-4e8b-9fff-e36d2c5d21fe

เป็นหน้าเว็บที่ใกล้เคียงกับรายการข้อมูลมากกว่าคำอธิบาย

  • สตริง UUID ใช้ รูปแบบการเขียน UUID ที่คั่นด้วยขีดกลาง
  • ไม่มีคำอธิบายเกี่ยวกับหลักการสร้าง UUID เกณฑ์การจัดเรียง ช่วงทั้งหมด ฟังก์ชันค้นหา ลิขสิทธิ์ หรือวิธีการติดตั้งใช้งาน
  • มีเพียง รายการข้อมูล โดยไม่มีคำอธิบายเชิงเทคนิคหรือคู่มือการใช้งาน

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
nemorize 2024-12-13

ประโยคที่ชวนขุ่นเคืองที่สุดที่ผมนึกออกได้โดยใช้ leetspeak/hexspeak คือประโยคนี้:
fe11a710-babe-4150-ace5-b19b1accd1cc
(ใช่ มันเป็น UUID ที่ใช้ได้จริง)
(ผมขอโทษจริง ๆ)

โอ้โห... 👀
 
GN⁺ 2024-12-07
ความคิดเห็นบน Hacker News

  • สิ่งที่น่าประทับใจที่สุดคือ การค้นหาใช้งานได้จริง เหมือนมายากลดี ๆ ทั่วไป พอได้ฟังคำอธิบายแล้วก็ดูเรียบง่ายมาก
    บทความอธิบายการทำงานของโปรเจกต์สำหรับคนที่สงสัย: https://eieio.games/blog/writing-down-every-uuid/
    ตอนแรกลองค้นหาเฉพาะ UUID ที่ตรงเป๊ะเท่านั้น แต่พอรู้ว่ารองรับถึงขั้น full-text search ก็ยิ่งทึ่งกว่าเดิม

    • ดีใจจริง ๆ ที่ทริกนั้นให้ความรู้สึกเหมือนมายากล ตอนที่ผมรู้ว่ามันเป็นไปได้ ผมเองก็ทั้งประหลาดใจและสนุก แต่ไม่แน่ใจว่าคนอื่นจะรู้สึกเหมือนกันไหม
      แน่นอนว่าผมภูมิใจด้วยที่มันให้ประโยชน์ใช้งานจริงได้มากขนาดนี้ ในที่สุดก็หา UUID ที่ตรงกับความต้องการมาใช้ได้พอดี
    • เป็นตัวอย่างที่ดีของข้อสังเกตที่ Teller พูดไว้ว่า “บางครั้งมายากลก็เป็นเพียงการที่ใครสักคนใช้เวลากับบางสิ่งมากกว่าที่คนทั่วไปจะคาดหวังอย่างสมเหตุสมผลไปไกลมาก”
    • คำอธิบายเรื่อง full-text search ฉลาดกว่าที่ตอนแรกคาดไว้เล็กน้อย ตอนแรกคิดว่ามันสร้าง UUID ไปเรื่อย ๆ จนกว่าจะเจอตัวที่ตรงกับทิศทางการค้นหาของปุ่ม next/prev แต่จริง ๆ แล้วเป็นวิธีสร้างผลลัพธ์ที่เป็นไปได้หลายรายการ แล้วเลือกตัวที่ดีที่สุดจากในนั้น
      เดาแบบนั้นเพราะทุกครั้งที่เลื่อนไปมาระหว่างผลการค้นหา จะได้ผลลัพธ์ที่ต่างกัน เลยสงสัยว่าจริง ๆ แล้วมันสร้างขึ้นมากี่รายการ
    • full-text search ตอนแรกดูเหมือนค้นหาตามลำดับ แต่จริง ๆ ไม่ใช่ เลยสับสนนิดหน่อย กด “next” ไปหลายครั้งแล้วกด “prev” จำนวนครั้งเท่ากัน ก็ไม่จำเป็นต้องกลับมาที่ UUID เดิม
      ถึงอย่างนั้นก็ดูเป็นทริกที่เจ๋งดี
    • วิธีค้นหานี้คล้ายมากกับแนวทางทั่วไปในการทำตัวตรวจสะกดแบบง่าย ๆ คือเมื่อมีอินพุตเข้ามา ก็สร้างรายการที่อาจตรงกันทั้งหมดซึ่งสามารถมีอินพุตนั้นอยู่ได้
      ไม่ใช่การค้นหาในคลังข้อความ แต่เหมือนใช้ข้อมูลที่ป้อนมาเพื่อสร้างดัชนีของคลังข้อความแทน ในที่นี้คือรายการ UUID ส่วนในตัวตรวจสะกดก็คือรายการคำในพจนานุกรม

  • ดูเหมือนมีแฮ็กเกอร์บางคนทำ UUID ทั้งหมด หลุดออกมา
    ต้องไปเช็กแล้วว่า UUID ของฉันอยู่ในรายชื่อที่หลุดไหม

    • นี่คือการแฮ็กครั้งใหญ่ที่สุดนับตั้งแต่ PIN ของ ATM ทั้งหมดหลุด: https://pastebin.com/SmJRB8eQ
    • ถ้าแจ้งเรื่องนี้ให้ฝ่ายความปลอดภัยรู้ รับรองว่าพวกเขาจะรีบพุ่งเข้ามาจัดการทันที
    • รอใช้บริการ “havemyuuidsbeenpwned.com” อยู่เลย
    • 10b82756-f8b4-4fee-a508-adeadbeef5eb
      ช่วยไม่ได้แฮะ ถึงเวลาฟอร์แมตแล้ว
    • งานบริษัทตอนนี้เป็นแบบนี้อยู่ เลยไม่มีเวลาจะลดผลกระทบจากการรั่วไหลนี้ในด้านความปลอดภัยของข้อมูลส่วนตัวเลย ขอประกาศยอมแพ้อย่างเป็นทางการ

  • มีประโยชน์มาก ถ้าลืม UUID จะมาเปิดอ้างอิง ผมก็ใช้เว็บนี้ตลอดเวลาต้องจำ private key ของบิตคอยน์: https://privatekeys.pw/keys/bitcoin/1

    • คีย์สุ่ม: ยอดคงเหลือ 0
      คีย์จริง: ตอนนี้ยอดคงเหลือกลายเป็น 0
    • ไม่รู้มาก่อนว่ามีคนสร้าง คีย์ BTC ที่อ่อนแอ เล่น ๆ ด้วย บางส่วนน่าจะใช้เป็นกับดักล่อบอตด้วย
    • แน่นอนว่าน่าจะมีคนค้นหา private key จริงแล้วทำให้มันอาจรั่วไหลด้วย
    • ดูอันนี้ด้วย: https://keys.lol/

  • บางครั้งพอสร้าง UUID ขึ้นมาแล้วไม่ได้เอาไปใช้ที่ไหน ก็รู้สึกผิดแปลก ๆ เหมือนทำให้มันสูญเปล่า

    • คุณไม่ได้รู้สึกแบบนั้นคนเดียว: https://wasteaguid.info/
    • UUID มีมากพออยู่แล้ว การไม่บันทึกมันไว้ที่ไหนสักแห่งกลับเป็นการประหยัดทรัพยากรที่หายากกว่าด้วยซ้ำ
    • แล้วรู้สึกผิดแค่ไหนกับ UUID ทั้งหลายที่ไม่ได้ถูกสร้างขึ้นมา จนไม่มีโอกาสได้เกิดเลย?
    • ข้อมูล clickstream ของบริษัทมีคอลัมน์ event_uuid ซึ่งเป็นการรวม UUID, จำนวนเต็มขนาดใหญ่, หมายเลขบัญชี และตัวระบุอื่น ๆ อีกสัก 10 อย่างเข้าด้วยกัน
      เวลาที่ไม่รู้ว่าควร join ด้วยคอลัมน์ไหน การ join ก็สะดวกมาก
    • เมื่อก่อนเคยใช้ SELECT TOP 1 ... ORDER BY NEWID() เพื่อเลือกเรคคอร์ดหนึ่งรายการจากตารางที่มีหลายล้านรายการ
      UUID หลายล้านตัวถูกสร้างขึ้น และหนึ่งในนั้นบังเอิญถูกเลือกเพราะมีค่าต่ำที่สุด แล้วเรคคอร์ดที่เชื่อมโยงอยู่ก็ถูกส่งกลับมา เป็นการสิ้นเปลืองสุด ๆ

  • ส่วนที่บอกว่า “เบราว์เซอร์ไม่อยากเรนเดอร์หน้าต่างที่สูงกว่าหนึ่งล้านล้านของหนึ่งล้านล้านพิกเซล เลยต้องจัดการการเลื่อนและการเรนเดอร์เอง” น่าสนุกดี ถ้าลองทำจริง ๆ จะค่อนข้างน่าผิดหวัง และไปไม่ถึงใกล้ ๆ หนึ่งล้านล้านพิกเซลเลยด้วยซ้ำ
    เมื่อ 5 ปีก่อนตอนทำงานที่ Fastmail มีลูกค้าที่ใช้ IE ใส่อีเมลประมาณ 200,000 ฉบับไว้ใน mailbox แล้ว scrollbar พัง เลยไปตรวจดูขีดจำกัด ได้ผลประมาณนี้ และบางอันเพิ่งกลับไปเช็กใหม่เมื่อกี้
    Firefox เมื่อก่อนจะละทิ้ง declaration ที่ถูกตีความว่าเป็นค่ามากกว่า 17,895,697 พิกเซล ตอนนี้ clamp ไว้ตรงจุดนั้น แต่มีความต่างประมาณ 3 พิกเซล เลยยังไม่ชัดทันทีว่าเกิดอะไรขึ้นกันแน่
    IE จะละทิ้ง declaration ที่ถูกตีความว่าเป็นค่าตั้งแต่ 10,737,418.23 พิกเซลขึ้นไป ส่วน WebKit จะ clamp ค่าแถว ๆ 2²⁵ หรือประมาณ 33,554,432 พิกเซล
    ตอนทดสอบครั้งก่อน Chromium เหมือนกับ WebKit แต่ตอนนี้ clamp แถว ๆ 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 ครั้งพอ มากกว่านั้นเยอะเกินไป
      แล้วก็รอวันที่ผมจะรู้ว่าแพ็กเกจของคุณไม่ได้ทำสิ่งที่ผมต้องการเป๊ะ ๆ แล้วต้อง fork ด้วยนะ
    • จะดีกว่านี้ถ้า 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 และบอกว่า “มีหน้าขนาด 3,200 ตัวอักษรทั้งหมดที่เป็นไปได้ในปัจจุบัน” อย่างไรก็ตาม ชุดอักขระถูกจำกัดและไม่มีเครื่องหมายไฮเฟน จึงหา UUID เหล่านี้ไม่เจอ

    • ยังมีงานดัดแปลงชื่อ A Short Stay in Hell (2009) ของ Steven L. Peck ด้วย
      ถ้าเข้าใจตัวเลขขนาดมหึมา ก็เป็นงานอ่านที่ทั้งสนุกและน่ากลัว

  • นึกว่าจะเป็นรายชื่อโดเมน .com ทั้งหมดที่เป็น UUID ที่ถูกต้อง เลยสงสัยว่าจริง ๆ แล้วจะมีโดเมนแบบนั้นอยู่สักกี่อัน
    อัปเดต: มีคนแชร์ไว้แล้วในคอมเมนต์อื่น: https://news.ycombinator.com/item?id=42342653

  • เทคโนโลยีการบีบอัดก้าวหน้ามากจนตอนนี้เราสามารถสำรวจหน้าเว็บที่มีขนาดมากกว่า 340 อันเดซิลเลียนไบต์ ได้แล้ว
    เรากำลังอยู่ในยุคที่น่าทึ่งจริง ๆ

    • อันนี้แทบจะแน่นอนว่าเป็นการสร้างสถิติใหม่ของ คะแนน Weissman สูงสุด
    • ไม่เห็นจะมีอะไร เมื่อไม่กี่ปีก่อนใน Cookie Clicker ร้านเบเกอรี่ของผมผลิตระดับอันเดซิลเลียนได้สบาย ๆ

  • น่าทึ่งที่เป็นเว็บไซต์ซึ่งมีเนื้อหามากกว่าหนึ่งหน้าจออยู่ในคราวเดียว แต่ตอนเลื่อนกลับไม่มีแอนิเมชันโหลดหลายวินาทีโผล่มา
    สงสัยว่านักพัฒนาเว็บแอปพลิเคชันสมัยใหม่จะหาทางใช้ประโยชน์จากเทคโนโลยีนี้ได้หรือไม่

    • เห็นด้วยเต็มที่ ผมก็คิดทันทีว่า “ว้าว เร็ว ลื่น และตอบสนองดี!”
      ฮาร์ดแวร์คอมพิวเตอร์เร็วขึ้นกว่าเมื่อปี 1995 หรือ 30 ปีก่อนถึง 1,000 เท่า แต่ซอฟต์แวร์กลับบวมเทอะทะจนยังช้ากว่าเดิม เป็นเรื่องไร้สาระมาก
      วิดีโอที่เกี่ยวข้อง: “Will Software Stop Getting Slower?” Jonathan Blow
      https://www.youtube.com/watch?v=4ka549NNdDk