UUID v4 Generator

Generate cryptographically random UUID v4

Форматувати

Кількість:

UUID v4 — найпоширеніша версія UUID у сучасному програмному забезпеченні. На відміну від своїх аналогів, що беруть біти з часової мітки або хешу простору імен, UUID v4 побудований повністю на випадкових даних — що робить його найпростішим і найуніверсальнішим вибором, коли потрібен унікальний ідентифікатор без будь-яких метаданих про його походження.

Цей генератор використовує crypto.randomUUID() — нативний API браузера та Node.js, що отримує ентропію з криптографічно захищеного генератора випадкових чисел операційної системи — того самого джерела, що використовується для ключового матеріалу TLS.

Що таке UUID v4?

Universally Unique Identifier (UUID) — це 128-бітна мітка, стандартизована в RFC 4122. Зазвичай представляється як 32 шістнадцяткові цифри, згруповані дефісами за шаблоном 8-4-4-4-12:

550e8400-e29b-41d4-a716-446655440000

В UUID v4 122 із 128 бітів є випадковими. Решта 6 бітів — фіксовані поля, передбачені специфікацією: 4 біти кодують версію (0100 = 4) і 2 біти кодують варіант RFC 4122 (10). Саме тому третя група завжди починається з 4, а четверта — з 8, 9, a або b.

Анатомія UUID v4

Розбір 550e8400-e29b-41d4-a716-446655440000:

СегментБітиЗначення
550e840032 випадковихtime_low (назва історична — повністю випадкове у v4)
e29b16 випадковихtime_mid (історична назва — повністю випадкове у v4)
41d44 фіксованих + 12 випадковихВерсійний ніббл 4 (двійкове 0100) + 12 випадкових бітів
a7162 фіксованих + 14 випадковихБіти варіанта 10 (старші біти першого байта) + 14 випадкових бітів
44665544000048 випадковихnode (повністю випадкове у v4)
Note:Ніббл варіанта на початку четвертої групи завжди дорівнює 8, 9, a або b — тому що два старших біти цього байта зафіксовані на 10 (маркер варіанта RFC 4122), залишаючи два інші вільними.

UUID v4 та інші версії

RFC 4122 визначає п'ять версій UUID. Кожна вирішує свою задачу:

UUID v1Часова мітка + MAC

Поєднує 60-бітну часову мітку (інтервали 100 наносекунд з жовтня 1582 р.) з MAC-адресою хоста. Монотонно зростає в межах однієї машини.

Use when: вам потрібні впорядковані за часом ID і ви не проти розкриття ідентифікатора сервера та часу генерації.

UUID v3Хеш MD5

Детермінований: однакові простір імен + ім'я завжди дають однаковий UUID. Використовує хешування MD5.

Use when: вам потрібні відтворювані ID з відомого простору імен (наприклад, DNS-імена). Переважно v5 над v3.

UUID v4Випадковий

122 біти криптографічно захищеної випадковості. Без часової мітки, MAC-адреси чи простору імен. Найпоширеніший вибір загального призначення.

Use when: вам потрібні унікальні ID без структурного змісту та з максимальною конфіденційністю.

UUID v5Хеш SHA-1

Як v3, але використовує SHA-1. Так само детермінований від простору імен + імені.

Use when: вам потрібні відтворювані ідентифікатори з адресацією за вмістом (наприклад, стабільні ID для ресурсів, ідентифікованих URL).

UUID v7Впорядкований за часом випадковий

Новіший (RFC 9562, 2024). Кодує Unix-часову мітку в мілісекундах у старших бітах, потім випадкові біти. Сортований і зручний для баз даних.

Use when: вам потрібні ID, зручні для індексів БД, з природним часовим упорядкуванням (переважно v1 для нових проектів).

Коли використовувати UUID v4

UUID v4 — правильний інструмент у переважній більшості ситуацій, коли потрібен просто «унікальний ID» без додаткових обмежень:

ID користувачів та акаунтів

Непрозорі ID користувачів, що не розкривають нічого про час створення акаунта або ідентифікатор сервера. Не піддаються перерахуванню або вгадуванню.

Первинні ключі баз даних

Працює з будь-яким рушієм БД. UUID v4 безпечно генерувати на стороні клієнта та поєднувати з розподілених джерел без координації.

ID сесій і токенів

122 біти випадковості роблять перебір практично неможливим — за стійкістю порівнюється з 122-бітним випадковим токеном.

Назви файлів та об'єктів

Безпечні від дублювання назви файлів для завантажень, ключі об'єктів S3 або записи кешу.

Ключі ідемпотентності

Генеруйте UUID на клієнті перед відправкою запиту. Сервер може безпечно дедублювати повторні запити без спільного лічильника.

Кореляція та ID трасування

Додавайте UUID до кожного рядка журналу та відрізка розподіленого трасування. Не потрібна координація між сервісами.

Note:Якщо ваш варіант використання потребує сортованих ID (наприклад, рядки в БД мають кластеризуватись за часом вставки), розгляньте UUID v7. UUID v4 навмисно випадковий і спричинить фрагментацію індексу B-tree при інтенсивних вставках.

Ймовірність колізії

При 122 випадкових бітах простір UUID v4 містить 2122 ≈ 5,3 × 1036 можливих значень. Ймовірність колізії відповідає задачі про парадокс днів народження:

Згенеровано UUIDЙмовірність колізії
1 мільярд (109)~1 із 5,3 × 1018
1 трильйон (1012)~1 із 5,3 × 1012
1018 (обсяг екзабайта)~1 із 5 300

Широко відомий орієнтир: щоб отримати 50% ймовірність однієї колізії, потрібно згенерувати приблизно 2,71 × 1018 UUID. При швидкості 1 мільярд UUID на секунду це займе приблизно 85 років безперервної генерації.

Приклади коду

JavaScript — Браузер і Node.js 14.17+

Метод crypto.randomUUID() доступний нативно у всіх сучасних браузерах і Node.js 14.17+. Встановлення пакетів не потрібне.

js
// Browser or Node.js 14.17+
const id = crypto.randomUUID()
// → "110e8400-e29b-41d4-a716-446655440000"

// Generate multiple
const ids = Array.from({ length: 5 }, () => crypto.randomUUID())

Node.js — старіші версії (пакет uuid)

js
const { v4: uuidv4 } = require('uuid')

const id = uuidv4()
// → "110e8400-e29b-41d4-a716-446655440000"

Python

python
import uuid

# Generate a UUID v4
id = str(uuid.uuid4())
# → '110e8400-e29b-41d4-a716-446655440000'

# The uuid module uses os.urandom() — cryptographically secure
print(uuid.uuid4().hex)  # without hyphens
# → '110e8400e29b41d4a716446655440000'

Go

go
import "github.com/google/uuid"

id := uuid.New().String()
// → "110e8400-e29b-41d4-a716-446655440000"

// Or using the standard library (Go 1.20+ with math/rand/v2 is NOT cryptographic)
// Always prefer github.com/google/uuid for production use

Rust

toml
# Cargo.toml
[dependencies]
uuid = { version = "1", features = ["v4"] }
rust
use uuid::Uuid;

let id = Uuid::new_v4().to_string();
// → "110e8400-e29b-41d4-a716-446655440000"

Часті запитання

Чи є UUID v4 криптографічно захищеним?

UUID v4 сам по собі не є примітивом безпеки — це формат ідентифікатора. Однак при генерації через crypto.randomUUID() базова ентропія є криптографічно захищеною. Не використовуйте генератори UUID на основі Math.random() у контекстах, критичних для безпеки.

Чи можуть два UUID v4 коли-небудь бути рівними?

Теоретично так, але практично ні. Ймовірність генерації дубліката в будь-якому реалістичному наборі даних є астрономічно малою.

UUID v4 vs nanoid — що обрати?

Обидва є генераторами випадкових ID з CSPRNG. Ключові відмінності:

  • UUID v4 відповідає стандарту RFC 4122, розпізнається кожною БД і фреймворком, не потребує залежностей (нативний crypto.randomUUID()).
  • nanoid використовує URL-безпечний алфавіт і коротший за замовчуванням (21 символ проти 36). Потребує npm-пакет.

Надавайте перевагу UUID v4 для сумісності із зовнішніми системами. nanoid — для коротших ID.

Зберігати UUID як рядки чи бінарно в базах даних?

Для більшості БД зберігання як UUID або BINARY(16) ефективніше, ніж VARCHAR(36). PostgreSQL має нативний тип uuid. MySQL і MariaDB — BINARY(16). SQLite — TEXT.

Навіщо в UUID v4 дефіси — і чи можна їх опустити?

Дефіси є частиною канонічного представлення UUID (RFC 4122), але суто косметичні. Без них отримуємо компактний 32-символьний шістнадцятковий рядок. Більшість парсерів UUID приймають обидва формати.

js
const id = crypto.randomUUID()              // "550e8400-e29b-41d4-a716-446655440000"
const compact = id.replaceAll('-', '')     // "550e8400e29b41d4a716446655440000"