เครื่องมือสำหรับนักพัฒนา · ตัวสร้าง UUID
UUID ที่เป็นศูนย์และสูงสุด: ค่าพิเศษสองค่าและเมื่อใดจึงควรใช้
· พื้นหลัง
uuid นักพัฒนาเวิร์กโฟลว์ การตรวจสอบข้อมูล
Nil UUID ที่เป็นศูนย์ทั้งหมดอยู่ในมาตรฐานตั้งแต่ 2005 และ all-F Max UUID เข้าร่วมใน 2024 โพสต์นี้อธิบายว่ามีไว้เพื่ออะไร วิธีโต้ตอบกับเครื่องมือตรวจสอบความถูกต้อง และข้อผิดพลาดเกี่ยวกับค่า Sentinel ที่ควรหลีกเลี่ยง
แถวที่มี ID 00000000-0000-0000-0000-000000000000 — วิธีที่ตัวยึดตำแหน่งกลายเป็นจุดบกพร่องในการผลิต
แถวที่มีตัวระบุเป็น 00000000-0000-0000-0000-000000000000 สามารถมีรูปทรง UUID ในขณะที่มีความหมายที่แตกต่างจากตัวระบุที่สร้างขึ้น หากแอปพลิเคชันใช้ค่านั้นอย่างเงียบๆ สำหรับ “ยังไม่ได้กำหนด” ทุกแถวที่ยังสร้างไม่เสร็จจะใช้เครื่องหมายเดียวกันร่วมกัน โค้ดที่ถือว่า UUID ที่ยอมรับชื่อออบเจ็กต์จริงอาจร้องขอ แคช หรือเข้าร่วมบนตัวยึดตำแหน่งราวกับว่ามันเป็นคีย์ธรรมดา รูปแบบที่มองเห็นไม่ได้สื่อสารถึงกฎเกณฑ์ทางธุรกิจ มีเพียงสัญญารักษาการณ์ที่ชัดเจนเท่านั้นที่ทำ
จุดบกพร่องในการผลิตเริ่มต้นขึ้นเมื่อเลเยอร์หนึ่งทราบเกี่ยวกับตัวยึดตำแหน่งและอีกเลเยอร์ไม่ทราบ แบบฟอร์มอาจส่งค่า Nil, API อาจยอมรับ และเลเยอร์การคงอยู่อาจจัดเก็บไว้ ในขณะที่ผู้ปฏิบัติงานดาวน์สตรีมถือว่าสตริงที่ไม่ใช่ค่าว่างทุกรายการเป็นคีย์นอกที่ใช้งานได้ ความล้มเหลวไม่ใช่ว่า Nil มีรูปแบบไม่ถูกต้อง ToolAcre จงใจรับรู้ ความล้มเหลวคือการปล่อยให้ "ข้อความที่ถูกต้อง" "ตัวระบุที่สร้างขึ้น" และ "ความสัมพันธ์ที่กำหนด" ยุบลงในเงื่อนไขเดียวที่ไม่ได้ตรวจสอบ
Nil UUID — คำจำกัดความ และเหตุใดการตรวจสอบเวอร์ชันและตัวแปรทุกเวอร์ชันจึงล้มเหลวทางเทคนิค
ในการใช้งานที่ได้รับการตรวจสอบ Nil คือสตริงที่เป็นศูนย์ทั้งหมดตามรูปแบบบัญญัติ ได้รับสาขาเฉพาะก่อนที่จะทดสอบรูปแบบ UUID ปกติ ดังนั้น isValidUuid จะส่งกลับค่าจริง แม้ว่านิพจน์ทั่วไปจะต้องใช้ตัวเลขเวอร์ชันตั้งแต่ 1 ถึง 8 และ RFC-variant nibble จาก 8 ถึง b inspectUuid เป็นไปตามข้อยกเว้นเดียวกัน: รายงานค่าที่ถูกต้อง กำหนดเวอร์ชัน 0 และบอกว่า UUID นั้นเป็นศูนย์บิตทั้งหมดและไม่ใช่แบบสุ่ม นี่เป็นพฤติกรรมของแอปพลิเคชันที่ได้รับการตรวจสอบแล้ว ไม่ใช่การกล่าวอ้างทั่วไปที่ผู้ตรวจสอบทุกคนจะต้องเลือกเหมือนกัน
สาขานั้นมีความสำคัญเนื่องจาก Nil ไม่ผ่านเส้นทางเวอร์ชันและตัวแปรทั่วไปที่ใช้สำหรับตัวระบุที่สร้างขึ้น ค่า ToolAcre version-4 จะมี 4 อยู่ในตำแหน่งเวอร์ชัน และค่าหนึ่งของ 8, 9, a หรือ b อยู่ในตำแหน่งที่ต่างกัน ไม่มีมีศูนย์ทั้งสองแห่ง การเรียกเช็คเหล่านั้นว่า “ล้มเหลว” โดยไม่กล่าวถึงข้อยกเว้นจะทำให้เข้าใจผิด ตัวตรวจสอบจะรับรู้ค่าพิเศษก่อน จากนั้นจึงข้ามรูปแบบปกติโดยการออกแบบ ผู้บริโภคต้องการคำสั่งซื้อที่มองเห็นได้เท่าเทียมกันหากพวกเขายอมรับ
Nil UUID เป็นข้อยกเว้นที่ถูกต้องอย่างชัดเจนใน ToolAcre ซึ่งรายงานเป็นเวอร์ชัน 0
สตริง all-f ffffffff-ffff-ffff-ffff-ffffffffffff ไม่ได้รับสาขาพิเศษในที่เก็บนี้ นอกจากนี้ยังล้มเหลวในรูปแบบปกติเนื่องจาก f อยู่นอกช่วงเวอร์ชันที่ยอมรับและอยู่นอกชุด nibble ตัวแปร RFC ที่ยอมรับ ด้วยเหตุนี้ ToolAcre จึงรายงานว่าไม่เป็นที่ยอมรับ แทนที่จะปฏิบัติเหมือนไม่มี สมุดงานจะระบุประวัติการกำหนดมาตรฐานและวัตถุประสงค์ขอบเขตช่วงเป็น Max แต่ไม่มีบันทึกเครื่องมือ การใช้งาน หรือการทดสอบจะตรวจสอบการอ้างสิทธิ์เหล่านั้น ดังนั้นบทความนี้จึงไม่ทำซ้ำ
ความแตกต่างนี้มีประโยชน์มากกว่าประวัติที่ไม่รองรับ โดย Nil คือค่าคงที่ที่มีชื่อซึ่งมีพฤติกรรมที่ทดสอบแล้ว ในขณะที่ Max เป็นอินพุตที่ตัวตรวจสอบปฏิเสธ โปรเจ็กต์อาจกำหนดซีแมนทิกส์ของ Sentinel เพิ่มเติมในโปรโตคอลของตัวเอง แต่ต้องไม่อนุมานตัวเลือกนั้นจาก ToolAcre หากความสามารถในการทำงานร่วมกันขึ้นอยู่กับการยอมรับค่า all-f ให้จัดทำเอกสารกฎนั้นและทดสอบในระบบที่เป็นเจ้าของ อย่าถือว่าทุกไลบรารีจะจัดประเภทสตริงที่มีรูปทรง UUID เหมือนกัน
ค่าสูงสุด all-f ถูกปฏิเสธโดย ToolAcre; ไม่มีการยืนยันประวัติ RFC หรือการใช้ช่วงที่ตั้งใจไว้
Sentinel และค่า Null จะตอบคำถามที่แตกต่างกันก็ต่อเมื่อสคีมาบอกเช่นนั้น Null สามารถแสดงถึงการไม่มีความสัมพันธ์ได้โดยตรง Sentinel จะเก็บคอลัมน์ไว้และอาจมีประโยชน์เมื่ออินเทอร์เฟซโดยรอบไม่สามารถมีค่าว่างได้ แต่จะสร้างค่าที่ดูเหมือนข้อมูล ดังนั้นจึงเดินทางผ่านดัชนี การรวม ซีเรียลไลเซอร์ และแคช ความสะดวกที่ชัดเจนทำให้ผู้อ่านทุกคนต้องรับผิดชอบ: แต่ละคนต้องจำไว้ว่า UUID ที่ยอมรับนั้นไม่ได้ตั้งชื่อเอนทิตีที่ได้รับมอบหมาย
การค้าขายนั้นจะกลายเป็นกับดักเมื่อผู้เฝ้ายามสามารถตอบสนองการตรวจสอบรูปร่างของคีย์นอกได้โดยไม่ตอบสนองความหมายของความสัมพันธ์ นอกจากนี้ยังสามารถเบลอสถานะที่แตกต่างกัน เช่น ไม่ทราบ ตั้งใจยกเลิกการมอบหมาย ลบ หรือยังไม่ได้ประมวลผล หากสถานะเหล่านั้นส่งผลกระทบต่อพฤติกรรม ให้แสดงสถานะเหล่านั้นอย่างชัดเจน แทนที่จะใช้ตัวระบุเวทมนตร์ตัวเดียวมากเกินไป ในกรณีที่ไม่มีการเก็บรักษาความเข้ากันได้ ให้ระบุความหมายที่บันทึกไว้แก่รัฐ ปฏิเสธมันทุกที่ และแปลงเป็นขอบเขตที่เป็นเจ้าของอย่างชัดเจน แทนที่จะกระจายการเปรียบเทียบทั่วทั้งรหัสธุรกิจ
เครื่องมือตรวจสอบและค่าพิเศษ — เหตุใดการตรวจสอบเวอร์ชันที่เข้มงวด/variant จึงอาจปฏิเสธ Nil และ Max และวิธีตัดสินใจว่าคุณควรตรวจสอบอย่างไร
ToolAcre สาธิตสองชั้นภายในเครื่องมือตรวจสอบความถูกต้องตัวเดียว อินพุตปกติจะถูกตัดออก วงเล็บปีกกาด้านนอกที่เป็นตัวเลือกจะถูกเอาออก และสตริงที่เหลือจะถูกตรวจสอบกับเค้าโครง 8-4-4-4-12 ตามรูปแบบบัญญัติ รวมถึงเวอร์ชันที่ยอมรับและตำแหน่งตัวแปร ไม่มีการทดสอบก่อนรูปแบบนั้นและยอมรับอย่างจงใจ แม็กซ์ไม่มีข้อยกเว้นและล้มเหลว ซึ่งหมายความว่าผู้เรียกไม่สามารถทำนายนโยบายมูลค่าพิเศษจากนิพจน์ทั่วไปเพียงอย่างเดียว โฟลว์การควบคุมที่อยู่รอบรูปแบบเป็นส่วนหนึ่งของสัญญาการตรวจสอบ
ออกแบบนโยบายของคุณเองโดยแยกคำถามสามข้อออกจากกัน ประการแรก ข้อความสามารถจดจำได้ในรูปแบบที่ขอบเขตของคุณอนุญาตหรือไม่ ประการที่สอง ค่านี้เป็นค่า UUID ปกติหรือเป็นข้อยกเว้นที่มีชื่อหรือไม่ ประการที่สาม หมวดหมู่นั้นได้รับอนุญาตสำหรับฟิลด์นี้และการดำเนินการหรือไม่ จุดสิ้นสุดการสร้างอาจปฏิเสธ Nil แม้ว่าตัวแยกวิเคราะห์การวินิจฉัยจะจดจำจุดนั้นได้ ในขณะที่ขอบเขตการนำเข้าอาจแปลเครื่องหมาย Nil ดั้งเดิมที่จัดทำเอกสารไว้เป็นค่าว่าง การส่งคืนผลลัพธ์เหล่านั้นแยกกันจะป้องกันไม่ให้ “parser ยอมรับมัน” จากการอนุญาตโดยไม่ได้ตั้งใจในการจัดเก็บ
ToolAcre ยอมรับ Nil อย่างชัดเจนและปฏิเสธ Max ภายใต้รูปแบบเวอร์ชันและตัวแปร
พิจารณาตารางงานที่มีตัวระบุผู้รับโอนซึ่งใช้ Nil สำหรับ "ไม่ได้มอบหมาย" แบบสอบถามที่เขียนเป็น WHERE Assignee_id IS NOT NULL ดูเหมือนจะเลือกงานที่ได้รับมอบหมาย แต่ยังเลือกทุกแถว Nil เนื่องจาก Sentinel เป็นสตริงที่เป็นรูปธรรม การรวมอาจปล่อยแถวเหล่านั้นถ้าไม่มีผู้ใช้มีคีย์นั้น ทำให้เกิดผลลัพธ์ที่สองที่ชัดเจนน้อยลง ข้อความค้นหาทั้งสองมีความสมเหตุสมผลในท้องถิ่น พวกเขาไม่เห็นด้วยเนื่องจากสคีมาซ่อนสถานะไว้ในตัวระบุที่ดูธรรมดาแทนที่จะเปิดเผยการมอบหมายโดยตรง
การแก้ไขที่คงทนคือการกำหนดโมเดลการมอบหมายเป็นการมอบหมาย: ใช้ความสัมพันธ์ที่เป็นโมฆะเมื่อสัญญาการจัดเก็บข้อมูลอนุญาต หรือเพิ่มสถานะที่ชัดเจนเมื่อต้องแยกแยะหลายสถานะ หากขอบเขตความเข้ากันได้ยังคงส่ง Nil ให้แปลหนึ่งครั้งก่อนที่จะคงอยู่ และย้อนกลับการแมปสำหรับขอบเขตนั้นเท่านั้น จากนั้นทดสอบค่าเวอร์ชัน 4 ที่สร้างขึ้น ไม่มี สูงสุด อินพุตว่าง และข้อความที่มีรูปแบบไม่ถูกต้องเป็นกรณีแยกต่างหาก แอปพลิเคชันควรตัดสินใจแต่ละผลลัพธ์แทนที่จะสืบทอดคำตอบใดก็ตาม การตรวจสอบรูปแบบทั่วไปจะเกิดขึ้นเพื่อส่งคืน
Takeaway: ค่าพิเศษจำเป็นต้องมีการจัดการที่ชัดเจน — สร้าง ID จริงด้วยตัวสร้าง ToolAcre และถือว่า Nil และ Max เป็นข้อยกเว้นโดยเจตนา
ค่าพิเศษจำเป็นต้องมีการจัดการที่มีชื่อเนื่องจากรูปร่างไม่สามารถตอบสนองความต้องการของแอปพลิเคชันของคุณได้ ToolAcre สร้างเวอร์ชันปกติ-4 UUID จาก Web Crypto โดยถอยกลับจาก RandomUUID ไปเป็น getRandomValues เมื่อจำเป็น และปฏิเสธที่จะใช้แหล่งสุ่มที่ไม่ปลอดภัย ผู้ตรวจสอบสามารถแยกแยะค่าที่สร้างขึ้นจากข้อยกเว้น Nil ที่ได้รับการยอมรับอย่างชัดเจน นั่นทำให้เครื่องมือนี้มีประโยชน์สำหรับการสังเกต แต่ไม่ได้เลือกนโยบายผู้ดูแลฐานข้อมูลหรือพิสูจน์ว่าตัวระบุที่ยอมรับนั้นเป็นของบันทึกที่มีอยู่
ใช้ตัวสร้างสำหรับตัวระบุใหม่และถือว่าทุก Sentinel เป็นการตัดสินใจโปรโตคอลที่แยกจากกัน ในตัวตรวจสอบปัจจุบัน Nil ถูกต้อง เวอร์ชัน 0 และไม่ใช่แบบสุ่ม แม็กซ์ถูกปฏิเสธ รักษาความแตกต่างนั้นไว้เมื่อทดสอบเพจ จากนั้นเปรียบเทียบกับกฎของภาษา ฐานข้อมูล และ API ก่อนที่จะยอมรับค่าใดค่าหนึ่ง แนวทางที่ปลอดภัยนั้นจงใจจำกัดให้แคบลง: ID ที่สร้างขึ้น ข้อยกเว้นของโปรแกรมแยกวิเคราะห์ ความสัมพันธ์ที่ขาดหายไป และสถานะธุรกิจเป็นแนวคิดที่แตกต่างกัน และขอบเขตที่แข็งแกร่งทำให้พวกเขาแตกต่าง