Генератор UUID

UUID v4 — это 122 бита криптографически стойкой случайности — повсеместный стандарт для ключей идемпотентности, идентификаторов сессий и везде, где нужен непрозрачный, неупорядоченный идентификатор. UUID v7 встраивает 48-битную временную метку Unix-millisecond в начальные байты, поэтому значения, сгенерированные близко по времени, сортируются рядом в лексикографическом порядке. Это делает v7 более подходящим для первичных ключей базы данных, где вставки v4 иначе могут фрагментировать индекс B-tree.

Пример

Три UUID v4 (случайные, без порядка):

f47ac10b-58cc-4372-a567-0e02b2c3d479
6ba7b810-9dad-11d1-80b4-00c04fd430c8
d1b2c3e4-5678-4abc-9def-0123456789ab

Три UUID v7, сгенерированные в ту же миллисекунду (обратите внимание на общий префикс):

018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90
018f8e50-fcaa-7c3d-a41f-8c9b07e2c0d1
018f8e50-fcab-7c01-b3e7-1d9a4f5c6e82

Частые ошибки и подводные камни

Это реальные подводные камни, с которыми разработчики сталкиваются при встраивании UUID в приложение:

• Использование v4 там, где важен порядок вставки. Индексация 10 млн случайных v4 вызывает тяжелые разделения страниц в B-tree. Если оставляете v4, либо смиритесь с усилением записи, либо смените первичный ключ на v7.
• Удаление дефисов и потеря версионного ниббла. f47ac10b58cc4372a5670e02b2c3d479 все еще является допустимым 32-символьным hex UUID, но 13-й символ (4) — это маркер версии, а не случайный ниббл. Не считайте все 32 символа случайными.
• Надежда на Math.random(). Старые библиотеки, построенные на Math.random(), не являются криптографически стойкими и могут быть предсказуемыми. Используйте crypto.randomUUID() (браузеры и Node 19+) или библиотеку v7, которая читает из crypto.
• Отношение к v7 как к временной метке. Начальные 48 бит несут время, но остальное случайно, поэтому два v7 с одной миллисекундой не упорядочены детерминированно. Не полагайтесь на разрешение связей.
• Хранение как VARCHAR(36). Это работает, но удваивает хранилище по сравнению с нативной 16-байтной колонкой UUID / BINARY(16) и замедляет join. Используйте нативный тип базы данных (uuid в Postgres, UNIQUEIDENTIFIER в SQL Server).
• Regex, требующий конкретной версии. /[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-.../i соответствует только v4. Если позже вы выдадите v7, этот regex молча отклонит допустимые ID.

В чем разница между UUID v4 и v7?

v4 — это 122 бита случайности плюс маркеры версии и варианта, без временной компоненты. v7 префиксирует 48-битную временную метку Unix-millisecond и заполняет остальное случайными битами, поэтому значения v7, сгенерированные близко по времени, сортируются лексикографически. Используйте v7 как первичный ключ базы данных, чтобы держать вставки B-tree локальными; используйте v4, когда вообще не нужен сигнал порядка.

Получу ли я когда-нибудь дубликат UUID?

Фактически нет. UUID v4 имеет 122 случайных бита, поэтому вероятность столкновения любых двух в партии из миллиарда составляет около 10^-18. Вам нужно было бы сгенерировать порядка 2,7 квинтиллиона UUID v4, прежде чем достичь 50% вероятности одного столкновения. Считайте уникальную генерацию данностью и не добавляйте проверку уникальности.

Является ли v4 криптографически случайным?

Этот инструмент использует crypto.randomUUID(), который по спецификации обязан брать из криптографически стойкого PRNG. Этого достаточно для идентификаторов сессий, ключей идемпотентности и большинства токенов безопасности. Это не замена подписанному токену или длинному API-секрету, и вам не следует выводить ключи шифрования из UUID.

Стандартизирован ли UUID v7?

Да. UUID v7 определен в RFC 9562 (май 2024), который заменил RFC 4122 и формализовал v6, v7 и v8 наряду с оригинальными версиями. Большинство современных языков имеют реализации v7 — Postgres, MySQL и SQL Server все принимают значения v7 как колонку UUID без изменений.

Как выглядит двоичная форма и важен ли порядок байтов?

UUID — это 16 байт. Каноническая текстовая форма группирует их как 8-4-4-4-12 hex-символов. Байты записываются в сетевом (big-endian) порядке согласно RFC 9562, поэтому 018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90 начинается с байта 0x01. Microsoft GUID исторически хранят первые три группы в памяти в little-endian — будьте осторожны при взаимодействии с .NET-бинарными дампами.

Сохраняете ли вы UUID, которые генерирует этот инструмент?

Нет. Мы не сохраняем UUID, которые вы здесь генерируете. Каждое значение отображается в области вывода и исчезает в момент обновления или закрытия вкладки — ничего не хранится, телеметрия по значениям не собирается. Добро пожаловать проверить в инструментах разработчика вашего браузера.