> uuidv7 generator <
// معرّفات UUID مرتّبة زمنيًا وقابلة للفرز (RFC 9562، 2024) — طابع زمني Unix بالمللي ثانية بطول 48 بت + 74 بت عشوائيًا، تُنشأ محليًا
// فك تشفير / فحص UUIDV7
الصق أي معرّف UUID أدناه لاستخراج طابعه الزمني المضمّن وإصداره ونوعه. يعمل مع v7 ويبلّغ إذا كان الإدخال إصدار UUID مختلفًا.
UUIDv7 متوافق مع المواصفة
يطبّق تنسيق UUID المرتّب زمنيًا من RFC 9562 (مايو 2024): طابع زمني Unix بالمللي ثانية بطول 48 بت، إصدار 7 بطول 4 بت، rand_a بطول 12 بت، نوع بطول 2 بت، rand_b بطول 62 بت. مُتحقَّق منه مقابل متجهات اختبار المواصفة.
ترتيب فرز زمني
افرز عدديًا أو معجميًا فتحصل على ترتيب الإدراج — مثالي للمفاتيح الأساسية في شجرة B وفهارس السلاسل الزمنية وربط السجلات. لا مزيد من انقسامات صفحات v4 العشوائية أو الفهارس المجزأة.
الرتابة ضمن المللي ثانية نفسها
عند وقوع عدة معرّفات UUID في مللي ثانية واحدة، يُزاد الجزء العشوائي بصرامة لكي يبقى الإخراج مرتّبًا ضمن تلك المللي ثانية. أوقفه لاستخدام الطريقة 1 العادية من RFC 9562 (الملء العشوائي) إن كنت تفضّل ذلك.
افحص أي UUIDv7
الصق معرّف UUID من النوع v7 فيستخرج المفكّك الطابع الزمني المضمّن (مللي ثانية + ISO 8601) وبتات الإصدار وبتات النوع وحقلَي rand_a / rand_b. مفيد لتصحيح الأخطاء وفحص السجلات القديمة ومسارات التدقيق.
// حول UUIDV7
كيف يعمل UUIDv7:
إن UUIDv7 معرّف بطول 128 بت مُرتَّب على الشكل unix_ts_ms (48) | ver (4) | rand_a (12) | var (2) | rand_b (62). أول 48 بت هي طابع Unix الزمني الحالي بالمللي ثانية، بترتيب big-endian، مما يجعل المعرّف UUID متزايدًا بشكل رتيب مع الزمن. الـ 4 بتات التالية تشفّر الإصدار (ثنائيًا 0111 = عشريًا 7)، لذا تبدأ المجموعة الثالثة المفصولة بالشرطات دائمًا بالرقم 7. الحقل rand_a هو 12 بتًا عشوائيًا تُستخدم لدقة دون المللي ثانية أو كإنتروبيا إضافية. حقل النوع البالغ 2 بت ثابت على 10 (لذا يكون أول حرف في المجموعة الرابعة دائمًا 8 أو 9 أو a أو b). الـ 62 بتًا المتبقية (rand_b) تأتي من crypto.getRandomValues() في كل عملية إنشاء. الإنتروبيا الإجمالية لكل معرّف UUID هي 74 بتًا عشوائيًا، وهو مقاوم للتصادم عند أي معدل إنشاء واقعي.
مثال:
018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55 (ts=2024-05-08T15:00:00.000Z)
المعايير والمراجع:
- >RFC 9562 — Universally Unique IDentifiers (UUIDs)، مايو 2024 (يلغي RFC 4122، ويعرّف v6/v7/v8)
- >RFC 4122 — مواصفة UUID الأصلية لعام 2005 (لا تزال مرجعية لـ v1-v5)
- >Web Crypto API (W3C) — مولّد
crypto.getRandomValues()CSPRNG المستخدَم للـ 74 بتًا العشوائية - >سلوك
gen_random_uuid()في PostgreSQL (v4 افتراضيًا، v7 في امتدادات pgcrypto / النسخ المتفرّعة) - >draft-peabody-dispatch-new-uuid-format — اقتراح v6/v7/v8 الأصلي الذي أصبح RFC 9562
لماذا تستخدم UUIDv7:
- >مفاتيح أساسية لقواعد البيانات مع محلية الإدراج — تبقى الصفحات ممتلئة ولا تتجزأ الفهارس
- >يحل محل زوج التسلسل + UUID: عمود واحد، قابل للفرز ومُعرَّف فريد عالميًا في آنٍ معًا
- >يحل محل مفاتيح v4 الأساسية في الجداول كثيرة الكتابة لمعالجة مشكلة انقسام الصفحات عند الإدراج العشوائي
- >معرّفات ربط السجلات التي تُفرز حسب وقت الإنشاء دون الحاجة إلى عمود طابع زمني منفصل
- >الأنظمة الموزّعة التي يحتاج فيها عدة كُتّاب إلى معرّفات مرتّبة دون منسّق
- >مصادر الأحداث (event sourcing) / سجلات الإلحاق فقط حيث يكون الترتيب الزمني هو الفهرس الطبيعي
- >مفاتيح S3 / تخزين الكائنات حيث يطابق فرز البادئة ترتيب الإدراج
- >يحل محل Snowflake / KSUID / ULID حيثما يُفضَّل التنسيق القياسي
أدوات ذات صلة:
- >مولّد UUID — يُنشئ v4 (عشوائي) وv1 (طابع زمني) عندما لا تحتاج إلى ترتيب فرز v7
- >مولّد GUID — المعرّف نفسه تحت تسمية مايكروسوفت
- >محوّل الطابع الزمني — يحوّل مللي ثانية Unix المضمّنة إلى الوقت المحلي / ISO 8601
- >محوّل Epoch — افحص جزء الطابع الزمني البالغ 48 بت في أي منطقة زمنية
- >مولّد كلمات المرور — رموز عشوائية تشفيريًا عندما لا تكون قابلية الفرز مطلوبة
// أمثلة على الإخراج
معرّف UUIDv7 واحد أُنشئ الآن
count=1, format=standard, timestamp=current
output:
018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55
دفعة بكمية كبيرة مع الرتابة ضمن المللي ثانية نفسها
count=5, format=standard, monotonic=on
output:
018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a56 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a57 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a58 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a59
طابع زمني تاريخي مخصّص — تعبئة رجعية لعملية ترحيل
count=1, timestamp=custom, value=1577836800000 (2020-01-01)
output:
016f5e66-e800-7c9a-b403-2f1d4a7c91ee
تنسيق مدمج لعناوين URL / أسماء الملفات
count=1, format=no-hyphens
output:
018f5c2e90c07a4fb6ee8dfe3c2b0a55
معرّف UUIDv7 مفكوك — افحص الحقول المضمّنة
input = 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55
output:
ts_ms = 1715180400000 ISO = 2024-05-08T15:00:00.000Z ver = 7 var = 10 (RFC 4122) rand_a = 0xa4f rand_b = 0x36ee8dfe3c2b0a55
// طبّقه بنفسك
تمتلك معظم اللغات إما مساعدًا في المكتبة القياسية أو تطبيقًا في ملف واحد لـ UUIDv7 منذ صدور RFC 9562 في عام 2024. فيما يلي الوصفات المعيارية التي يمكنك إدراجها في قاعدة شيفرتك — في JS للمتصفح وNode.js وGo وPython وPostgreSQL.
UUIDv7 في JS متصفح/Node نقي — بنية RFC 9562
function uuidv7() {
const ts = BigInt(Date.now());
const rand = new Uint8Array(10);
crypto.getRandomValues(rand);
const b = new Uint8Array(16);
b[0] = Number((ts >> 40n) & 0xFFn);
b[1] = Number((ts >> 32n) & 0xFFn);
b[2] = Number((ts >> 24n) & 0xFFn);
b[3] = Number((ts >> 16n) & 0xFFn);
b[4] = Number((ts >> 8n) & 0xFFn);
b[5] = Number( ts & 0xFFn);
b[6] = (rand[0] & 0x0F) | 0x70; // version = 7
b[7] = rand[1];
b[8] = (rand[2] & 0x3F) | 0x80; // variant = RFC 4122
for (let i = 9; i < 16; i++) b[i] = rand[i - 6];
const h = Array.from(b, x => x.toString(16).padStart(2,'0')).join('');
return `${h.slice(0,8)}-${h.slice(8,12)}-${h.slice(12,16)}-${h.slice(16,20)}-${h.slice(20)}`;
}
// usage:
const id = uuidv7();
console.log(id); // -> '018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55'
// generate a batch and verify chronological sort:
const batch = Array.from({ length: 5 }, uuidv7);
batch.sort(); // sorts by creation time without a separate timestampNode.js v26.1.0 فأحدث — crypto.randomUUIDv7() المدمجة
import { randomUUIDv7 } from 'node:crypto';
// Added in Node.js v26.1.0 (2026-05-07).
// Returns an RFC 9562 version 7 UUID. The first 48 bits encode a
// millisecond Unix timestamp; the rest is CSPRNG output.
const id = randomUUIDv7();
// -> '018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55'
// The CSPRNG output is cached for performance: Node generates enough
// entropy upfront for the next ~128 UUIDs. Pass disableEntropyCache: true
// when you need each call to draw fresh randomness, e.g. directly after
// a fork() or in tight high-security loops.
const freshId = randomUUIDv7({ disableEntropyCache: true });
// IMPORTANT: per the Node docs, "the embedded timestamp relies on a
// non-monotonic clock and is not guaranteed to be strictly increasing."
// If two UUIDs land in the same millisecond OR the system clock steps
// backwards, the IDs may not sort in creation order. Use a userland
// monotonic-v7 library (e.g. uuidv7 on npm) when strict ordering matters.Go — google/uuid v1.6 فأحدث يوفّر UUIDv7 أصليًا
package main
import (
"fmt"
"github.com/google/uuid"
)
func newID() uuid.UUID {
id, err := uuid.NewV7()
if err != nil {
panic(err)
}
return id
}
func main() {
id := newID()
fmt.Println(id.String()) // 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55
fmt.Println(id.Time()) // embedded creation timestamp
}Python 3.13 فأحدث — uuid.uuid7() من المكتبة القياسية
import uuid
# Python 3.13 added uuid7() and uuid8() to the standard library.
uid = uuid.uuid7()
print(uid) # 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55
print(uid.version) # 7
# For older Python use the 'uuid7' or 'uuid-utils' PyPI packages, or:
# from uuid_extensions import uuid7PostgreSQL 18 فأحدث — دالة uuidv7() الأصلية
-- PG 18 ships uuidv7() natively. Use it as a primary key default:
CREATE TABLE events (
id uuid PRIMARY KEY DEFAULT uuidv7(),
body jsonb,
ts timestamptz NOT NULL DEFAULT now()
);
-- For older Postgres, install the pg_uuidv7 extension or generate client-side.
-- Migration tip: keep INDEX on (id) only — v7 already sorts chronologically,
-- so a separate (created_at) index is usually redundant.// المزالق الشائعة
> يكشف UUIDv7 وقت الإنشاء — لا تستخدمه للرموز المبهمة
أول 48 بت من أي v7 هي طابع زمني Unix بالمللي ثانية. يمكن لأي شخص يرى المعرّف UUID فك تشفير وقت إنشاء السجل، ومعدل إصدار المعرّفات، و(مع عدة عيّنات) تقدير ساعة الخادم تقريبًا. هذا مقبول للمفاتيح الأساسية الداخلية لقواعد البيانات ومعرّفات السجلات، لكن لعناوين إعادة تعيين كلمة المرور وروابط المشاركة ومعرّفات الجلسة أو رموز الدعوة، استخدم بدلًا من ذلك UUIDv4 أو سلسلة عشوائية مُنشأة بواسطة CSPRNG.
> تراجع الساعة يكسر الرتابة
إذا قفزت ساعة النظام إلى الوراء (خطوة NTP، ترحيل آلة افتراضية، ثانية كبيسة)، فقد تنتج معرّفات v7 المُنشأة ببساطة قيمًا تُفرز قبل المعرّفات الصادرة سابقًا. توصي RFC 9562 §6.2 بالطريقة 2 (عشوائي رتيب): تتبّع آخر معرّف UUID مُنشأ، وعندما لا يتقدّم الطابع الزمني، زد الجزء العشوائي بدلًا من ذلك. مفتاح الرتيب في هذه الأداة يقوم بذلك تمامًا.
> v7 ليس بديلًا مباشرًا لـ v4 في السياقات الحساسة أمنيًا
كثيرًا ما يُعتمد على المعرّفات التي تبدو عشوائية (v4) كرموز حامل عن طريق الخطأ: «إذا عرفت المعرّف UUID، يمكنك قراءة الصف». يمتلك v7 فقط 74 بتًا عشوائيًا وبادئة طابع زمني يمكن التنبؤ بها، وهو ما يبقى مقاومًا للتصادم لكنه يوفّر قابلية للتنبؤ أقل بكثير من 122 بتًا عشوائيًا في v4. إذا كان شيء ما يُعامَل كصلاحية (capability)، فأنشئ رمزًا تشفيريًا منفصلًا بدلًا من إعادة استخدام المفتاح الأساسي v7.
> تعمل مقارنة السلاسل فقط بالشكل ذي الأحرف الصغيرة والشرطات
يعتمد الفرز الزمني لـ v7 على المقارنة المعجمية للسلسلة المعيارية المؤلفة من 36 حرفًا بالأحرف الصغيرة — أو على المقارنة بايتًا ببايت للقيمة الأساسية البالغة 16 بايتًا. خلط الأحرف الكبيرة والصغيرة، أو إزالة الشرطات في منتصف الطريق، أو تخزين بعض الصفوف محاطة بـ {...} وأخرى بدونها، كل ذلك سينتج ترتيب فرز لم يعد يطابق وقت الإنشاء. اختر شكلًا معياريًا واحدًا لكل عمود وافرضه بقيد CHECK.
> يدور الطابع الزمني البالغ 48 بت في عام 10889
إن 2^48 مللي ثانية تساوي تقريبًا 8,925 عامًا بعد حقبة Unix — يفيض حقل الطابع الزمني في 2 أغسطس 10889 بالتوقيت العالمي UTC. إذا كانت شيفرتك تفترض أن الطابع الزمني المضمّن يقع في نطاق معقول، فاضبط الحد الأعلى على 281,474,976,710,655 مللي ثانية (الحد الأقصى الذي يمكن أن يحمله عدد صحيح بلا إشارة بطول 48 بت) بدلًا من ترميز عام قريب في المستقبل سيكون خاطئًا بعد قرن.
>> الأسئلة الشائعة
س: ما هو UUIDv7؟
ج: UUIDv7 معرّف بطول 128 بت مُعرَّف في RFC 9562 (مايو 2024) يجمع طابعًا زمنيًا Unix بالمللي ثانية بطول 48 بت مع 74 بتًا من العشوائية وبتات الإصدار + النوع القياسية. والنتيجة معرّف فريد عالميًا يُفرز أيضًا زمنيًا حسب وقت الإنشاء — أفضل ما في العالمين. صُمِّم خصيصًا لمعالجة معاناة فهارس قواعد البيانات الناجمة عن مفاتيح UUIDv4 الأساسية العشوائية، حيث يقع كل إدراج في صفحة شجرة B مختلفة ويسبّب تضخّمًا هائلًا في الكتابة.
س: كيف يختلف UUIDv7 عن UUIDv4؟
ج: UUIDv4 عشوائي بالكامل (122 بتًا عشوائيًا) وليس له بنية تتجاوز حقلَي الإصدار + النوع. معرّفان من v4 أُنشئا بفارق ميكروثانية يُفرزان إلى مواضع متباعدة جدًا، وهو أمر رائع لعدم القابلية للتنبؤ لكنه سيّئ لفهارس شجرة B. يضع UUIDv7 طابعًا زمنيًا Unix بالمللي ثانية بطول 48 بت في المقدمة، لذا فإن معرّفات v7 المُنشأة في أوقات متقاربة تُفرز أيضًا متقاربة في التخزين. المقايضة: يكشف v7 وقت الإنشاء وله فقط 74 بتًا عشوائيًا بدلًا من 122 — لا يزال مقاومًا للتصادم، لكنه غير مناسب كرمز سري.
س: هل ينبغي أن أنتقل من UUIDv4 إلى UUIDv7؟
ج: للمفاتيح الأساسية الداخلية لقواعد البيانات في الجداول كثيرة الكتابة — نعم، في معظم الأحيان. يمكن أن يفوق تجزّؤ الفهارس الذي يسببه v4 تكلفة الاستعلامات نفسها، خصوصًا في PostgreSQL أو MySQL مع فهارس InnoDB المُجمَّعة. أما للرموز المعروضة للمستخدمين أو المضمّنة في عناوين URL أو المُعامَلة كصلاحيات («إذا عرفت المعرّف UUID يمكنك الوصول إلى المورد»)، فأبقِ على v4 أو استخدم رمزًا عشوائيًا منفصلًا — فـ v7 يكشف وقت الإنشاء. النمط الشائع هو مفاتيح v7 الأساسية لعمليات الربط الداخلية مع slug عشوائي منفصل لعنوان URL العام.
س: هل UUIDv7 هو نفسه ULID أو KSUID أو Snowflake؟
ج: متشابهة مفاهيميًا — جميعها الأربعة معرّفات مرتّبة زمنيًا — لكن تخطيطات البتات والترميزات تختلف. يستخدم ULID ترميز Crockford base32 وتخطيط مللي ثانية مختلفًا. يرمّز KSUID طابعًا زمنيًا بطول 32 بت + حمولة بطول 128 بت كـ 27 حرفًا base62. أما Snowflake فهو معرّف بطول 64 بت خاص بتويتر مع معرّفات للعُمّال. UUIDv7 هو المكافئ القياسي من IETF، مُرمَّز بالشكل الست عشري المعياري 8-4-4-4-12، بحيث تفهمه بالفعل كل مكتبة UUID ونوع UUID في قواعد البيانات وبرنامج تشغيل JDBC/ODBC. إذا كنت تبدأ من الصفر في 2025 وما بعده، ففضّل v7 — فهو المعيار.
س: كم معرّف UUIDv7 يمكنني إنشاؤه في المللي ثانية قبل حدوث التصادمات؟
ج: ضمن مللي ثانية واحدة، توفّر التفرّد فقط الـ 74 بتًا العشوائية (12 في rand_a + 62 في rand_b). وفقًا لحدّ تصادم عيد الميلاد، يمكنك إنشاء نحو 2^37 ≈ 137 مليار معرّف v7 في المللي ثانية نفسها قبل بلوغ احتمال تصادم بنسبة 50% — أي بلا حدود فعليًا لأي نظام واقعي. وعبر المللي ثانية، يميّز الطابع الزمني نفسه، لذا فإن خطر التصادم العالمي على مدى عمر النظام لا يُذكر. وعند تشغيل مفتاح الرتيب، تكون التصادمات ضمن المللي ثانية صفرًا بحكم التصميم (يُزاد الجزء العشوائي).
س: هل يمكنني استخراج الطابع الزمني من UUIDv7؟
ج: نعم — الطابع الزمني هو أول 48 بت، أي أول 12 حرفًا ست عشريًا بعد إزالة الشرطات. اجمع المجموعات الثلاث الأولى المفصولة بالشرطات (8 + 4 = 12 hex digits)، وحلّلها كعدد صحيح ست عشري، فتحصل على طابع Unix الزمني بالمللي ثانية. استخدم المفكّك أعلاه للقيام بذلك تفاعليًا، أو في الشيفرة: parseInt(uuid.replace(/-/g,'').slice(0,12), 16). النتيجة هي لحظة المللي ثانية التي أُنشئ فيها المعرّف UUID، بدقة ساعة النظام في ذلك الوقت.
س: كيف يبدو رقم الإصدار في UUIDv7؟
ج: تبدأ المجموعة الثالثة المفصولة بالشرطات دائمًا بالرقم 7. على سبيل المثال: 018f5c2e-90c0-7a4f-b6ee-8dfe3c2b0a55. وتبدأ المجموعة الرابعة دائمًا بـ 8 أو 9 أو a أو b — وهي القيم الأربع الممكنة عندما يكون أعلى بتّين 10 (نوع RFC 4122). إذا لم يكن رقم الإصدار 7، فإن المعرّف UUID من إصدار آخر (عادةً 4 للعشوائي أو 1 لـ v1 المبني على الوقت) ولن يُفرز زمنيًا.
س: هل يدعم PostgreSQL / MySQL معرّف UUIDv7 أصليًا؟
ج: يوفّر PostgreSQL 18 (الصادر في سبتمبر 2025) الدالة uuidv7() كدالة مدمجة. تحتاج الإصدارات الأقدم إلى امتداد pg_uuidv7 أو الإنشاء من جانب العميل. لا يمتلك MySQL 8.x v7 أصليًا؛ استخدم المساعد UUID_TO_BIN(uuid, 1) (الذي يبدّل بايتات الطابع الزمني لأجل ترتيب الفرز) لـ v1 فقط — أما لـ v7 فأنشئه من جانب العميل. يتوقع كل من SQL Server وOracle وSQLite إنشاء v7 من جانب العميل. تدعم معظم أدوات الربط الكائني العلائقي ORM (Hibernate وEntity Framework وSequelize وPrisma وSQLAlchemy) الآن v7 إما أصليًا أو عبر مكوّن إضافي.
س: هل خيار الرتابة متوافق مع RFC 9562؟
ج: نعم. تصف RFC 9562 §6.2 صراحةً ثلاث طرق لضمان الترتيب ضمن المللي ثانية: (1) الملء العشوائي، (2) العشوائي الرتيب — زيادة عدّاد عندما لا يتقدّم الطابع الزمني، (3) دقة الطابع الزمني دون المللي ثانية. ينفّذ مربع الاختيار الرتيب في هذه الأداة الطريقة 2: عندما يتشارك معرّفان UUID الطابع الزمني نفسه البالغ 48 بت، يُضبط الجزء العشوائي للثاني على previous_random + 1 بدلًا من سحبه من جديد. وهذا يضمن ترتيبًا صارمًا للإنشاء بالدفعات مع البقاء متوافقًا تمامًا مع المواصفة.
س: هل تُرسَل بياناتي إلى أي مكان؟
ج: لا. يحدث كل إنشاء وفك تشفير وفرز ونسخ وتنزيل لـ UUIDv7 بالكامل في متصفحك كـ JavaScript خالص. لا تجري الصفحة أبدًا أي طلب شبكة عند النقر على إنشاء أو فك تشفير أو نسخ أو تنزيل — يمكنك التحقق من ذلك عبر علامة تبويب الشبكة في أدوات المطوّر بمتصفحك. لا نسجّل الطوابع الزمنية أو البذور المخصّصة أو معرّفات UUID المُنشأة أو المخرجات المفكوكة. الصفحة نفسها HTML ثابت يُقدَّم من شبكة CDN، لذا لا يصل أي إدخال إلى بنيتنا التحتية أبدًا. وهذا يجعل الأداة آمنة للاستخدام مع معرّفات قواعد بيانات الإنتاج أو السجلات الداخلية أو أي بيانات أخرى تفضّل ألا تمرّ عبر خادم طرف ثالث.
س: هل يمكنني استخدام UUIDv7 في Java / .NET / Rust؟
ج: نعم. لدى Java الحزمة com.fasterxml.uuid:java-uuid-generator 5.0 فأحدث، وJDK 21 يدعمه عبر مساعدات المكتبة. يوفّر .NET 9 الدالة Guid.CreateVersion7() في BCL. تستخدم Rust الدالة Uuid::now_v7() من حزمة uuid خلف علامة الميزة v7. تمتلك معظم المنظومات الأخرى (Elixir وRuby وPHP وSwift وKotlin) حزمًا جيدة الصيانة أيضًا — ابحث عن «uuidv7» أو «uuid v7» في سجل حزم اللغة. تنسيق النقل متطابق عبرها جميعًا، لذا يمكن لـ JavaScript تحليل معرّف v7 المُنشأ في Go واستخراج طابعه الزمني دون أي تحويل.
س: هل لدى Node.js مولّد UUIDv7 مدمج؟
ج: نعم — اعتبارًا من Node.js v26.1.0 (الصادر في 2026-05-07) تكشف المكتبة القياسية الدالة crypto.randomUUIDv7([options]). استوردها على النحو import { randomUUIDv7 } from 'node:crypto' واستدعِها بلا وسائط للحصول على سلسلة UUID من النوع v7 وفق RFC 9562. الخيار الوحيد المدعوم هو disableEntropyCache (قيمة منطقية، الافتراضي false)؛ افتراضيًا يخزّن Node مسبقًا ما يكفي من البيانات العشوائية لإنشاء الـ 128 معرّفًا التالية تقريبًا، وهو التحسين نفسه المستخدَم في crypto.randomUUID(). تحذير مهم من الوثائق الرسمية: «يعتمد الطابع الزمني المضمّن على ساعة غير رتيبة وليس مضمونًا أن يكون متزايدًا بشكل صارم». بعبارة أخرى، قد لا يُفرز معرّفان UUID أُنشئا في المللي ثانية نفسها، أو أي معرّفات UUID أُنشئت عبر خطوة NTP / انحراف ساعة آلة افتراضية إلى الوراء، حسب ترتيب الإنشاء. إذا كنت بحاجة إلى رتابة صارمة ضمن المللي ثانية، فاستخدم تطبيقًا من فضاء المستخدم يتبع RFC 9562 §6.2 الطريقة 2 (حزمة uuidv7 على npm، أو هذه الأداة مع تشغيل مفتاح الرتيب).
س: كيف أخزّن UUIDv7 بكفاءة في قاعدة بيانات؟
ج: خزّنه كنوع ثنائي بطول 16 بايتًا بدلًا من سلسلة بطول 36 حرفًا — فتوفّر 20 بايتًا لكل صف، وتنصّف حجم الفهرس، وتكسب مسار مقارنة أسرع. استخدم نوع uuid في PostgreSQL، أو BINARY(16) في MySQL، أو uniqueidentifier في SQL Server، أو BLOB في SQLite. أضف قيد CHECK يفرض أن نِبل الإصدار يساوي 7 إن أردت الإلزام. مع v7 تتجمّع الصفوف طبيعيًا حسب وقت الإنشاء، لذا يكفي عادةً فهرس تغطية على (uuid_pk) — ولا تحتاج إلى فهرس (created_at) منفصل للاستعلامات الزمنية.