เครื่องมือสำหรับนักพัฒนา · ตัวสร้าง UUID
อะไรทำให้ UUID สตริงมีรูปแบบที่ดีและสิ่งที่ผู้ตรวจสอบไม่สามารถรู้ได้
· มันทำงานอย่างไร
uuid การเข้ารหัส เบราว์เซอร์-apis
ตัวพิมพ์ใหญ่ วงเล็บปีกกา โกศ: คำนำหน้าและยัติภังค์ที่หายไปทั้งหมดจะแสดงเป็นข้อมูลจริง โพสต์นี้จะกำหนดรูปแบบ Canonical แสดงให้เห็นว่าผู้ตรวจสอบแบบผ่อนปรนควรยอมรับอะไร และแยกรูปแบบที่ดีออกจากการดำรงอยู่
400 ที่ควรจะเป็น 404 — การตรวจสอบ UUID ที่เลอะเทอะทำให้เกิดข้อผิดพลาด API ที่น่าสับสนได้อย่างไร
ตำแหน่งข้อมูล API ได้รับตัวระบุจากไคลเอ็นต์: {12345678-90AB-CDEF-1234-567890ABCDEF} รหัสตรวจสอบจะตรวจสอบว่าตรงกับ /[0-9a-f]{32}/ และปฏิเสธว่าไม่ถูกต้อง ลูกค้าได้รับ 400 คำขอไม่ถูกต้อง โดยที่ 404 ไม่พบ หมายความว่า ตัวระบุมีรูปแบบที่ถูกต้อง ซึ่งเป็น UUID ที่ถูกต้องในรูปแบบวงเล็บปีกกา แต่เครื่องมือตรวจสอบเข้มงวดเกินไป ในทางกลับกัน จุดสิ้นสุดที่ยอมรับสตริงฐานสิบหกอักขระ 32 ใดๆ (ไม่มีขีดกลาง) จะยอมรับ 123456789012345678901234567890123456 แยกวิเคราะห์ว่าถูกต้อง และพิมพ์ผิด RFC 9562 กำหนดการแสดงข้อความตามรูปแบบบัญญัติ แต่อินพุตในโลกแห่งความเป็นจริงมาถึงในรูปแบบที่แตกต่างกันห้ารูปแบบ และผู้ตรวจสอบความถูกต้องที่ยอมรับเฉพาะรูปแบบมาตรฐานเท่านั้นที่จะปฏิเสธ 1 ถึง 5 เปอร์เซ็นต์ของอินพุตที่มีเจตนาดี
รูปแบบข้อความตามรูปแบบบัญญัติ — 32 เลขฐานสิบหกตัวพิมพ์เล็กใน 8-4-4-4-12 อักขระ 36 ทุกประการ ตามที่มาตรฐานระบุสำหรับเอาต์พุต
รูปแบบข้อความตามรูปแบบบัญญัติคือ 32 เลขฐานสิบหกตัวพิมพ์เล็กในห้ากลุ่มคั่นด้วยเครื่องหมายขีดกลาง: 8-4-4-4-12 แสดงเป็น 550e8400-e29b-41d4-a716-446655440000 มาตรฐานกำหนดตัวพิมพ์เล็กสำหรับเอาต์พุต ในอินพุต แนะนำให้ใช้การจับคู่ที่ไม่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ แบบฟอร์มนี้ไม่คลุมเครือ แยกวิเคราะห์เป็นไบต์ในลักษณะเดียวกันในทุกแพลตฟอร์ม และเป็นสิ่งที่ทุกไลบรารี UUID ส่งออกตามค่าเริ่มต้น หากคุณกำลังสร้าง UUID ใหม่จาก CSPRNG รูปแบบมาตรฐานคือสิ่งที่คุณควรสร้างและสิ่งที่ ToolAcre ผลิต ข้อมูลในโลกแห่งความเป็นจริงเบี่ยงเบนไปในลักษณะที่คาดเดาได้ ตัวระบุตัวพิมพ์ใหญ่ (550E8400-E29B-41D4-A716-446655440000) เป็นเรื่องธรรมดาจากระบบที่ใช้ค่าเริ่มต้นเป็นตัวพิมพ์ใหญ่ พวกเขาเป็นตัวแทนของไบต์เดียวกันและควรได้รับการยอมรับหลังจากการทำให้เป็นมาตรฐานเป็นตัวพิมพ์เล็ก
รูปแบบต่างๆ ที่คุณจะพบโดยทั่วไป ได้แก่ เลขฐานสิบหกตัวพิมพ์ใหญ่ {braces} คำนำหน้า urn:uuid: และรูปแบบที่ไม่มียัติภังค์อักขระ 32 ซึ่งเป็นรูปแบบที่มาตรฐานกำหนดให้ยอมรับ
Braced form ({550e8400-e29b-41d4-a716-446655440000}) เป็นเอาต์พุตมาตรฐานจากโมดูล uuid ของ Python และระบบของ Microsoft การถอดเหล็กจัดฟันจะทำให้ได้รูปแบบตามบัญญัติที่ถูกต้อง คำนำหน้า URN (urn:uuid:550e8400-e29b-41d4-a716-446655440000) ถูกกำหนดโดย RFC 8141 สำหรับชื่อทรัพยากรที่เหมือนกัน การลบโครงร่างและคำนำหน้าตัวระบุการลอกออกจากรูปแบบมาตรฐาน รูปแบบที่ไม่มียัติภังค์ (550e8400e29b41d4a716446655440000) คือ 32 หลักเลขฐานสิบหกที่ไม่มีโครงสร้าง มันเป็นไบต์ที่ถูกต้อง แต่สูญเสีย 8-4-4-4-12 การจัดกลุ่มที่ทำให้เวอร์ชันและตัวแปรสามารถอ่านได้ ตัวแปรเหล่านี้แมปกับค่า 128-บิตเดียวกันทั้งหมด RFC 9562 ส่วน 3 ระบุว่าในอินพุต รูปแบบตัวพิมพ์ใหญ่ SHOULD ได้รับการยอมรับ มันไม่ได้ห้ามตัวแปรอื่น มันบอกว่าในเอาต์พุตจะใช้รูปแบบตัวพิมพ์เล็กตามรูปแบบบัญญัติ MUST
ความสมบูรณ์ของเวอร์ชันและตัวแปร — ไม่ว่าจะปฏิเสธ UUID ซึ่งมีกลุ่มที่สามขึ้นต้นด้วย 0 หรือกลุ่มที่สี่ขึ้นต้นด้วย f
เครื่องมือตรวจสอบที่มีรูปแบบถูกต้องควร: ยอมรับแบบฟอร์ม 8-4-4-4-12 ตามรูปแบบบัญญัติที่เป็นตัวพิมพ์เล็กหรือตัวพิมพ์ใหญ่ ยอมรับค้ำยันและโกศ: ตัวแปรโดยการปอกพวกมันและตรวจสอบความถูกต้องของแบบฟอร์มหลัก ยอมรับสตริงเลขฐานสิบหกแบบไม่มียัติภังค์ 32 หลัก และจัดรูปแบบเป็นรูปแบบมาตรฐานเพื่อการเปรียบเทียบ ปฏิเสธสตริงที่มีตัวเลขฐานสิบหกหรืออักขระที่ไม่ใช่เลขฐานสิบหกไม่ถูกต้อง ข้อผิดพลาดที่พบบ่อยที่สุดคือการปฏิเสธอินพุตตัวพิมพ์ใหญ่หรือวงเล็บปีกกา เนื่องจากเครื่องมือตรวจสอบความถูกต้องเขียนด้วยลายมือเพื่อให้ตรงกับรูปแบบ Canonical เท่านั้น การตรวจสอบเวอร์ชันและตัวแปรอาจตรวจพบการพิมพ์ผิดได้ หากกลุ่มที่สามขึ้นต้นด้วย 0 หรือ 9 แสดงว่า UUID ไม่ถูกต้องหรือสงวนไว้ หากกลุ่มที่สี่ขึ้นต้นด้วย e หรือ f รูปแบบนั้นจะไม่ใช่ RFC 9562
ตัวอย่างการทำงาน — สตริงผู้สมัคร 6 รายการผ่านการตรวจสอบอย่างเข้มงวดและ 1 รายการผ่อนปรน พร้อมเหตุผลที่แต่ละรายการผ่านหรือล้มเหลว
เครื่องมือตรวจสอบแบบผ่อนปรนจะยอมรับค่าเหล่านี้ ผู้ตรวจสอบที่เข้มงวดสามารถปฏิเสธได้ การตรวจสอบที่มีรูปแบบถูกต้อง ToolAcre จะทำการตรวจสอบความถูกต้องอย่างเข้มงวด โดยจะยืนยันรูปแบบอักขระ 36 ตามรูปแบบบัญญัติที่มีขีดกลางในตำแหน่งที่ถูกต้อง ตรวจสอบเลขฐานสิบหกในทุกตำแหน่ง และตรวจสอบว่าเวอร์ชันและบิตของตัวแปรอยู่ในช่วงหรือไม่ ไม่ได้ตรวจสอบว่า UUID มีอยู่ในฐานข้อมูลของคุณ หรือสร้างขึ้นจากแหล่งที่มีการเข้ารหัสที่ปลอดภัย สิ่งเหล่านี้เป็นการตรวจสอบแยกต่างหากที่ดำเนินการโดยตรรกะของแอปพลิเคชันของคุณ รูปร่างดีไม่เหมือนกับของจริง สตริง UUID ที่แยกวิเคราะห์อย่างถูกต้องตามรูปร่างอาจไม่สามารถระบุแถวใดๆ ในฐานข้อมูลของคุณได้
รูปแบบที่ดีนั้นไม่มีอยู่จริง - เหตุใด UUID ที่สมบูรณ์แบบทางไวยากรณ์จึงอาจไม่อยู่ในข้อมูลของคุณและเหตุใดตัวตรวจสอบไม่ควรเป็นเลเยอร์การอนุญาตของคุณ
UUID ที่มีรูปแบบถูกต้องสมบูรณ์อาจเกิดจากการเดาหรือคัดลอกผิด การตรวจสอบรูปแบบคือด่านแรก ส่วนการตรวจสอบว่ามีอยู่จริงและการตรวจสอบสิทธิ์คือด่านที่สองและสาม การค้นฐานข้อมูลสำหรับอินพุตที่มีรูปแบบไม่ถูกต้องทุกครั้งเป็นงานที่สิ้นเปลือง การปฏิเสธอินพุตดังกล่าวก่อนสืบค้นฐานข้อมูลช่วยประหยัดเวลา เครื่องมือสร้างของ ToolAcre ให้ UUID มาตรฐาน 36 อักขระ หากคุณสร้างตัวตรวจสอบเอง ให้รองรับรูปแบบที่มีวงเล็บปีกกาและรูปแบบ urn: เพื่อให้ตรงกับอินพุตจริง และปฏิเสธสตริงที่ไม่ผ่านกฎรูปทรงพื้นฐานก่อนสอบถามฐานข้อมูล การสร้างตัวตรวจสอบแบบเข้มงวดต้องใช้นิพจน์ทั่วไปและจัดการกรณีขอบ รูปแบบมาตรฐานคือ /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i (ไม่แยกตัวพิมพ์ใหญ่เล็ก) รูปแบบวงเล็บปีกกาเพิ่มวงเล็บ: /^\{[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\}$/i และรูปแบบ urn: เพิ่มสคีม: /^urn:uuid:[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i
สิ่งนี้ไม่ครอบคลุมถึง — การปรับ ID ให้เป็นมาตรฐานสำหรับการจัดเก็บและการเลือกประเภทคอลัมน์ซึ่งเป็นการตัดสินใจที่แยกจากกัน
regex เดียวที่จัดการรูปแบบทั้งหมดจะอ่านได้ยากแต่เป็นไปได้ เครื่องมือตรวจสอบส่วนใหญ่จะทำให้เป็นมาตรฐานก่อน: ถอดวงเล็บปีกกาและโกศ: นำหน้า แปลงเป็นตัวพิมพ์เล็ก จากนั้นจับคู่รูปแบบมาตรฐาน สามารถตรวจสอบเวอร์ชันและบิตตัวแปรได้หลังจากการจับคู่รูปแบบโดยตรวจสอบตำแหน่ง 14 และตำแหน่ง 19 ตามที่อธิบายไว้ในบทความ 403 การจัดการข้อมูลที่ไม่ถูกต้องอย่างงดงามเป็นส่วนหนึ่งของการออกแบบการตรวจสอบ เมื่อไคลเอ็นต์ส่ง UUID ที่มีรูปแบบไม่ถูกต้อง อย่าเปิดเผยรูปแบบ regex หรือกฎการตรวจสอบภายในในข้อความแสดงข้อผิดพลาด ส่งกลับข้อผิดพลาดที่ชัดเจน: "รูปแบบ UUID ไม่ถูกต้อง คาดหวังรูปแบบ 8-4-4-4-12 รูปแบบ เช่น 550e8400-e29b-41d4-a716-446655440000" อย่าพยายาม เพื่อแก้ไขอินพุต ขอให้ลูกค้าส่งอีกครั้ง
ประเด็นสำคัญ: ตรวจสอบรูปร่างตั้งแต่เนิ่นๆ ค้นหาการมีอยู่แยกจากกัน — การตรวจสอบ ToolAcre จะยืนยันรูปร่างในเบราว์เซอร์ก่อนที่คุณจะแตะฐานข้อมูล
บางระบบบันทึกอินพุตที่ไม่ถูกต้องสำหรับการตรวจสอบความปลอดภัย (ตรวจจับการพยายามแทรกหรือการโจมตีรูปแบบที่สับสน) เครื่องมือตรวจสอบ ToolAcre ปฏิเสธรูปแบบที่ไม่เป็นที่ยอมรับซึ่งมีข้อความแสดงข้อผิดพลาดที่ชัดเจน และไม่พยายามแก้ไขอัตโนมัติ เหตุใดรูปแบบ Canonical จึงมีความสำคัญต่อการทำงานร่วมกัน: หากระบบหนึ่งเก็บ UUID ไว้เป็นเลขฐานสิบหกแบบไม่มียติภังค์ และอีกระบบหนึ่งเก็บ UUID ไว้เป็นเลขฐานสิบหกแบบยัติภังค์ 8-4-4-4-12 การเปรียบเทียบกับความเท่าเทียมกันนั้นจำเป็นต้องมีการทำให้เป็นมาตรฐาน ตัวพิมพ์ใหญ่และตัวพิมพ์เล็กต้องมีการเปรียบเทียบที่ไม่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ การค้ำยันและเปลือยจำเป็นต้องทำการปอก รูปแบบเหล่านี้ทำให้การดำเนินงานจำนวนมาก (การนำเข้า การโยกย้าย การเปรียบเทียบ) ทำได้ยากขึ้น เครื่องมือมาตรฐานที่ส่งออกรูปแบบมาตรฐานช่วยลดแรงเสียดทาน ตัวสร้าง ToolAcre จะส่งออกรูปแบบมาตรฐานตัวพิมพ์เล็ก 36 อักขระเสมอ เมื่อคุณนำเข้า UUID จากระบบอื่น ให้ทำให้มาตรฐานเป็นแบบฟอร์มนี้ในกระบวนการ ETL ของคุณเพื่อให้แน่ใจว่ามีความสอดคล้องกัน