Генератор UUID

• UUID v1 поєднує мітку часу з MAC-адресою машини — гарантовано унікальний, але розкриває час створення та апаратну ідентичність, створюючи занепокоєння щодо конфіденційності.
• UUID v3 та v5 є детермінованими хешами: v3 використовує MD5, v5 використовує SHA-1. За однакового простору імен та імені вони завжди створюють однаковий UUID — корисно для генерації узгоджених ідентифікаторів з природних ключів (наприклад, перетворення електронних адрес на ідентифікатори користувачів).
• UUID v4 використовує 122 біти випадкових даних, забезпечуючи найсильнішу гарантію унікальності без витоку будь-якої інформації.
• UUID v7 (RFC 9562, 2024) вбудовує мітку часу Unix у перші 48 бітів, зберігаючи 74 випадкові біти — сортується за часом створення, що робить його ідеальним для первинних ключів баз даних, де важлива продуктивність індексів.

Для більшості додатків v4 є вибором за замовчуванням; переходьте на v7 для первинних ключів баз даних, де важливий порядок вставлення.

UUID v4 використовує 122 випадкові біти, даючи 5,3 × 10^36 можливих значень. Проблема днів народження визначає ймовірність колізії: після генерації 2,7 × 10^18 (2,7 квінльйона) UUID існує 50% шанс однієї колізії.

У практичних термінах, генерація 1 мільярда UUID на секунду протягом 85 років досягає цього порогового значення. У більш реалістичних масштабах — система, яка генерує 1 мільйон UUID на день — ймовірність будь-якої колізії за 100 років становить приблизно 1 до 10^24.

Це передбачає використання належного генератора випадкових чисел (CSPRNG); використання Math.random() у JavaScript (який не є криптографічно безпечним) зменшує ентропію та збільшує ризик колізій. Завжди використовуйте crypto.randomUUID(), бібліотеки uuid v4 або вбудовані в базу даних функції UUID для виробничих систем.

UUID як первинні ключі уможливлюють децентралізовану генерацію ідентифікаторів (програми створюють ідентифікатори без кругових звернень до бази даних) та запобігають атакам перерахунку (користувачі не можуть вгадати ідентифікатори інших записів).

Однак випадкові значення UUID v4 погіршують продуктивність B-дерево індексів — випадкові вставки викликають розбиття сторінок та фрагментацію, збільшуючи підсилення запису у 2–5 разів порівняно з послідовними цілими ключами. UUID v7 вирішує цю проблему за допомогою випадковості з префіксом мітки часу, забезпечуючи як унікальність, так і послідовний порядок.

Вартість зберігання також вища: 16 байтів проти 4–8 байтів для цілих чисел, що є значним у таблицях з мільярдами рядків і кількома індексами.

Поширений шаблон поєднує UUID як публічні ідентифікатори з цілими ключами автоінкременту всередині, об'єднуючи таблиці за ефективним цілим числом і водночас виставляючи лише безпечний UUID для API та URL-адрес.

UUID (універсальний унікальний ідентифікатор) — це 128-бітне значення, розроблене так, щоб бути унікальним у просторі та часі без центрального центру реєстрації, як визначено в IETF RFC 9562 (який замінює попередній RFC 4122).

Його 128 бітів записані як 32 шістнадцяткові символи, згруповані у форматі 8-4-4-4-12, наприклад 550e8400-e29b-41d4-a716-446655440000. Певні біти зарезервовані: 13-й шістнадцятковий символ кодує версію, а верхні біти 17-го шістнадцяткового символу кодують варіант.

Решта бітів містять випадкові дані, мітку часу або хешоване ім'я залежно від версії. Оскільки адресований простір становить 2^122, незалежні генератори можуть безпечно створювати ідентифікатори без будь-якої координації.

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

• У JavaScript функція crypto.randomUUID() повертає UUID версії v4. Вона задокументована на MDN Web Docs як частина Web Crypto API та доступна в сучасних браузерах і Node.js 14.17+.
• У Python стандартний модуль uuid містить uuid.uuid4() для випадкових значень та uuid.uuid1() для значень на основі міток часу.
• У PostgreSQL функція gen_random_uuid() створює UUID версії v4, тоді як MySQL 8 пропонує UUID() для значення у стилі v1.

Усі вони створюють рядки, сумісні з RFC 9562, тому ідентифікатори, згенеровані в одній мові, без проблем працюють в іншій.

Так, GUID та UUID — це той самий 128-бітний ідентифікатор; GUID (Globally Unique Identifier) — це просто термінологія Microsoft для стандартного UUID, визначеного стандартом IETF RFC 9562. Вони двійково сумісні, тому значення, створене у Windows або .NET, може використовуватися будь-якою системою, сумісною з RFC, і навпаки.

Єдина звична відмінність полягає у форматуванні: інструменти Microsoft часто беруть значення у фігурні дужки, наприклад {550e8400-e29b-41d4-a716-446655440000}, а деякі старі API COM використовували великі літери для шістнадцяткових значень.

Непомітний нюанс полягає у порядку байтів — двійковий GUID від Microsoft зберігає перші три поля у форматі little-endian, що має значення лише під час синтаксичного аналізу «сирих» байтів, а не для канонічного рядкового формату з дефісами.

UUID не є секретом і ніколи не повинен сприйматися як такий, навіть якщо його випадкові біти надходять із криптографічно безпечного генератора. RFC 9562 прямо застерігає, що UUID не мають вбудованого захисту і не повинні вважатися важкими для вгадування; OWASP також застерігає від використання ідентифікаторів як токенів авторизації.

Версія 4 генерує 122 біти з CSPRNG, тому її практично неможливо передбачити, але версії 1 та 7 містять мітки часу, які розкривають час створення, а версії 3 та 5 є детермінованими хешами відомого простору імен та імені.

Для токенів сеансів, скидання паролів або ключів API генеруйте спеціальні секрети з високою ентропією, замість того щоб покладатися на структуру UUID для захисту.

Поля версії та варіанта — це фіксовані бітові шаблони, вбудовані в кожен UUID за стандартом RFC 9562, які повідомляють парсерам, як було згенеровано значення.

Версія займає чотири старші біти сьомого байта (13-та шістнадцяткова цифра), тому UUID версії v4 завжди має там цифру 4, а v7 — завжди 7. Варіант розташовується у двох або трьох старших бітах дев'ятого байта (17-та шістнадцяткова цифра), що для стандартного варіанта IETF робить цю цифру однією з таких: 8, 9, a або b.

Саму тому дійсний UUID версії v4 відповідає шаблону xxxxxxxx-xxxx-4xxx-[89ab]xxx-xxxxxxxxxxxx. Перевірка цих фіксованих позицій є правильним способом перевірки або класифікації UUID, а не поверхнева перевірка довжини.

Масова генерація UUID корисна для заповнення баз даних початковими даними, створення тестових наборів, тестування на навантаження та наповнення макетів API, і цей інструмент може видавати безліч дійсних ідентифікаторів в один клік. Оскільки кожен UUID створюється незалежно з випадкового джерела або джерела міток часу згідно з RFC 9562, генерування пакету не несе помітного ризику колізій навіть при великій кількості.

Для повторюваних тестових даних віддавайте перевагу детермінованим UUID версії 5, похідним від фіксованого простору імен та імені, щоб той самий вхідний рядок завжди давав однаковий ідентифікатор під час різних запусків.

Під час заповнення таблиць виробничого масштабу розгляньте версію 7, щоб масово вставлені рядки потрапляли приблизно в послідовному порядку індексу, що зберігає сторінки B-дерева компактними та зменшує підсилення запису під час імпорту.

Зберігайте UUID у рідному 16-байтовому двійковому типі, коли ваша база даних це підтримує, оскільки збереження їх як 36-символьного тексту марнує більш ніж удвічі більше простору та сповільнює порівняння індексів. PostgreSQL надає спеціальний тип стовпця uuid, тоді як MySQL та SQL Server зазвичай використовують BINARY(16) з функціями перетворення в рядок з дефісами та з нього.

Як зазначається в RFC 9562, UUID не залежать від регістру символів і мають бути нормалізовані — зазвичай до нижнього регістру — перед збереженням, щоб пошук залишався послідовним.

Якщо ви використовуєте UUID як первинні ключі, віддавайте перевагу версії 7 для збереження локальності вставки; якщо ви мусите використовувати версію 4, деякі рушії дозволяють переставляти байти мітки часу, хоча версія 7 є стандартизованим рішенням тієї самої проблеми фрагментації.

Найпоширеніша помилка з UUID — це використання некриптографічного джерела випадкових чисел, такого як Math.random() у JavaScript, яке не є CSPRNG і може створювати упереджені або передбачувані значення; MDN натомість рекомендує crypto.randomUUID() або Web Crypto API.

Інші часті помилки включають:

• сприйняття нульового UUID (усі нулі) за справжній ідентифікатор
• припущення, що UUID достатньо секретні для авторизації доступу
• збереження їх як тексту, коли 16-байтовий двійковий стовпець був би набагато ефективнішим

Розробники також несумісно змішують версії або покладаються на версію 1 у контекстах, де важлива конфіденційність, оскільки вбудована мітка часу та історична MAC-адреса розкривають інформацію. Нарешті, порівняння UUID з урахуванням регістру призводить до хибних невідповідностей, оскільки RFC 9562 визначає їх як нечутливі до регістру.