Генератор UUID v4

Генератор UUID v4, це безплатний інструмент для створення універсального унікального ідентифікатора версії 4, який можна використовувати як ідентифікатор запису, об'єкта або запиту.

Як генератор UUID v4 обробляє мої дані?

Генерація відбувається на сервері. Вхідні дані передаються на нього через HTTPS і не зберігаються. Тому було б неправильно стверджувати, що весь процес виконується у браузері або що дані ніколи не залишають твій пристрій.

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

Що таке UUID v4?

UUID v4, це 128-бітний ідентифікатор, змінна частина якого генерується випадково або псевдовипадково. Кілька бітів зарезервовано для позначення версії та варіанта UUID. Його часто використовують, коли різним системам потрібно створювати ідентифікатори, не звертаючись спочатку до центрального сервісу по наступний доступний номер.

Стандартний запис містить 32 шістнадцяткові символи, розділені дефісами на п'ять груп. Він відповідає шаблону 8-4-4-4-12 і має довжину 36 символів разом із чотирма дефісами.

Приклад синтаксично правильного значення: 550e8400-e29b-41d4-a716-446655440000. В UUID версії 4 першим символом третьої групи є 4. Два старші біти, які визначають варіант, мають значення 10, тому першим шістнадцятковим символом четвертої групи буде 8, 9, a або b.

Це значення є ідентифікатором, а не закодованою інформацією. З нього не можна відновити дату створення, ім'я облікового запису, адресу пристрою чи порядковий номер.

Яку версію UUID вибрати?

Вибирай версію 4, якщо потрібен незалежно згенерований непрозорий ідентифікатор і однакові вхідні дані не мають давати однаковий результат. Якщо коротко, v1 використовує час та інформацію про вузол, v2 є форматом DCE Security, v3 створює UUID із простору імен та імені за допомогою MD5, v4 генерується випадково, v5 використовує SHA-1, v6 змінює порядок даних на основі часу, v7 поєднує часову позначку Unix із випадковими даними, а v8 призначена для експериментальних форматів або форматів конкретних постачальників.

• Використовуй UUID v4 для ідентифікаторів записів, посилань на завантаження, ідентифікаторів запитів API та тестових даних, якщо підходять випадково розподілені ідентифікатори.
• Використовуй UUID v5, коли певна комбінація простору імен та імені завжди має давати той самий ідентифікатор. Це зручно для повторюваного імпорту та правил усунення дублікатів.
• Розглянь UUID v7, якщо ідентифікатори записів мають загалом відповідати часу створення, а база даних або програмне забезпечення підтримує цю версію.
• Використовуй звичайне послідовне ціле число, якщо значення створює одна база даних, а компактність і природне впорядкування ключів важливіші за децентралізовану генерацію.

Старіші версії досі використовуються в наявних системах, але для нового рішення слід обирати версію відповідно до реальних вимог, а не вважати всі UUID взаємозамінними.

Як використовувати UUID v4 на практиці

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

1. Створи новий UUID для об'єкта або події, яким потрібен ідентифікатор.
2. Під час передавання між системами зберігай усі п'ять груп і чотири дефіси.
3. Якщо база даних має окремий тип UUID, зберігай значення в ньому. В іншому разі використовуй текстове або двійкове поле відповідного розміру для вибраного представлення.
4. Додай обмеження унікальності, якщо база даних має відхиляти повторювані згенеровані значення UUID v4.

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

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

Чи можуть два UUID v4 збігтися?

Так, теоретично колізія можлива. Проте за звичайного використання UUID v4 вона не є практичною проблемою, якщо генератор використовує належне джерело випадковості. UUID v4 має 122 змінні біти, оскільки решта бітів позначає його версію та варіант. Це залишає надзвичайно велику кількість можливих значень.

Тому визначення "універсальний унікальний" описує практичну властивість, а не математичну гарантію. Помилкове копіювання чи повторне використання значень, недоліки реалізації або неналежна генерація випадкових чисел через неякісне джерело випадковості створюють реальніший ризик дублікатів, ніж випадковий збіг. Системи, у яких дублікати неприпустимі, все одно повинні забезпечувати унікальність на рівні бази даних або застосунку.

UUID також не доводить, що запит справжній. Не використовуй видимий UUID як єдиний засіб авторизації та не вважай об'єкт захищеним лише тому, що його адресу складно вгадати. Перевірка доступу має застосовуватися до самого ресурсу, на який указує UUID.

Поширені запитання

Чи залежить UUID від регістру літер?

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

Чи можна використовувати UUID v4 в URL або назві файлу?

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

Чи потрібно видаляти дефіси з UUID?

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

Чи підходить UUID v4 як пароль або секретний ключ API?

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

Чи може UUID v4 вважатися персональними даними за GDPR?

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

Чи можна використовувати UUID v4 як первинний ключ бази даних?

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