UUID Decoder: คู่มือถอดรหัส version, variant และ timestamp ที่ซ่อนอยู่ใน UUID

นักพัฒนาส่วนใหญ่มักมอง UUID เป็นแค่สตริงที่อ่านไม่รู้เรื่อง สร้างขึ้นมา เก็บลงฐานข้อมูล แล้วก็จบ แต่ความจริงแล้ว UUID คือค่า 128 บิตที่มีโครงสร้างชัดเจน และเบาะแสที่มีประโยชน์ที่สุดซ่อนอยู่ในจุดเล็ก ๆ ที่เรียกว่า version nibble ตัวเลขหลักเดียวนี้จะบอกคุณว่า UUID ตัวนั้นแฝง timestamp ของการสร้างเอาไว้ หลั่น MAC address ของเครื่องที่สร้างมันออกมา หรือเป็นแค่ค่าสุ่มล้วน ๆ การอ่านค่านี้ด้วยมือเปล่าต้องนับเลขฐานสิบหกแล้วคำนวณเลขฐานสองในหัว ซึ่งเป็นงานที่ UUID Decoder ทำให้โดยอัตโนมัติ

UUID Decoder จะ parse UUID ที่คุณวางและระบุ version (1 ถึง 8) และ variant ได้ทันที สำหรับ version แบบอิงเวลา เครื่องมือจะดึง timestamp ที่ฝังอยู่ในตัว identifier ออกมาด้วย ไม่ว่าจะเป็นนาฬิกา Gregorian 60 บิตของ v1, ฟิลด์ที่จัดเรียงใหม่ของ v6 หรือตัวนับ Unix millisecond ของ v7 ทุกอย่างประมวลผลแบบ client-side 100% ในเบราว์เซอร์ ข้อมูลผลิตภัณฑ์จริงของคุณจึงไม่มีทางหลุดออกจากเครื่อง

ทำไมต้องใช้ UUID Decoder?

• ระบุ version ได้ทันที เลขฐานสิบหกตัวที่ 13 คือค่า version เครื่องมือจะอ่าน nibble นี้แล้วบอกคุณทันทีว่าคุณกำลังดู v1 แบบอิงเวลา, v4 แบบสุ่ม, v7 แบบเรียงลำดับได้ หรือรูปแบบอื่น โดยไม่ต้องแปลงเลขในหัวเอง
• ดึง timestamp ที่ซ่อนอยู่ version 1, 6 และ 7 ต่างจดบันทึกเวลาที่ถูกสร้างไว้ในตัว decoder จะคำนวณกลับเป็นทั้งค่าตัวนับดิบและวันเวลา UTC ที่อ่านง่าย ทำให้ตอบคำถาม "ของนี้สร้างเมื่อไร?" ได้จาก ID เพียงอย่างเดียว
• ถอดรหัส variant บิต variant จะบอกว่า UUID นั้นเป็นไปตามสเปกใด ระหว่าง RFC 9562 รูปแบบปัจจุบัน หรือรูปแบบ Microsoft รุ่นเก่า ซึ่งจำเป็นเวลาตรวจสอบ identifier จากระบบเก่า
• ประมวลผลฝั่ง client ล้วน ๆ และฟรี ทุกอย่างเกิดขึ้นในเครื่องคุณ ไม่ต้องสมัคร ไม่มี API key ไม่มีลิมิต แม้แต่ ID ที่ copy มาจากเหตุการณ์ที่กำลังดำเนินอยู่จริง ๆ ก็ปลอดภัย
• รองรับทุก version ที่เจอในงานจริง ตั้งแต่ v1 รุ่นคลาสสิกไปจนถึง v7 ที่เฟรมเวิร์กยุคใหม่ใช้ รวมถึง v3, v5 และ v8 เครื่องมือจะระบุ version และอธิบายฟิลด์ต่าง ๆ ให้ครบ

ฟีเจอร์หลัก

• เผยตัวตนเครื่อง ผลลัพธ์ของ v1 จะแสดงฟิลด์ node ซึ่งในระบบดั้งเดิมคือ IEEE MAC address ของเครื่องที่สร้าง ID
• คำนวณฟิลด์ที่จัดเรียงใหม่ถูกต้อง เพราะ v6 จัดเรียงฟิลด์ของ v1 ใหม่เพื่อให้ timestamp เรียงลำดับได้ decoder จึงใช้คณิตศาสตร์นาฬิกาเดียวกันกับทั้งสอง version ซึ่งคำนวณเองแล้วพลาดง่าย

วิธีใช้งาน

1. เปิด UUID Decoder ในเบราว์เซอร์ ช่องรับข้อมูลรองรับ UUID ที่มีหรือไม่มีขีด ตัวพิมพ์ใหญ่หรือเล็กก็ได้
2. วาง identifier ที่ copy มาจากแถวฐานข้อมูล log ไฟล์ หรือรายงาน error
3. ดู badge ของ version และ variant ที่จะบอกทันทีว่าตรวจพบ version อะไร และมี timestamp ฝังอยู่หรือไม่
4. อ่านฟิลด์ที่ถอดรหัสแล้ว ทั้งค่าตัวนับดิบ วันเวลา UTC และส่วนประกอบอื่น เช่น clock sequence และ node
5. ใช้ต่อได้ไม่จำกัดจำนวน จะ decode ID ทั้งชุดจากไฟล์ log ทีละรายการก็ได้

UUID ไม่ได้สุ่มขึ้นมาทั้งหมด

UUID มาตรฐานมี 32 หลักฐานสิบหกจัดกลุ่มแบบ 8-4-4-4-12 และความหมายของแต่ละหลักขึ้นอยู่กับ version version nibble คือเลขฐานสิบหกตัวแรกของกลุ่มที่สาม ส่วน variant กำหนดโดยบิตนำของหลักแรกในกลุ่มที่สี่

• Version 1 บรรจุ timestamp 60 บิตที่นับเป็นช่วง 100 นาโนวินาทีนับจากวันที่ 15 ตุลาคม 1582, clock sequence และ MAC address 48 บิตของอินเทอร์เฟซที่สร้าง ID นี้ ID จากเครื่องเดียวกันจะเรียงลำดับได้ถูกต้อง แต่รูปแบบนี้ก็รั่วไหลข้อมูลด้วยเช่นกัน
• Version 4 คือแบบที่ทุกคนนึกถึง กล่าวคือ 122 บิตของค่าสุ่มระดับเข้ารหัสลับ ที่เหลืออยู่คงที่แค่บิต version และ variant ไม่มี timestamp ไม่มีตัวตนเครื่อง ไม่มีลำดับ เหมาะเมื่อต้องการแค่ความไม่ซ้ำ
• Version 6 จัดเรียงฟิลด์ของ version 1 ใหม่โดยย้ายส่วนสำคัญของ timestamp มาไว้หน้าสุด ทำให้ ID เรียงตามลำดับตัวอักษรได้ในฐานข้อมูล โดยยังใช้นาฬิกา Gregorian เดิมและมีข้อควรระวังด้านความเป็นส่วนตัวเช่นเดิม
• Version 7 คือ UUID แบบเรียงตามเวลายุคใหม่สำหรับระบบกระจายศูนย์ โดย 48 บิตแรกคือ Unix timestamp หน่วย millisecond ตามด้วยบิตสุ่ม ทำให้ ID เรียงลำดับได้และเป็นมิตรกับ index

บิต variant อยู่บนสุดของเลขฐานสิบหกตัวที่ 16 ถ้า nibble เป็น 8, 9, a หรือ b (เลขฐานสอง 10xx) แปลว่าเป็นรูปแบบ RFC 9562 ที่ไลบรารีสมัยใหม่แทบทั้งหมดใช้ ถ้าเป็น c หรือ d คือรูปแบบ Microsoft รุ่นเก่า และ e กับ f สงวนไว้ ถ้า variant ตรวจไม่ผ่านมักแปลว่าผู้สร้างไม่เป็นไปตามสเปก ซึ่งเป็นสัญญาณดีบักที่มีประโยชน์

การดึง timestamp ทำได้ง่ายเมื่อรู้โครงสร้าง ลองดู v7 อย่าง 018f6b2c-4e5a-7c1d-8a2f-3b9d1e7c5a40 version nibble คือ 7 และ variant nibble คือ 8 เอา 48 บิตแรกคือ 018f6b2c4e5a มาแปลง จะได้ 1,715,490,016,858 millisecond นับจาก Unix epoch หรือคือ 2024-05-12 05:00:16.858 UTC นั่นเอง

ตัวอย่าง v1: 1e5f8330-9b6c-11ee-8c99-0242ac120002 นำ time_hi (0x1ee), time_mid (0x9b6c) และ time_low (0x1e5f8330) มารวมกัน จะได้ 139,219,527,163,413,296 ช่วงของ 100 นาโนวินาทีนับจากปี 1582 ตรงกับ 2023-12-15 17:05:16.341 UTC สังเกตฟิลด์ node 0242ac120002 ซึ่งเป็น MAC address จริง และคำนำหน้า 02:42 แบบ Docker บอกที่มาของมันชัดเจน ส่วน version 6 เก็บค่า 60 บิตเดิมแบบจัดเรียงใหม่เป็น 1ee9b6c1-e5f8-6330-... และ decoder จะคำนวณได้เวลาสร้างเดียวกัน

นี่คือมุมด้านความเป็นส่วนตัว UUID แบบ version 1 คือคำสารภาพเล็ก ๆ มันรั่วทั้งเวลาสร้างที่แม่นยำและตัวตนฮาร์ดแวร์ของเครื่องที่สร้าง นักวิจัยเคยใช้ v1 ที่รั่วไหลไประบุเครื่องของผู้เขียนมัลแวร์ ก่อนจะเปิดเผย ID ต่อสาธารณะ ควรรู้ให้ชัดว่า v1 ของคุณกำลังบอกอะไร

กรณีใช้งานจริง

หาอายุของข้อมูลในฐานข้อมูล

ในตารางที่ใช้ UUID แบบอิงเวลา identifier ทุกตัวคือคอลัมน์ created_at ฟรี ๆ ถ้าได้รับมอบฐานข้อมูลเก่าที่ไม่มี timestamp ของระบบ audit การ decode primary key แบบ v1 หรือ v7 จะคืนเวลาสร้างของทุกแถวกลับมา มีค่ามากระหว่าง migration

ดีบักระบบกระจายศูนย์

เมื่อ request ล้มเหลวข้ามหลายบริการ UUID ที่แนบกับข้อความเหล่านั้นจะเล่าเรื่องได้ การ decode v7 ID ของเหตุการณ์ช่วยสร้างลำดับการทำงานข้ามเครื่องที่นาฬิกาเพี้ยน และเชื่อมโยง log เข้าด้วยกัน

ฟอเรนซิกเอกสาร

โปรแกรมประมวลผลคำและตัวสร้าง PDF มักฝัง UUID ไว้ใน metadata และหลายตัวยังสร้างเป็น v1 การ decode ID ที่ฝังไว้สามารถบอกได้ว่าเอกสารถูกสร้างเมื่อไรและบนเครื่องไหน ซึ่งเป็นหลักฐานสำคัญในงาน incident response

เลือก v4 หรือ v7 สำหรับระบบใหม่

กำลังเลือกกลยุทธ์ ID ให้โปรเจกต์ใหม่? ลอง decode ตัวอย่างจากแต่ละไลบรารีดู v4 ให้ความลับสูงสุด ส่วน v7 ให้การเรียงลำดับและ timestamp ฟรี ๆ แลกกับการเปิดเผยเวลาสร้างแก่ใครก็ตามที่เห็น ID

แนวทางปฏิบัติที่ดีที่สุด

• เลือก v7 สำหรับ ID ใหม่ที่ต้องเรียงลำดับ มันรวม Unix timestamp แบบ millisecond กับค่าสุ่ม เรียงได้ตามธรรมชาติใน B-tree index และไม่รั่ว MAC address เหมือน v1
• จำไว้ว่า v1 รั่วไหล decode v1 ดูก่อนเปิดเผยต่อสาธารณะ ถ้าฟิลด์ node มี MAC address จริงถือว่าเป็นการรั่วไหลของข้อมูล ควรย้ายไป v4 หรือ v7
• ตรวจความถูกต้องก่อน decode ยืนยันว่าสตริงตรงรูปแบบ 8-4-4-4-12 ก่อนเชื่อผลลัพธ์ที่ได้
• มอง timestamp ที่ decode ได้เป็นเวลาสร้าง ไม่ใช่ความจริงสัมบูรณ์ เพราะมันคือเวลาที่ ID ถูกสร้าง ซึ่งอาจต่างจากเวลาที่เหตุการณ์ทางธุรกิจเกิดขึ้น
• อย่าใช้เวลาที่ decode ได้ตัดสินด้านความปลอดภัยเพียงลำพัง นาฬิกาเพี้ยนและการปลอมแปลงทำให้มันไม่เหมาะเป็นฐานของการอนุญาตสิทธิ์

เริ่มใช้งานเลย

คราวหน้าที่ UUID โผล่มาในไฟล์ log รายงานบั๊ก หรือ database dump อย่าเพิ่งมองข้าม ลองวางลงใน UUID Decoder แล้วให้ identifier ตัวนั้นเล่าเรื่องของมันเอง

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• UUID Generator — สร้าง identifier แบบ v1, v4 และ v7 เป็นชุด
• Snowflake ID Decoder — ดึง timestamp จาก Snowflake identifier
• Epoch Batch Converter — แปลง Unix timestamp เป็นวันเวลาที่อ่านง่าย

คราวหน้าที่ ID ดูเหมือนสุ่มไร้ความหมาย อย่าลืมว่า version nibble รู้คำตอบ ขอให้สนุกกับการถอดรหัส

คำถามที่พบบ่อย

ถ: decoder ดึง timestamp ออกจาก UUID ได้ทุกตัวหรือไม่?

ตอบ: ไม่ได้ มีเฉพาะ version แบบอิงเวลาเท่านั้นที่มี timestamp version 1 และ 6 ฝังนาฬิกา Gregorian 60 บิต ส่วน version 7 ฝัง Unix millisecond 48 บิต อย่าง version 4 และแบบ hash อย่าง version 3 กับ 5 ไม่มีข้อมูลเวลาเลย

ถ: วาง UUID จากระบบ production ลงในเครื่องมือได้ปลอดภัยหรือไม่?

ตอบ: ปลอดภัยครับ การประมวลผลทั้งหมดเกิดขึ้นในเบราว์เซอร์ของคุณ identifier ที่วางลงไปจะไม่ถูกส่งไปเซิร์ฟเวอร์ใด ไม่ถูกบันทึกหรือเก็บไว้ จึงใช้ได้แม้ระหว่างเหตุการณ์ที่กำลังดำเนินอยู่จริง

ถ: ทำไม v4 ของผมถึงไม่มี timestamp ให้ดู?

ตอบ: version 4 ถูกกำหนดให้เป็นค่าสุ่มล้วน นอกจากบิต version และ variant ที่คงที่แล้ว อีก 122 บิตคือค่าสุ่มทั้งหมด จึงไม่มีอะไรให้ถอดรหัส ถ้าต้องการเวลาสร้างควรเปลี่ยนมาสร้าง v7

ถ: timestamp ของ v1 แม่นยำแค่ไหน?

ตอบ: นาฬิกาของ v1 ละเอียดถึงระดับ 100 นาโนวินาที ความแม่นยำจริงจึงขึ้นกับนาฬิกาของเครื่องที่สร้าง ซึ่งโดยทั่วไปอยู่ในระดับไมโครวินาทีถึงมิลลิวินาที ถ้าเครื่องนั้นปรับเวลา ผลลัพธ์ก็จะสะท้อนตามไปด้วย