เครื่องมือสำหรับนักพัฒนา · ตัวสร้าง UUID
GUID กับ UUID: อธิบายวงเล็บปีกกา, ลำดับไบต์และตัวแปรของ Microsoft
· พื้นหลัง
uuid การเข้ารหัส เบราว์เซอร์-apis
GUID เป็นชื่อของ Microsoft สำหรับ UUID แต่เครื่องหมายปีกกา ตัวพิมพ์ใหญ่ และลำดับไบต์สามารถทำให้ตัวระบุเดียวกันดูแตกต่างกันในแต่ละแพลตฟอร์ม โพสต์นี้จะอธิบายความแตกต่างแต่ละข้อและวิธีเปรียบเทียบอย่างปลอดภัย
ID เดียวกันซึ่งไม่สามารถจับคู่ข้ามระบบได้ — บริการ .NET และบริการ Java ที่ไม่เห็นด้วยกับหนึ่งบันทึก
บริการ .NET สร้าง GUID และส่งไปยังบริการ Java ซึ่งพยายามจับคู่ค่ากับ UUID จาก PostgreSQL การเปรียบเทียบสตริงล้มเหลว และระบบรายงานว่าตัวระบุไม่ตรงกัน แม้ว่าบริการทั้งสามจะทำงานกับ 16 bytes พื้นฐานเดียวกันก็ตาม ความแตกต่างที่ดูเหมือนเป็นเรื่องสวยงาม เช่น วงเล็บปีกกา กรอบ ลำดับไบต์ แต่สิ่งเหล่านี้ทำให้การเปรียบเทียบสตริงล้มเหลว และสร้างความสับสนให้กับจุดการรวมที่ไม่ทำให้เป็นมาตรฐานที่ขอบเขต GUID เป็นคำศัพท์ของ Microsoft สำหรับสิ่งที่ RFC 9562 เรียก UUID: ตัวระบุ 128 บิตที่มีเค้าโครงบิตเดียวกัน ทั้งสองชื่ออ้างถึงโครงสร้างพื้นฐานเดียวกัน แต่การเป็นตัวแทนแตกต่างกันในลักษณะที่ทำให้นักพัฒนาประหลาดใจ การทำความเข้าใจว่าความสับสนเกิดขึ้นที่ใดจะช่วยป้องกันข้อบกพร่องในการรวมระบบ
GUID คือ UUID — รูปแบบ 128 บิตที่ใช้ร่วมกัน และที่มาของความแตกต่างในการตั้งชื่อ
GUID ย่อมาจาก Globally Unique Identifier และ Globally Unique Identifier และเป็นชื่อที่ Microsoft ใช้สำหรับสิ่งที่มาตรฐาน RFC เรียกว่า UUID โครงร่าง 128 บิตและระบบเวอร์ชัน /variant เหมือนกัน RFC 4122 และ RFC 9562 ระบุรูปแบบและความหมาย UUID Microsoft นำไปใช้และใช้คำว่า GUID ความแตกต่างในการตั้งชื่อถือเป็นอดีต: Microsoft ใช้ GUID ก่อนที่ UUID จะได้รับมาตรฐานโดย IETF และคำศัพท์เฉพาะของ Microsoft ติดอยู่ในระบบนิเวศ .NET ที่ระดับบิต GUID และ UUID สามารถใช้แทนกันได้อย่างสมบูรณ์ ในระดับการจัดรูปแบบ การนำเสนอมีความแตกต่างกัน: โค้ด .NET มักจะเขียน GUID ด้วยเครื่องหมายปีกกาและอักษรตัวพิมพ์ใหญ่ ในขณะที่ RFC UUID ตามรูปแบบบัญญัติจะใช้ตัวพิมพ์เล็กและไม่มีเครื่องหมายปีกกา
วงเล็บปีกกาและตัวพิมพ์ใหญ่ - แบบฟอร์ม {XXXXXXXX-...} สไตล์รีจิสทรีและวิธีทำให้เป็นมาตรฐาน
UUID ในรูปแบบมาตรฐาน RFC เขียนเป็นอักขระเลขฐานสิบหกตัวพิมพ์เล็ก 8, 4, สี่, สี่ และ 12 ตัว คั่นด้วยเครื่องหมายขีดกลาง: 550e8400-e29b-41d4-a716-446655440000 .NET GUID จะแสดงตามปกติด้วยเครื่องหมายปีกกาและตัวพิมพ์ใหญ่: {550E8400-E29B-41D4-A716-446655440000} วงเล็บปีกกามาจากรูปแบบ Windows Registry; ตัวพิมพ์ใหญ่เป็นแบบแผนการแสดงผล ทั้งสองรูปแบบแสดงถึง 128 bits ที่เหมือนกัน หากต้องการจับคู่ GUID จาก .NET กับ UUID จาก PostgreSQL ให้ถอดเครื่องหมายปีกกาออกและทำให้ปลอกเป็นมาตรฐาน จากนั้นเปรียบเทียบสตริง ToolAcre เช็คที่มีรูปแบบถูกต้องยอมรับรูปแบบมาตรฐานและจะลบเครื่องหมายปีกกาออกโดยอัตโนมัติ การทำให้เป็นมาตรฐานคือการแปลงข้อความเล็กน้อยที่คงความหมายทั้งหมดไว้
ลำดับไบต์แบบผสม - วิธีจัดเก็บสามฟิลด์แรกแบบ little-endian ในโครงสร้าง GUID และเหตุใด Guid.ToByteArray จึงแตกต่างจากลำดับไบต์ RFC
ความแตกต่างที่เป็นอันตรายระหว่าง GUID และ UUID คือลำดับไบต์ RFC 9562 ระบุว่าสามฟิลด์แรก (8, 4 และ 4 กลุ่มเลขฐานสิบหก) จะถูกจัดเก็บไว้ในลำดับไบต์ขนาดใหญ่ (เครือข่าย) .NET โครงสร้าง Guid จะจัดเก็บสามฟิลด์แรกในรูปแบบ little-endian: ไบต์จะถูกกลับรายการก่อนที่จะเขียนลงหน่วยเก็บข้อมูล 16 bytes เดียวกันนี้ เมื่อเขียนโดย .NET Guid.ToByteArray() และตีความด้วยโค้ดที่สอดคล้องกับ RFC จะสร้างการแสดงข้อความที่แตกต่างไปจากเดิมอย่างสิ้นเชิง UUID 550e8400-e29b-41d4-a716-446655440000 ในลำดับไบต์ RFC จะถูกจัดเก็บเป็นไบต์ 55 0e 84 00 e2 9b 41 d4 a7 16 44 66 55 44 00 00
รูปแบบดั้งเดิมของ Microsoft — c หรือ d ในอักขระตัวแรกของกลุ่มที่สี่หมายถึงอะไร
นอกเหนือจากลำดับไบต์แล้ว ตัวระบุ Microsoft แบบเดิมบางครั้งยังใช้ช่องรูปแบบที่ไม่เป็นมาตรฐานอีกด้วย โดยที่ RFC 9562 ระบุว่าอักขระตัวแรกของกลุ่มที่สี่ต้องเป็น 8, 9, a หรือ b Microsoft GUID รุ่นเก่าอาจใช้ c, d, e หรือ f สิ่งเหล่านี้ยังคงเป็น UUID ที่ถูกต้อง แต่สอดคล้องกับรูปแบบเดิมที่มีมาก่อนมาตรฐาน RFC หากคุณพบ GUID ที่มี c หรือ d ในอักขระตัวแรกของกลุ่มที่สี่ คุณจะมีค่า 128 บิตที่ถูกต้อง ซึ่งไม่สอดคล้องกับบิตตัวแปร RFC สมัยใหม่ .NET สร้าง GUID ที่สอดคล้องกับ RFC ดังนั้นตัวระบุใหม่ไม่ควรแสดงปัญหานี้ บิตตัวแปรแบบเดิมนั้นหายากแต่มีความสำคัญที่ต้องจดจำ
ตัวอย่างการทำงาน — 16 bytes เดียวกันที่เรนเดอร์ในลำดับ RFC และในลำดับโครงสร้าง GUID แสดงว่าอักขระตัวใดสลับกัน
ใช้ UUID 550e8400-e29b-41d4-a716-446655440000 และแปลงเป็น .NET GUID ไบต์รูปแบบอาร์เรย์โดยใช้แบบแผน little-endian ในลำดับ RFC ไบต์คือ: ฟิลด์แรก (550e8400) เท่ากับ 55 0e 84 00 ฟิลด์ที่สอง (e29b) เท่ากับ e2 9b ฟิลด์ที่สาม (41d4) เท่ากับ 41 d4 ฟิลด์ที่สี่และห้าเท่ากับ a7 16 44 66 55 44 00 00 ใน .NET little-endian: ช่องแรกกลายเป็น 00 84 0e 55 ช่องที่สองกลายเป็น 9b e2 ช่องที่สามกลายเป็น d4 41 และส่วนที่เหลือยังคงอยู่ใน big-endian อาร์เรย์ไบต์เต็มคือ 00 84 0e 55 9b e2 d4 41 a7 16 44 66 55 44 00 00. หากระบบ Java อ่านไบต์เหล่านี้โดยคาดหวังลำดับ RFC ระบบจะตีความว่าเป็น 00840e55-9be2-d441-a716-446655440000
สิ่งนี้ไม่ครอบคลุม — SQL NEWSEQUENTIALID ของเซิร์ฟเวอร์ และการสั่งซื้อ ซึ่งเป็นหัวข้อการจัดเก็บข้อมูลของตนเอง
SQL การทำงานของฟังก์ชัน NEWSEQUENTIALID ของเซิร์ฟเวอร์และคุณสมบัติการจัดลำดับตัวระบุเฉพาะคือเลเยอร์พื้นที่เก็บข้อมูลและหัวข้อเฉพาะของฐานข้อมูล โพสต์นี้เน้นที่รูปแบบและความแตกต่างของลำดับไบต์ในระดับแอปพลิเคชันและการทำให้เป็นอนุกรม ปัญหาการจัดการ UUID เฉพาะฐานข้อมูลเชิงลึกและลำดับไบต์ได้รับการแก้ไขอย่างดีที่สุดในเอกสารประกอบเฉพาะสำหรับแพลตฟอร์มฐานข้อมูลนั้น ระบบฐานข้อมูลที่แตกต่างกันมีแนวทางและแนวทางที่แตกต่างกันในการจัดเก็บข้อมูล UUID การทำดัชนี การเรียงลำดับ และการสนับสนุนดั้งเดิม ฐานข้อมูลบางแห่งตรวจพบเวอร์ชันและบิตของตัวแปรโดยอัตโนมัติ ในขณะที่ฐานข้อมูลอื่นๆ ต้องการการประกาศประเภทที่ชัดเจนและการจัดการลำดับไบต์ที่ขอบเขตระหว่างระบบและพื้นที่เก็บข้อมูล
Takeaway: ทำให้เป็นมาตรฐานที่ขอบเขต — เช็ค ToolAcre ยอมรับรูปแบบ Canonical ซึ่งเป็นรูปร่างที่จะสร้างมาตรฐานเมื่อแลกเปลี่ยน ID
ทำให้เป็นมาตรฐานที่ขอบเขตเมื่อตัวระบุข้ามขอบเขตระบบ .NET/non-.NET ถอดเครื่องหมายปีกกา ทำให้เคสเป็นมาตรฐานอย่างสม่ำเสมอ และสลับไบต์สามฟิลด์แรกหากไบต์มาจาก .NET Guid.ToByteArray() รูปแบบ RFC ตามรูปแบบบัญญัติเป็นมาตรฐานอ้างอิง: อักขระเลขฐานสิบหกตัวพิมพ์เล็ก 8, สี่, สี่, สี่ และสิบสองตัวพร้อมเครื่องหมายยติภังค์ ไม่มีวงเล็บปีกกา ลำดับไบต์ขนาดใหญ่ เมื่อทำการแลกเปลี่ยนกับระบบ .NET ให้ยอมรับแบบฟอร์มมาตรฐานและใช้การแปลงอย่างชัดเจนในโค้ดการรวม การจัดการลำดับไบต์ของเอกสารและทดสอบการแปลงอย่างละเอียด ความคล้ายคลึงพื้นฐานหลักระหว่าง GUID และ UUID หมายความว่า 128 bits ส่วนใหญ่เหมือนกัน