เครื่องมือสำหรับนักพัฒนา · ตัวสร้าง UUID
จาก 128 Bits ถึง 36 อักขระ: UUID การเข้ารหัสข้อความทำงานอย่างไร
· มันทำงานอย่างไร
uuid การเข้ารหัส เบราว์เซอร์-apis
UUID คือ 16 bytes แต่รูปแบบที่คุ้นเคยคือ 36 อักขระ โพสต์นี้จะอธิบายการคูณเลขฐานสิบหก ขีดกลาง กฎของตัวพิมพ์ และการเข้ารหัสที่สั้นกว่าที่ผู้คนใช้เมื่อแบบฟอร์มมาตรฐานยาวเกินไป
เหตุใดคอลัมน์จึงกว้างกว่าค่า — ค่า 16 ไบต์ซึ่งมีราคา 36 อักขระในข้อความ และความหมายสำหรับ URL และพื้นที่เก็บข้อมูล
ความกว้างของคอลัมน์ที่จัดเก็บจะขยายเมื่อคุณเลือกรูปแบบ UUID ค่า 128 บิตคือ 16 bytes แต่การแสดงข้อความนั้นขึ้นอยู่กับการเข้ารหัส: เลขฐานสิบหก (36 อักขระที่มีเครื่องหมายยติภังค์, 32 ไม่มี), base64url (22 อักขระ), base58 (22–23 อักขระ), Crockford base32 (26 อักขระ) หากสคีมาของคุณจัดเก็บ UUID เป็น VARCHAR(36) คุณจะใช้จ่าย 36 อักขระในทุกแถว ในตารางที่มี 1 พันล้านแถวและไม่มีคอลัมน์อื่น นั่นคือ 36 กิกะไบต์ของข้อความโอเวอร์เฮด เทียบกับ 16 กิกะไบต์ของไบนารี ทางเลือกไม่ใช่แค่เครื่องสำอางเท่านั้น ส่งผลต่อขนาดการสืบค้น การส่งข้อมูลไปกลับของเครือข่าย และความกดดันของแคช รูปแบบมาตรฐานคือ 36 อักขระ: เลขฐานสิบหก 8 หลัก, ขีดกลาง, เลขฐานสิบหกสี่หลัก, ขีดกลาง, เลขฐานสิบหกสี่หลัก, ขีดกลาง, เลขฐานสิบหกสี่หลัก, ขีดกลาง, เลขฐานสิบหกสิบสองหลัก
เลขฐานสิบหกจะเพิ่มทุกอย่างเป็นสองเท่า แต่ละไบต์จะกลายเป็นอักขระสองตัว และเครื่องหมายยัติภังค์สี่ตัวเติม 36 ให้สมบูรณ์
แต่ละไบต์จะกลายเป็นอักขระฐานสิบหกสองตัวพอดี (0–9, a–f) เครื่องหมายยัติภังค์มีไว้เพื่อให้อ่านง่ายและเหตุผลดั้งเดิมนับตั้งแต่ระบุ UUID ครั้งแรก การเข้ารหัสเลขฐานสิบหกจะเพิ่มจำนวนไบต์เป็นสองเท่า: 16 bytes กลายเป็น 32 หลักเลขฐานสิบหกบวก 4 ยัติภังค์ เป็นการเข้ารหัสที่ช้าที่สุดและยาวที่สุด แต่มนุษย์สามารถอ่านได้และรองรับทุกที่ กฎตัวพิมพ์: RFC 9562 กำหนดตัวพิมพ์เล็กสำหรับเอาต์พุตตามรูปแบบบัญญัติ แต่อินพุตไม่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ การจัดเก็บตัวพิมพ์ใหญ่ทำให้เสียโอกาสในการทำให้เป็นมาตรฐาน ดังนั้นจัดเก็บตัวพิมพ์เล็กและเปรียบเทียบอินพุตโดยไม่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ การเข้ารหัส Base64url แทนค่าสามไบต์เป็นอักขระสี่ตัวโดยใช้ตัวอักษร 64 อักขระ (A–Z, a–z, 0–9, ลบ, ขีดล่าง) สิบหกไบต์กลายเป็นอักขระ 21 ตัว และอักขระเสริมหนึ่งตัว รวมเป็นอักขระ 22 ตัว Base64url จะลบช่องว่างภายในและอักขระมาตรฐาน (บวกและเครื่องหมายทับ) ที่สงวนไว้ใน URL
กฎตัวพิมพ์ - ตัวพิมพ์เล็กในเอาต์พุต ไม่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ในอินพุต และเหตุใดการเปรียบเทียบตัวพิมพ์แบบผสมจึงทำให้เกิดการจับคู่แบบไม่โต้ตอบ
UUID ในรูปแบบ base64url จะบันทึกอักขระ 14 เมื่อเทียบกับเลขฐานสิบหก และใช้ได้ใน URL ที่ไม่มีการเข้ารหัสเปอร์เซ็นต์ ข้อเสีย: อ่านได้น้อยกว่า (ตัวอักษรตัวพิมพ์เล็กดูเหมือนตัวเลข b, 8, B และ 8 ง่ายต่อการสับสน) Bitcoin และบล็อกเชนอื่น ๆ ใช้ Base58 และลบอักขระที่ไม่ชัดเจน (0, O, I, l) ทำให้ผลลัพธ์เป็น 22–23 อักขระในขณะที่ยังคงอ่านได้ Crockford base32 (ออกแบบมาสำหรับรูปแบบที่เหมือน ISBN ที่สรุปยอดแล้ว) ใช้อักขระ 26 และจัดลำดับความสำคัญของความถูกต้องมากกว่าความกะทัดรัด Microsoft GUID byte-order trap ใช้กับที่เก็บข้อมูล UUID ในบางฐานข้อมูล RFC 9562 ระบุลำดับไบต์เครือข่าย (big-endian) สำหรับไบต์ทั้งหมด การกำหนดค่าเซิร์ฟเวอร์ Microsoft SQL บางตัวจะจัดเก็บ GUID ที่มีลำดับไบต์แบบ little-endian ในสามฟิลด์แรก
การเข้ารหัสที่สั้นกว่า — base64url ที่อักขระ 22, base58 และ Crockford base32 โดยมีข้อเสียคือความสามารถในการอ่านและความปลอดภัยในการคัดลอกและวาง
ค่า 128 บิตเดียวกันที่เก็บอยู่ใน big-endian และ little-endian จะสร้างสตริงเลขฐานสิบหกที่แตกต่างกัน UUID 550e8400-e29b-41d4-a716-446655440000 จัดเก็บเป็น Microsoft GUID อาจถูกเรียกค้นเป็น 00840e55-9be2-d441-a716-446655440000 (ไบต์ 0–3 และ 4–5 และ 6–7 กลับด้าน) หากระบบของคุณเชื่อมโยงระหว่างระบบที่สอดคล้องกับ RFC และระบบของ Microsoft คุณต้องตระหนักถึงสิ่งนี้และปรับมาตรฐานที่ขอบเขตหรือเอกสารว่ารูปแบบใดที่คุณใช้ในแต่ละคอลัมน์ ตัวอย่างการทำงาน: v4 UUID 9b2e4f1a-4f3e-4c1a-8a7d-1b2c3d4e5f60 ในเลขฐานสิบหกใช้อักขระ 36 เนื่องจาก 16 bytes มันคือ 9b 2e 4f 1a 4f 3e 4c 1a 8a 7d 1b 2c 3d 4e 5f 60 ใน base64url: แบ่งออกเป็นสามไบต์ แปลงเป็น base64, ขยายแถบ: my5PGk8-TBqKfRssPTRPX2A ในเลขฐานสิบหกที่ไม่มียัติภังค์: 9b2e4f1a4f3e4c1a8a7d1b2c3d4e5f60 (32 อักขระ)
กับดักลำดับไบต์ของ Microsoft - วิธีการจัดเก็บสามฟิลด์แรกของ GUID แบบ little-endian ดังนั้นไบต์เดียวกันจึงสามารถพิมพ์เป็นสองสตริงที่แตกต่างกันได้
Base64url บันทึก 14 อักขระ base58 จะประหยัดได้ประมาณเดียวกัน เลขฐานสิบหกเป็นมาตรฐาน เลือกตามกรณีการใช้งานของคุณ: หากตัวระบุปรากฏใน URL และอักขระทุกตัวมีความสำคัญ ให้ใช้ base64url หากปรากฏในบันทึกและ UI ที่มนุษย์อ่าน ให้ใช้รูปแบบมาตรฐานฐานสิบหก หากคุณกำลังสร้างระบบบล็อกเชนหรือระบบแบบกระจายที่การตรวจสอบมีความสำคัญ ให้ใช้ base58 หรือ Crockford base32 เมื่อเลือกประเภทคอลัมน์ ให้จัดเก็บค่าที่ปรับให้เหมาะสมที่สุดสำหรับรูปแบบการเข้าถึงจริงของคุณ หากคุณสืบค้น UUID บ่อยครั้งและต้องการการจับคู่ที่ไม่คำนึงถึงขนาดตัวพิมพ์ ให้จัดเก็บไบนารี่(16) และปล่อยให้ฐานข้อมูลจัดการการแทนค่า หากคุณค้นหาด้วยสตริงย่อย (ค้นหา UUID ที่ขึ้นต้นด้วยคำนำหน้า) เลขฐานสิบหกจะสามารถอ่านได้มากขึ้นในเอาต์พุตการดีบัก
ตัวอย่างการทำงาน — ตัวระบุหนึ่งตัวเขียนเป็นไบต์ เลขฐานสิบหกตามรูปแบบบัญญัติ และรูปแบบที่สั้นลง ซึ่งแสดงแต่ละขั้นตอนการแปลง
หากคุณส่งออกไปยัง CSV และส่งอีเมลไปยังผู้ใช้ที่ไม่ใช่ด้านเทคนิค เลขฐานสิบหกจะจดจำได้มากขึ้น หากคุณมีพื้นที่จำกัด (แอปบนอุปกรณ์เคลื่อนที่ที่มีแคชในเครื่อง) base64url หรือ base58 จะประหยัดแบนด์วิธ ตัวสร้าง ToolAcre เอาต์พุตรูปแบบมาตรฐานฐานสิบหก 36 อักขระ หากคุณต้องการการเข้ารหัสอื่น การตรวจสอบที่มีรูปแบบถูกต้องยังคงใช้งานได้ เนื่องจากจะทำให้การแสดงที่ถูกต้องเป็นปกติก่อนที่จะตรวจสอบรูปแบบ ข้อควรพิจารณาด้านประสิทธิภาพมีความสำคัญเมื่อเข้ารหัสหรือถอดรหัส UUID หลายล้านรายการ การเข้ารหัสเลขฐานสิบหกนั้นง่าย: แปลงแต่ละไบต์เป็นอักขระสองตัวในเวลา O(1) ต่อไบต์ การถอดรหัสก็ง่ายไม่แพ้กัน การเข้ารหัสและถอดรหัส Base64 ใช้ตารางการค้นหาและช้ากว่าเล็กน้อย (ประมาณ 2–3x ช้ากว่าฐานสิบหกต่อไบต์ ขึ้นอยู่กับฮาร์ดแวร์และการใช้งาน) Base58 ช้ากว่ามากเนื่องจากเป็นการแปลงฐานและต้องใช้เลขคณิตแบบแยกส่วน
สิ่งนี้ไม่ครอบคลุมถึง - ตัวเลือกคอลัมน์ฐานข้อมูล เช่น ประเภท uuid ดั้งเดิมกับ binary(16) ครอบคลุมแยกกัน
หากระบบของคุณเข้ารหัสหรือถอดรหัส UUID ในฮอตลูป (การสร้างตัวระบุความถี่สูง การส่งออกจำนวนมาก) เลขฐานสิบหกจะเร็วขึ้น หากการเข้ารหัสเกิดขึ้นไม่บ่อยนักและการประหยัดอักขระ 14 สำคัญ base64url ก็เป็นทางเลือกที่สมเหตุสมผล ตัวสร้าง ToolAcre เอาต์พุตเป็นเลขฐานสิบหก ดังนั้นคุณจึงได้เปรียบด้านประสิทธิภาพโดยไม่ต้องเสียสละความเข้ากันได้ ซีแมนทิกส์การเปรียบเทียบสตริงแตกต่างกันตามการเข้ารหัส UUID เลขฐานสิบหกสามารถเปรียบเทียบเป็นสตริงได้: 550e8400-e29b-41d4-a716-446655440000 < 550e8400-e29b-41d4-a716-446655440001 (ใช้การเปรียบเทียบพจนานุกรม) UUID ไบนารีสามารถเปรียบเทียบได้เป็นไบต์: การเปรียบเทียบแบบไบต์ต่อไบต์จะเหมือนกับการเปรียบเทียบตัวเลข อย่างไรก็ตาม UUID ที่เข้ารหัส Base64url และ base58 จะไม่รักษาลำดับตัวเลขไว้ในการเปรียบเทียบสตริงพจนานุกรม หากระบบของคุณอาศัยการเรียงลำดับคำศัพท์ของ UUID (รูปแบบที่พบบ่อยอย่างน่าประหลาดใจสำหรับการสร้างดัชนีหรือคีย์ฐานข้อมูล) คุณต้องใช้เลขฐานสิบหก ไบนารี่ หรือตัวแปร UUID ที่จัดเรียงได้ (v6 หรือ v7)
ประเด็นสำคัญ: เก็บรูปแบบ Canonical ไว้ที่ขอบเขต — ตัวสร้าง ToolAcre จะส่งออก UUID อักขระมาตรฐาน 36-อักขระ และเช็คจะยอมรับสตริงในรูปแบบนั้น
ขณะนี้ตัวสร้าง ToolAcre สร้าง UUID v4 ซึ่งไม่สามารถจัดเรียงตามลำดับการเข้ารหัสได้ การทำงานร่วมกันต้องมีมาตรฐานในการเข้ารหัสเพียงครั้งเดียว ระบบที่ยอมรับ UUID ในรูปแบบ hex, base64 และ base58 พร้อมกันจะต้องทำให้อินพุตทั้งหมดเป็นมาตรฐานในรูปแบบ Canonical ก่อนประมวลผล สิ่งนี้เป็นไปได้แต่เพิ่มความซับซ้อน API ภายนอกหรือฐานข้อมูลอาจต้องมีการเข้ารหัสเฉพาะ: API บางตัวคาดหวัง urn:uuid: นำหน้าเลขฐานสิบหก, บางตัวคาดหวังเลขฐานสิบหกแบบไม่มียัติภังค์ ส่วนบางตัวคาดหวัง base64url บันทึกความคาดหวังในการเข้ารหัส UUID ของระบบของคุณอย่างชัดเจนในสัญญา API ตัวสร้าง ToolAcre จะส่งเอาต์พุตฐานสิบหกตามรูปแบบบัญญัติเสมอ หากคุณต้องการการเข้ารหัสอื่นๆ ให้ดำเนินการแปลงอย่างชัดเจนและบันทึกข้อดีข้อเสีย (พื้นที่ ประสิทธิภาพ ความสามารถในการอ่าน และการจัดเรียง) ให้กับทีม