Що таке декодування UUID?
Декодування UUID це процес аналізу UUID для витягнення інформації про:
- Version: Яка версія UUID (1–8) на основі 4 біт у позиції 48–51
- Variant: Який варіант UUID (зазвичай RFC 4122) на основі біт 64–65
- Components: Витягнення мітки часу, ідентифікатора вузла або інших даних залежно від версії
- Час генерації: Для часових UUID (v1, v6, v7)
Example: 123e4567-e89b-12d3-a456-426614174000 є UUID версії 1 із міткою часу 2228-06-25T20:01:28.545Z коли показано з точністю JavaScript до мілісекунди.
Огляд структури UUID
| Format | Description |
|---|---|
| 8-4-4-4-12 | 32 шістнадцяткові цифри, згруповані дефісами |
| Біти версії | Біти 48–51 (13-та цифра) |
| Біти варіанта | Біти 64–65 (17-та цифра) |
Номер версії з'являється як перша шістнадцяткова цифра в третій групі (наприклад, 123e4567-e89b-12d3-a456-426614174000 для версії 1).
Декодування за версіями UUID
| Version | Що можна розшифрувати |
|---|---|
| UUID v1 |
|
| UUID v3/v5 |
|
| UUID v4 |
|
| UUID v6 |
|
| UUID v7 |
|
Витягнення мітки часу з UUID
| Тип UUID | Метод витягання часу | Epoch |
|---|---|---|
| UUID v1 | Об’єднати біти 0–31, 32–47 і 48–59, переставляючи компоненти мітки часу | 15 жовтня 1582 |
| UUID v6 | Об’єднати біти 0–47 з бітами 52–63; біти 48–51 — це версія і виключаються | 15 жовтня 1582 |
| UUID v7 | Витягнути біти 0–47 (Unix-мілісекунди) | 1 січня 1970 |
Правила валідації UUID
- Перевірка формату: 8-4-4-4-12 шістнадцяткових цифр з дефісами
- Перевірка версії: 13-й символ має бути від 1 до 8
- Перевірка варіанта: 17-й символ має бути 8, 9, A або B (для RFC 4122)
Регулярний вираз для базової перевірки UUID:
^[0-9a-f]{8}-[0-9a-f]{4}-[1-8][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$Приклад мітки часу UUID v7
017f22e2-79b0-7cc3-98c4-dc0c0c07398f є тестовим вектором RFC 9562 для UUIDv7. Перші 48 біт — це Unix-мілісекунди, які декодуються в 2022-02-22T19:22:22.000Z, 1645557742000 мілісекунд, або 1645557742 seconds.
Згенерувати новий UUID v7, або продовжити з Конвертер Unix-міток часу. Ці посилання не містять UUID, який ви ввели.
Практичні застосування
- Судова експертиза: Визначення коли були створені ідентифікатори
- Debugging: Трасування поведінки системи за мітками часу в ідентифікаторах
- Auditing: Перевірка хронологічної цілісності
- Перевірки формату: Виявлення пошкоджених ідентифікаторів; дійсний UUID не доводить автентичності
- Відновлення даних: Відтворення часових відношень
- Міграції систем: Розуміння деталей реалізації застарілих UUID
Витягнення MAC-адреси (v1/v6)
Для UUID v1 і v6 часто можна витягти ідентифікатор вузла (MAC-адресу), якщо він не був рандомізований під час генерації:
- Витягніть останні 12 шістнадцяткових цифр (48 біт) з UUID
- Форматуйте з двокрапками як XX:XX:XX:XX:XX:XX
- Перевірте, чи є MAC-адреса реальною або випадковою, аналізуючи біт multicast
Якщо в першому байті встановлений біт 0x01, ймовірно, це рандомізований ідентифікатор вузла, а не реальна MAC-адреса.
Поширені запитання
Чи можу я точно визначити, коли було створено UUID v4?
Ні. UUID v4 є повністю випадковим і не містить інформації про час. Час створення не можна визначити з самого UUID v4.
Наскільки точними є мітки часу у часових UUID?
Тимчасові мітки UUID v1/v6 мають точність 100 наносекунд. UUID v7 має точність мілісекунд. Проте фактична точність системного годинника може відрізнятися.
Чи можу я конвертувати між версіями UUID?
Ні — ви не можете безпосередньо конвертувати між версіями збереженням того самого значення ідентифікатора. Різні версії мають фундаментально різні структури.
Чи можу я ідентифікувати комп’ютер, який згенерував UUID v1?
Якщо ідентифікатор вузла не був рандомізований, UUID v1 може містити MAC-адресу системи, яка його згенерувала. Проте багато сучасних реалізацій рандомізують це з міркувань приватності.
Як я можу визначити, чи є UUID дійсним?
Перевірте формат (8-4-4-4-12 шістнадцяткових цифр), підтвердіть цифру версії (13-й символ) — від 1 до 8, і підтвердіть біти варіанта (17-й символ — 8, 9, A або B для UUID за RFC 4122).