أدوات المطور · مولد UUID
GUID مقابل UUID: شرح الأقواس وترتيب البايت والمتغيرات من Microsoft
· خلفية
uuid التشفير متصفح API
GUID هو اسم Microsoft لـ UUID، ولكن يمكن للأقواس الكبيرة والأحرف الكبيرة وترتيب البايت أن يجعل نفس المعرف يبدو مختلفًا عبر الأنظمة الأساسية. يشرح هذا المنشور كل اختلاف وكيفية المقارنة بأمان.
نفس المعرف الذي فشل في المطابقة عبر الأنظمة - تختلف خدمة .NET وخدمة Java على سجل واحد
تقوم خدمة .NET بإنشاء GUID وترسلها إلى خدمة Java، التي تحاول مطابقة القيمة مع UUID من PostgreSQL. تفشل مقارنة السلسلة، وتبلغ الأنظمة عن عدم تطابق المعرفات، على الرغم من أن الخدمات الثلاث تعمل بنفس 16 bytes الأساسي. تبدو الاختلافات تجميلية - الأقواس، والغلاف، وترتيب البايت - ولكنها تتسبب في فشل مقارنات السلاسل وإرباك نقاط التكامل التي لا يتم تسويتها عند الحدود. GUID عبارة عن مصطلحات Microsoft لما يطلق عليه RFC 9562 UUID: معرف 128 بت بنفس تخطيط البت. يشير الاسمان إلى نفس البنية الأساسية، لكن التمثيل يختلف بطرق تفاجئ المطورين. إن فهم مصدر الارتباك يمنع أخطاء التكامل.
GUID هو UUID — تنسيق 128 بت المشترك ومن أين جاء اختلاف التسمية
GUID يرمز إلى المعرف الفريد العمومي والمعرف الفريد العمومي وهو الاسم الذي تستخدمه Microsoft لما تسميه معايير RFC بـ UUID. تخطيط 128-بت ونظام الإصدار/variant متطابقان. RFC 4122 و RFC 9562 تحديد تنسيق UUID والمعنى؛ تقوم Microsoft بتنفيذها وتستخدم المصطلح GUID. يعد اختلاف التسمية تاريخيًا: استخدمت Microsoft GUID قبل أن يتم توحيد UUIDs بواسطة النظام IETF، وظلت مصطلحات Microsoft عالقة داخل النظام البيئي .NET. على مستوى البتات، GUID وUUID قابلان للتبادل تمامًا. على مستوى التنسيق، تختلف في العرض: غالبًا ما يكتب كود .NET المعرفات الفريدة العمومية (GUID) بأقواس وأحرف كبيرة، بينما تستخدم معرفات UUID الأساسية RFC أحرفًا صغيرة وبدون أقواس.
الأقواس والأحرف الكبيرة - نموذج التسجيل {XXXXXXXX-...} وكيفية تطبيعه
تتم كتابة UUID بالنموذج RFC الأساسي على هيئة ثمانية وأربعة وأربعة وأربعة واثني عشر حرفًا سداسيًا عشريًا صغيرًا مفصولة بواصلات: 550e8400-e29b-41d4-a716-446655440000. يتم عرض .NET GUID بشكل تقليدي بأقواس وأحرف كبيرة: {550E8400-E29B-41D4-A716-446655440000}. تأتي الأقواس من تنسيق تسجيل Windows؛ الأحرف الكبيرة هي اصطلاح العرض. يمثل كلا النموذجين 128 bits المتطابقين. لمطابقة GUID من .NET مع UUID من PostgreSQL، قم بإزالة الأقواس وقم بتسوية الغلاف، ثم قارن بين السلاسل. ToolAcre الشيك جيد الصياغة يقبل النموذج المتعارف عليه ويزيل الأقواس تلقائيًا. التطبيع هو تحويل بسيط للنص يحافظ على كل المعنى.
ترتيب البايت المختلط - كيف يتم تخزين الحقول الثلاثة الأولى في البنية GUID، ولماذا يختلف Guid.ToByteArray عن ترتيب البايت RFC
الفرق الخطير بين GUID وUUID هو ترتيب البايت. RFC 9562 يحدد أن الحقول الثلاثة الأولى (8، 4، و4 المجموعات السداسية العشرية) يتم تخزينها بترتيب بايت كبير (الشبكة). .NET تقوم بنية الدليل بتخزين الحقول الثلاثة الأولى في النهاية الصغيرة: يتم عكس البايتات قبل الكتابة إلى وحدة التخزين. نفس 16 bytes، عند كتابتها بواسطة .NET Guid.ToByteArray() وتفسيرها بواسطة كود متوافق مع RFC، تنتج تمثيلات نصية مختلفة تمامًا. A 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 نموذج صفيف البايت باستخدام اصطلاح 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، ويظل الباقي في النهاية الكبيرة. مجموعة البايت الكاملة هي 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 وفهرستها وفرزها ودعمها الأصلي. تكتشف بعض قواعد البيانات الإصدار والبتات المتغيرة تلقائيًا، بينما تتطلب قواعد البيانات الأخرى تعريفات صريحة للنوع ومعالجة ترتيب البايت على الحدود بين الأنظمة والتخزين.
الخلاصة: التطبيع عند الحدود — يقبل الاختيار ToolAcre النموذج الأساسي، وهو الشكل الذي يجب توحيده عند تبادل المعرفات
قم بالتطبيع عند الحدود عندما تعبر المعرفات حدود النظام .NET/non-.NET. قم بإزالة الأقواس، وقم بتطبيع الغلاف بشكل متسق، وقم بتبديل الحقول الثلاثة الأولى بالبايت إذا كانت البايتات تأتي من .NET Guid.ToByteArray(). النموذج RFC المتعارف عليه هو المعيار المرجعي: ثمانية، وأربعة، وأربعة، وأربعة، واثني عشر حرفًا سداسيًا عشريًا صغيرًا مع واصلات، بدون أقواس، وترتيب بايت كبير. عند التبادل مع أنظمة .NET، وافق على نموذج موحد وقم بتطبيق التحويلات بشكل صريح في رمز التكامل. قم بتوثيق معالجة ترتيب البايت واختبار التحويلات بدقة. أوجه التشابه الأساسية بين GUID وUUID تعني أن معظم 128 bits متطابقة.