أدوات المطور · مولد UUID
من 128 Bits إلى 36 الأحرف: كيف يعمل UUID ترميز النص
· كيف يعمل
uuid التشفير متصفح API
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 حرفًا: ثمانية أرقام سداسية، واصلة، أربعة أرقام سداسية، واصلة، أربعة أرقام سداسية، واصلة، أربعة أرقام سداسية، واصلة، اثني عشر رقمًا سداسيًا.
يضاعف النظام السداسي كل شيء — يصبح كل بايت حرفين، وأربعة شرطات تكمل 36
يصبح كل بايت حرفين سداسيين عشريين بالضبط (0–9, a–f). توجد الواصلات لأسباب تتعلق بسهولة القراءة والإرث منذ أن تم تحديد UUIDs لأول مرة. يضاعف الترميز السداسي العشري عدد البايتات: 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). يتم استخدام Base58 بواسطة Bitcoin وغيرها من سلاسل الكتل ويزيل الأحرف الغامضة (0، O، I، l)، مما يجعل النتيجة 22–23 أحرفًا بينما تظل قابلة للقراءة. يستخدم Crockford base32 (المصمم للتنسيقات المشابهة للمجموع الاختباري ISBN) أحرفًا تبلغ 26 ويعطي الأولوية للصحة على الإيجاز. ينطبق اعتراض ترتيب البايت GUID لـ Microsoft على تخزين UUID في بعض قواعد البيانات. RFC 9562 يحدد ترتيب بايت الشبكة (النهاية الكبيرة) لجميع البايتات. تقوم بعض تكوينات خادم Microsoft SQL بتخزين المعرفات الفريدة العمومية (GUIDs) بترتيب بايت صغير في الحقول الثلاثة الأولى.
الترميزات الأقصر — base64url عند 22 من الأحرف، وbase58 وCrockford base32، مع مقايضاتها في سهولة القراءة وأمان النسخ واللصق
نفس قيمة 128 ذات البتات المخزنة في النهاية الكبيرة والنهاية الصغيرة تنتج سلاسل سداسية عشرية مختلفة. قد يتم استرداد UUID 550e8400-e29b-41d4-a716-446655440000 المخزن كملف Microsoft GUID كـ 00840e55-9be2-d441-a716-446655440000 (بايت 0–3 و4–5 و6–7 معكوس). إذا كان نظامك يربط بين أنظمة RFC المتوافقة وأنظمة Microsoft، فيجب أن تكون على دراية بهذا وتقوم إما بالتطبيع عند الحدود أو مستند التنسيق الذي تستخدمه في كل عمود. مثال عملي: الإصدار 4 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 ذات نهاية صغيرة، بحيث يمكن طباعة نفس البايتات كسلسلتين مختلفتين
يحفظ Base64url 14 من الأحرف؛ سيوفر base58 نفس المبلغ تقريبًا؛ الست عشري هو المعيار. اختر بناءً على حالة الاستخدام الخاصة بك: إذا ظهر المعرف في عناوين URL وكان كل حرف مهمًا، فاستخدم base64url؛ إذا ظهر في السجلات وواجهات المستخدم حيث يقرأه البشر، فاستخدم النموذج الأساسي السداسي العشري؛ إذا كنت تقوم ببناء نظام blockchain أو نظام موزع حيث يكون المجموع الاختباري مهمًا، فاستخدم base58 أو Crockford base32. عند اختيار نوع عمود، قم بتخزين القيمة التي تعمل على تحسين نمط الوصول الفعلي الخاص بك. إذا كنت تستعلم عن UUID بشكل متكرر وتحتاج إلى مطابقة غير حساسة لحالة الأحرف، فقم بتخزين الملف الثنائي (16) واترك قاعدة البيانات تتعامل مع التمثيل. إذا قمت بالاستعلام عن طريق سلسلة فرعية (البحث عن UUIDs التي تبدأ ببادئة)، يكون النظام الست عشري أكثر قابلية للقراءة في إخراج التصحيح.
مثال عملي - معرف واحد مكتوب على شكل بايتات، وشكل سداسي عشري أساسي ونموذج مختصر، يوضح كل خطوة تحويل
إذا قمت بالتصدير إلى CSV وأرسلت بريدًا إلكترونيًا إلى مستخدمين غير تقنيين، فسيكون من السهل التعرف على النظام الست عشري. إذا كانت المساحة محدودة (تطبيق جوال مزود بذاكرة تخزين مؤقت محلية)، فإن base64url أو base58 يحفظ النطاق الترددي. يقوم المولد ToolAcre بإخراج تنسيق سداسي عشري مكون من 36 للأحرف؛ إذا كنت بحاجة إلى ترميز مختلف، فسيظل التحقق الجيد يعمل لأنه يقوم بتطبيع أي تمثيل صالح قبل التحقق من التنسيق. تعتبر اعتبارات الأداء مهمة عند تشفير أو فك تشفير الملايين من UUIDs. يعد التشفير السداسي العشري أمرًا بسيطًا: قم بتحويل كل بايت إلى حرفين في O(1) مرة لكل بايت. فك التشفير بسيط بنفس القدر. يستخدم تشفير وفك تشفير Base64 جداول البحث وهي أبطأ قليلاً (تقريبًا 2–3x أبطأ من السداسية لكل بايت، اعتمادًا على الأجهزة والتنفيذ). Base58 أبطأ بشكل ملحوظ لأنه في الأساس تحويل أساسي ويتطلب حسابًا معياريًا.
ما لا يغطيه هذا - اختيارات أعمدة قاعدة البيانات مثل أنواع uuid الأصلية مقابل الثنائي (16)، والتي تتم تغطيتها بشكل منفصل
إذا كان نظامك يقوم بتشفير أو فك تشفير UUIDs في حلقة فعالة (إنشاء معرف عالي التردد، تصدير مجمع)، فإن النظام السداسي العشري يكون أسرع. إذا كان التشفير يحدث بشكل غير متكرر وكان توفير 14 للأحرف مهمًا، فإن base64url يعد مقايضة معقولة. يقوم المولد ToolAcre بإخراج سداسي عشري، لذلك تحصل على ميزة الأداء دون التضحية بالتوافق. تختلف دلالات مقارنة السلسلة حسب الترميز. يمكن مقارنة UUID الست عشرية كسلاسل: 550e8400-e29b-41d4-a716-446655440000 < 550e8400-e29b-41d4-a716-446655440001 (تعمل المقارنة المعجمية). يمكن مقارنة UUIDs الثنائية بالبايت: مقارنة البايت بالبايت هي نفس المقارنة الرقمية. ومع ذلك، فإن معرفات UUID المشفرة Base64url وbase58 لا تحافظ على الترتيب الرقمي في مقارنة السلسلة المعجمية. إذا كان نظامك يعتمد على الفرز المعجمي لمعرفات UUID (وهو نمط شائع بشكل مدهش لبناء الفهارس أو مفاتيح قاعدة البيانات)، فيجب عليك إما استخدام متغير UUID قابل للفرز (الإصدار 6 أو الإصدار 7).
الوجبات الجاهزة: احتفظ بالنموذج المتعارف عليه عند الحدود - يقوم المولد ToolAcre بإخراج معرفات UUID القياسية المكونة من أحرف 36 ويقبل فحصه السلاسل بهذا النموذج
يقوم المولد ToolAcre حاليًا بإنتاج v4 UUIDs، والتي لا يمكن فرزها حسب ترتيب التشفير. تتطلب إمكانية التشغيل البيني توحيد المعايير على ترميز واحد. يجب على النظام الذي يقبل UUIDs بالصيغة السداسية وbase64 وbase58 في وقت واحد أن يقوم بتطبيع جميع المدخلات إلى نموذج أساسي قبل المعالجة. وهذا ممكن ولكنه يزيد من التعقيد. قد تتطلب واجهات برمجة التطبيقات أو قواعد البيانات الخارجية ترميزًا محددًا: بعض واجهات برمجة التطبيقات تتوقع urn:uuid: سداسي عشري مسبوق، والبعض الآخر يتوقع سداسي عشري بدون واصلة، ويتوقع البعض الآخر base64url. قم بتوثيق توقع تشفير UUID لنظامك بوضوح في عقود API. يُخرج المولد ToolAcre دائمًا الشكل السداسي الأساسي؛ إذا كنت بحاجة إلى ترميزات أخرى، فقم بإجراء التحويل بشكل صريح وقم بتوثيق المفاضلات (المساحة والأداء وسهولة القراءة وإمكانية الفرز) للفريق.