- Тип
- Версия 7: сортируемая дата Unix
- Вариант
- RFC 9562 (ранее RFC 4122)
- Дата создания
- 22 февр. 2022 г., 16:22:22 2022-02-22T19:22:22.000Z · 1645557742000 ms
017f22e2-79b0-7cc3-98c4-dc0c0c07398f017F22E2-79B0-7CC3-98C4-DC0C0C07398F{017F22E2-79B0-7CC3-98C4-DC0C0C07398F}urn:uuid:017f22e2-79b0-7cc3-98c4-dc0c0c07398f01FWHE4YDGFK1SHH6W1G60EECF017f22e279b07cc398c4dc0c0c07398f1989357241971137676463954034883508623AX8i4nmwfMOYxNwMDAc5jw==Как это работает
UUID — это 128-битное число, записанное как 32 шестнадцатеричные цифры в пяти группах (8-4-4-4-12). Оно позволяет идентифицировать запись, ни у кого не спрашивая, занято ли значение: два сервера, два мобильных приложения или два процесса могут создавать идентификаторы одновременно, без согласования и без коллизий. Формат определён в RFC 9562, который в 2024 году заменил RFC 4122 и добавил версии 6, 7 и 8.
Цифра в начале третьей группы указывает версию, и каждая версия раскладывает биты по-своему. Версия 4 — чистая случайность. Версия 7 начинается с даты в миллисекундах, поэтому идентификаторы упорядочены по времени создания. В версиях 3 и 5 нет ничего случайного: они получаются из хеша пространства имён и имени и поэтому всегда дают один и тот же результат. Версии 1 и 6 содержат дату с точностью до 100 наносекунд и узел, которым исторически был MAC-адрес компьютера.
Анализатор работает в обратную сторону: читает версию и вариант, восстанавливает дату из UUID v1, v6 и v7 и из ULID и показывает то же значение в виде GUID, URN, шестнадцатеричного числа, целого числа или Base64. Всё вычисляется в вашем браузере; ни один идентификатор не отправляется на сервер.
Примеры
v5 · DNS · www.example.com2ed6657d-e927-568b-95e1-2665a8aea6a2Это тестовый вектор из RFC 9562. Любая библиотека, правильно реализующая версию 5, должна вернуть ровно это значение для этого имени в пространстве DNS.017F22E2-79B0-7CC3-98C4-DC0C0C07398F2022-02-22T19:22:22.000ZПервые 12 цифр UUID v7 — это миллисекунды Unix в шестнадцатеричном виде: 0x017F22E279B0 равно 1645557742000.C232AB00-9414-11EC-B3C8-9F6BDECED8461EC9414C-232A-6B00-B3C8-9F6BDECED846Один и тот же момент в версии 1 и в версии 6. Версия 6 переставляет биты даты от старшего к младшему, чтобы текст сортировался хронологически; последовательность часов и узел не меняются.01ARZ3NDEKTSV4RRFFQ69G5FAV01563e3a-b5d3-d676-4c61-efb99302bd5bULID занимает те же 128 бит, что и UUID, поэтому его можно хранить в столбце uuid. Но у него нет ни версии, ни варианта: при чтении как UUID эти цифры — часть случайных данных.Сценарии использования
- Создавать первичный ключ на клиенте или сразу в нескольких сервисах, не дожидаясь, пока база данных назначит автоинкремент.
- Генерировать ключи идемпотентности, чтобы повторный платёж или заказ не обрабатывался дважды.
- Помечать каждый запрос идентификатором корреляции, чтобы отслеживать его в логах нескольких микросервисов.
- Получать с помощью v5 стабильный идентификатор из естественного ключа (email, URL, артикул), чтобы две системы приходили к одному значению без общей таблицы.
- Узнавать время создания записи по её UUID v7 или ULID, когда он попадается в логе или отчёте об ошибке.
- Заполнять тестовые данные сотнями корректных идентификаторов за один раз.
Часто задаваемые вопросы
v4 или v7 для первичного ключа?
v7, если только у вас нет причин скрывать дату создания. Индексы на B-деревьях хранят ключи упорядоченно, а v4 попадает в любое место индекса: каждая вставка затрагивает другую страницу, страницы делятся, и кеш работает хуже. v7 всегда попадает в конец, как автоинкремент. Осторожно с SQL Server: тип uniqueidentifier сортирует, начиная с последних шести байтов, поэтому там v7 тоже не будет последовательным.
Могут ли два UUID v4 совпасть?
Теоретически да, на практике нет. У v4 122 случайных бита, и чтобы вероятность хотя бы одного повтора достигла 50 %, пришлось бы сгенерировать около 2,7 × 10¹⁸ штук — по миллиарду в секунду больше 85 лет. Условие одно: криптографический генератор. Реальные дубликаты, о которых сообщают, возникают из-за плохо инициализированного зерна, а не из-за математики.
UUID и GUID — это одно и то же?
Да, GUID — это название, которое использует Microsoft, а текст идентичен; в Windows он обычно пишется заглавными буквами и в фигурных скобках. Разница в двоичном представлении: Guid.ToByteArray в .NET хранит первые три группы в little-endian, поэтому, прочитав эти байты из другого языка, вы увидите первые цифры в обратном порядке.
Можно ли использовать UUID как секретный токен?
Правильно сгенерированный v4 содержит 122 непредсказуемых бита — этого хватает для трудно угадываемой ссылки, но RFC 9562 прямо говорит, что UUID не предназначены для роли учётных данных: многие библиотеки не гарантируют криптографический генератор, а версии 1, 6 и 7 раскрывают дату создания. Для токенов сессии или сброса пароля лучше генерировать отдельные случайные байты.
ULID или UUID v7?
Они несут почти одинаковую информацию: 48 бит миллисекунд и остальное — случайные данные. ULID записывается 26 символами без дефисов и неоднозначных букв, что удобнее в URL. v7 — стандартный UUID, поэтому без преобразований подходит для столбцов uuid в PostgreSQL и для любого валидатора. Если начинаете с нуля и в вашей базе есть тип uuid, выбирайте v7.
Почему узел в моих UUID v1 — не мой MAC?
Потому что раскрытие MAC-адреса сетевой карты позволяет выяснить, какая машина создала каждый идентификатор, — именно так в 1999 году вычислили автора вируса Melissa. RFC 9562 рекомендует случайный узел с установленным битом multicast, что и делает этот инструмент; анализатор предупредит, если UUID v1 содержит настоящий MAC.