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:
В UUID v4 122 із 128 бітів є випадковими. Решта 6 бітів — фіксовані поля, передбачені специфікацією: 4 біти кодують версію (0100 = 4) і 2 біти кодують варіант RFC 4122 (10). Саме тому третя група завжди починається з 4, а четверта — з 8, 9, a або b.
Анатомія UUID v4
Розбір 550e8400-e29b-41d4-a716-446655440000:
| Сегмент | Біти | Значення |
|---|---|---|
| 550e8400 | 32 випадкових | time_low (назва історична — повністю випадкове у v4) |
| e29b | 16 випадкових | time_mid (історична назва — повністю випадкове у v4) |
| 41d4 | 4 фіксованих + 12 випадкових | Версійний ніббл 4 (двійкове 0100) + 12 випадкових бітів |
| a716 | 2 фіксованих + 14 випадкових | Біти варіанта 10 (старші біти першого байта) + 14 випадкових бітів |
| 446655440000 | 48 випадкових | node (повністю випадкове у v4) |
8, 9, a або b — тому що два старших біти цього байта зафіксовані на 10 (маркер варіанта RFC 4122), залишаючи два інші вільними.UUID v4 та інші версії
RFC 4122 визначає п'ять версій UUID. Кожна вирішує свою задачу:
Поєднує 60-бітну часову мітку (інтервали 100 наносекунд з жовтня 1582 р.) з MAC-адресою хоста. Монотонно зростає в межах однієї машини.
Use when: вам потрібні впорядковані за часом ID і ви не проти розкриття ідентифікатора сервера та часу генерації.
Детермінований: однакові простір імен + ім'я завжди дають однаковий UUID. Використовує хешування MD5.
Use when: вам потрібні відтворювані ID з відомого простору імен (наприклад, DNS-імена). Переважно v5 над v3.
122 біти криптографічно захищеної випадковості. Без часової мітки, MAC-адреси чи простору імен. Найпоширеніший вибір загального призначення.
Use when: вам потрібні унікальні ID без структурного змісту та з максимальною конфіденційністю.
Як v3, але використовує SHA-1. Так само детермінований від простору імен + імені.
Use when: вам потрібні відтворювані ідентифікатори з адресацією за вмістом (наприклад, стабільні ID для ресурсів, ідентифікованих URL).
Новіший (RFC 9562, 2024). Кодує Unix-часову мітку в мілісекундах у старших бітах, потім випадкові біти. Сортований і зручний для баз даних.
Use when: вам потрібні ID, зручні для індексів БД, з природним часовим упорядкуванням (переважно v1 для нових проектів).
Коли використовувати UUID v4
UUID v4 — правильний інструмент у переважній більшості ситуацій, коли потрібен просто «унікальний ID» без додаткових обмежень:
ID користувачів та акаунтів
Непрозорі ID користувачів, що не розкривають нічого про час створення акаунта або ідентифікатор сервера. Не піддаються перерахуванню або вгадуванню.
Первинні ключі баз даних
Працює з будь-яким рушієм БД. UUID v4 безпечно генерувати на стороні клієнта та поєднувати з розподілених джерел без координації.
ID сесій і токенів
122 біти випадковості роблять перебір практично неможливим — за стійкістю порівнюється з 122-бітним випадковим токеном.
Назви файлів та об'єктів
Безпечні від дублювання назви файлів для завантажень, ключі об'єктів S3 або записи кешу.
Ключі ідемпотентності
Генеруйте UUID на клієнті перед відправкою запиту. Сервер може безпечно дедублювати повторні запити без спільного лічильника.
Кореляція та ID трасування
Додавайте UUID до кожного рядка журналу та відрізка розподіленого трасування. Не потрібна координація між сервісами.
Ймовірність колізії
При 122 випадкових бітах простір UUID v4 містить 2122 ≈ 5,3 × 1036 можливих значень. Ймовірність колізії відповідає задачі про парадокс днів народження:
Широко відомий орієнтир: щоб отримати 50% ймовірність однієї колізії, потрібно згенерувати приблизно 2,71 × 1018 UUID. При швидкості 1 мільярд UUID на секунду це займе приблизно 85 років безперервної генерації.
Приклади коду
JavaScript — Браузер і Node.js 14.17+
Метод crypto.randomUUID() доступний нативно у всіх сучасних браузерах і Node.js 14.17+. Встановлення пакетів не потрібне.
// 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)
const { v4: uuidv4 } = require('uuid')
const id = uuidv4()
// → "110e8400-e29b-41d4-a716-446655440000"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
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
# Cargo.toml
[dependencies]
uuid = { version = "1", features = ["v4"] }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 приймають обидва формати.
const id = crypto.randomUUID() // "550e8400-e29b-41d4-a716-446655440000"
const compact = id.replaceAll('-', '') // "550e8400e29b41d4a716446655440000"