Что такое UUID v7 и как работает генератор
Страница [uuid-v7-generator] (здесь и далее — ссылка на описываемый инструмент) мгновенно возвращает заданное количество идентификаторов UUID v7 — от 1 до 100 штук — с возможностью выбора регистра символов и наличия дефисов. Каждый полученный ID представляет собой 36‑символьную строку, начинающуюся с 48‑битной метки времени Unix в миллисекундах, за которой следуют случайные биты. Это — главное отличие от UUID v4: за счёт временно́го префикса такие идентификаторы естественным образом сортируются по моменту создания, что улучшает локальность индексов в базах данных.
В отличие от других онлайн-генераторов, этот работает полностью в браузере: ни один ID не отправляется на сервер BroBroGo. Вся случайность берётся из криптостойкого источника crypto.getRandomValues, доступного в современных браузерах. Изменение любой опции (количество, регистр, дефисы) немедленно запускает перегенерацию всего набора. Пользователь может скопировать любой отдельный ID щелчком по нему или скопировать сразу все кнопкой «Copied all!».
Структура UUID v7: метка времени + случайность
Спецификация UUID v7 (часть проекта IETF, который позже стал RFC 9562) определяет 128‑битный идентификатор, где:
- 48 бит — Unix-время в миллисекундах (эпоха от 1970-01-01). Это первые 12 шестнадцатеричных символов строки.
- 4 бита — версия UUID (значение
0111, то есть 7). - 12 бит — случайный или псевдослучайный счётчик (для уникальности в пределах одной миллисекунды).
- 2 бита — вариант (значение
10, что соответствует стандартному UUID). - оставшиеся 62 бита — чистая случайность.
Итоговая текстовая форма: xxxxxxxx-xxxx-7xxx-yxxx-xxxxxxxxxxxx, где x — шестнадцатеричные цифры из метки времени или случайных битов, а y — старшие два бита варианта (обычно 8, 9, a или b). Для UUID v7 бит варианта всегда 10, то есть y может быть 8, 9, a или b в зависимости от младших битов случайности.
На практике это означает, что первые символы любого сгенерированного UUID v7 будут монотонно возрастать с течением времени. Если сгенерировать два ID на разных машинах с разницей в 1 миллисекунду, ID с более поздней меткой будет лексикографически больше (при одинаковом регистре). В пределах одной миллисекунды порядок не гарантируется — случайная часть может дать любой результат.
Почему временная сортировка важна для баз данных
Традиционные UUID v4 (полностью случайные) при использовании в качестве первичного ключа в B‑tree индексах вызывают серьёзную фрагментацию. Каждая новая вставка с равной вероятностью попадает в любую страницу индекса, заставляя СУБД часто разбивать страницы и переписывать их на диск. Это снижает производительность вставки и увеличивает занимаемое место.
UUID v7 решает эту проблему: новые ID всегда попадают в конец индекса (или близко к нему), потому что метка времени возрастает. Это приближает поведение к автоинкрементному ключу, сохраняя при этом глобальную уникальность без централизованного координатора. Для распределённых систем, где каждая нода генерирует ID независимо, временна́я префиксная сортировка даёт огромное преимущество: индексы остаются компактными, а вставки — быстрыми.
Однако важно понимать: UUID v7 не гарантирует строгий порядок ID, созданных в одну и ту же миллисекунду — ни на одной машине, ни на разных. Поэтому полагаться на UUID v7 как на точную хронологическую последовательность внутри миллисекундного окна нельзя. Для этого существуют форматы с более высокой точностью (например, ULID использует 48‑бит метку времени в миллисекундах и дополнительный 80‑битный случайный блок, но тоже не даёт гарантии порядка в одной миллисекунде; для строгого порядка нужны монотонные счётчики, как в Snowflake).
Сравнение: UUID v7, UUID v4, ULID, NanoID
| Характеристика | UUID v4 | UUID v7 | ULID | NanoID |
|---|---|---|---|---|
| Длина строки (стандартная) | 36 символов | 36 символов | 26 символов | 21 символ (по умолчанию) |
| Содержит метку времени | Нет | Да (48 бит Unix ms) | Да (48 бит Unix ms) | Опционально (расширение) |
| Сортировка по времени | Нет | Да (не строгая в ms) | Да (не строгая в ms) | Нет (если без метки) |
| Криптостойкая случайность | Да | Да | Да (значение по умолчанию) | Да (используется крипто-генератор) |
| Символы | 0-9, a-f (hex) | 0-9, a-f (hex) | 0-9, A-Z (Crockford Base32) | 0-9, a-z, A-Z, _- (64 символа) |
| Уникальность | 122 случайных бита | 74 случайных бита (после метки) | 80 случайных бит | 126 бит (для 21 символа) |
| Поддержка в базах данных | Повсеместно | Растущая (PostgreSQL, MySQL 8.0+, CockroachDB) | Ограниченная (расширения) | Повсеместно как строка |
UUID v7 выигрывает за счёт стандартизации: он вписывается в существующую инфраструктуру UUID (36 символов, дефисы) и поддерживается популярными СУБД. ULID требует 26 символов и не является стандартом IETF. NanoID — компактный, но не имеет встроенной метки времени (есть расширения, но они не стандартизованы).
Как работает генератор на странице
Интерфейс минималистичен: выбор формата (UUID v7 является одним из вариантов, но на этой странице он фиксирован), поле для количества (1–100), переключатели «Uppercase» и «Include hyphens». При загрузке страницы сразу генерируется набор ID с настройками по умолчанию (строчные буквы, дефисы включены, count=1). После изменения любого параметра набор обновляется мгновенно.
Генерация происходит локально в JavaScript:
- Получается текущее время в миллисекундах (
Date.now()), которое преобразуется в 48-битное число. - К нему добавляются 4 бита версии (7), 2 бита варианта (10) и 74 случайных бита (через
crypto.getRandomValues). - Полученные 128 бит форматируются в шестнадцатеричную строку с дефисами на позициях 8-4-4-4-12 (по стандарту) или без дефисов, если опция отключена.
- Если включён «Uppercase», все буквы a-f преобразуются в A-F.
Важно: при отключении дефисов строка становится длиной 32 символа (128 бит / 4 бита на символ). Это всё ещё валидное представление UUID (так называемый «hex string»), но большинство библиотек ожидают каноническую форму с дефисами. Генератор не проверяет, что делает: если пользователь убирает дефисы, UUID остаётся тем же самым числом, но в компактном виде.
Статусы индикатора: «Ready.» — исходное состояние до генерации, «Generated.» — после успешного создания набора, «Copied all!» — после копирования всех ID в буфер обмена. При нажатии на конкретный ID он копируется в буфер, а статус не меняется (интерфейс не показывает отдельного уведомления, но копирование происходит).
Ограничения и граничные случаи
- Диапазон количества: строго от 1 до 100. Если ввести 0 или 101, инструмент, скорее всего, либо проигнорирует, либо вернёт ошибку (факт-лист не уточняет, но по логике — count должен быть в допустимых пределах). При изменении count все ID пересоздаются заново, даже если предыдущий набор был больше.
- Одна миллисекунда: при генерации 100 ID все они получат одинаковую метку времени (если генерация произошла в пределах одного вызова
Date.now()). Поэтому порядок ID в списке не отражает хронологию внутри набора — он определён случайной компонентой. Пользователь не должен ожидать, что первый ID сгенерирован раньше второго в рамках одного пакета. - Копирование всего набора: кнопка «Copied all!» копирует все ID, разделённые переносом строки. Формат — каждый ID на новой строке. Регистр и дефисы соответствуют текущим настройкам.
- Приватность: никакой телеметрии, никаких кук. Генерация полностью на клиенте. Это значит, что метка времени берётся с часов компьютера пользователя; если часы сбиты, метка будет неверной, но это не влияет на случайность.
Кому пригодится инструмент
- Разработчики распределённых систем, которым нужны уникальные первичные ключи, сортируемые по времени, без единой точки отказа.
- Администраторы баз данных, страдающие от фрагментации индексов из-за UUID v4. Они могут протестировать, как выглядят сгенерированные v7 ID, и оценить прирост производительности.
- Инженеры по безопасности, требующие не угадываемые идентификаторы (случайная часть криптостойкая), но при этом желающие отслеживать порядок создания записей.
- Все, кто мигрирует с UUID v4 на v7: инструмент позволяет быстро получить образцы для экспериментов, не поднимая сервер.
Часто задаваемые вопросы
1. Почему UUID v7 не гарантирует строгий порядок в пределах одной миллисекунды?
Потому что за меткой времени (48 бит) следуют случайные биты (74 бита без учёта версии и варианта). Если два ID созданы в одну миллисекунду, их порядок определяется случайным хвостом, а не временем. Для строгого монотонного порядка нужен счётчик на каждую миллисекунду, как в UUID v1 или Snowflake.
2. Может ли UUID v7 конфликтовать с UUID v4?
Нет, потому что бит версии для v7 равен 7 (0111), а для v4 — 4 (0100). Эти идентификаторы всегда различаются в 13‑м символе (если считать с дефисами). С точки зрения хранения они оба 128-битные числа, но их никогда не спутать.
3. Безопасен ли генератор для секретных данных?
Криптографическая стойкость случайной части зависит от реализации в браузере. crypto.getRandomValues считается достаточно надёжным для большинства задач (сессионные токены, API-ключи). Однако если требуется максимальная энтропия, стоит добавить дополнительное перемешивание или использовать аппаратный генератор случайных чисел.
4. Зачем нужна опция «Include hyphens»?
Дефисы — часть канонического представления UUID (x8-4-4-4-12). Некоторые системы ожидают именно такой формат. Удаление дефисов даёт компактную 32-символьную строку, которая проще встраивается в URL (без экранирования). Однако при этом теряется валидность для парсеров, которые ориентируются на дефисы.
5. Влияет ли регистр на уникальность?
Нет, UUID как 128-битное число не зависит от регистра. Строки «a1b2c3d4…» и «A1B2C3D4…» представляют один и тот же идентификатор. Регистр влияет только на хранение и сравнение строк: в базах данных, чувствительных к регистру, A ≠ a. Генератор позволяет выбрать нужный вариант для совместимости.
6. Почему нельзя сгенерировать больше 100 ID за раз?
Ограничение связано с производительностью интерфейса и разумным использованием ресурсов браузера. Генерация 1000 ID займёт доли секунды, но копирование такого объёма в буфер может быть неудобным. К тому же для массовой генерации лучше использовать скрипт на сервере или командную строку.