Сгенерировать UUID
Конфиденциально — файл не сохраняется
Какая версия?
Здесь появится результат: Ваши 0 UUID.
Как это работает
Выберите версию
v4 — для всего, что должно быть неугадываемым. v7 — для ключей базы данных. Разница объясняется на странице, а не подразумевается.
Укажите количество
Один или до десяти тысяч сразу, с форматированием на выбор — заглавные буквы, фигурные скобки, без дефисов или список в кавычках, готовый для кода.
Скопируйте их
Скопируйте все или скачайте текстовым файлом.
Версия 4 или версия 7 — и почему это важно для базы данных
UUID — это 128 бит, записанные 32 шестнадцатеричными цифрами в привычной группировке 8-4-4-4-12. Шесть из этих битов указывают версию и вариант, так что в версии 4 остаётся 122 случайных бита — достаточно, чтобы генерировать миллиард в секунду на протяжении столетия и всё равно с подавляющей вероятностью ни разу не получить повтор. В этом вся привлекательность: две системы, которые никогда не общались, могут создавать идентификаторы и спокойно считать, что они никогда не совпадут.
Чтобы это работало, случайность должна быть настоящей, и здесь она берётся из криптографического источника, а не из обычного генератора случайных чисел. Разница важна, когда идентификаторы служат ключами доступа — ссылка для сброса пароля, неугадываемая ссылка для совместного доступа, — потому что по предсказуемому генератору можно вычислить следующее значение из предыдущих. У криптографического источника предсказывать нечего.
Версия 7 появилась потому, что версия 4 плохо ведёт себя в роли первичного ключа. В начало она ставит 48-битную метку времени в миллисекундах, а остальное заполняет случайными битами, поэтому UUID, созданные один за другим, сортируются в порядке создания. Звучит как косметика, но это не так: случайный ключ разбрасывает каждую вставку по всему индексу, так что каждая запись затрагивает новую страницу и кеш перестаёт помогать, а упорядоченный по времени ключ дописывается в конец. На большой таблице разница в скорости вставки существенна — именно поэтому v7 и стандартизировали.
Компромисс реален, и его стоит взвесить. UUID версии 7 сообщает любому, кто его видит, примерное время создания с точностью до миллисекунды, а серия таких UUID показывает, как быстро вы создаёте записи. Для внутреннего ключа это нормально. Для идентификатора, который виден в URL, — номера заказа, ссылки на документ, ID пользователя — это небольшая утечка информации, которой у версии 4 нет. Если важно и то и другое, используйте v7 для первичного ключа и v4 для всего публичного.
Если нужно другое
Генерируйте их там, где они используются. Во всех базах данных и языках это уже встроено — gen_random_uuid() в PostgreSQL, UUID() в MySQL, crypto.randomUUID() в JavaScript, uuid.uuid4() в Python, — и сгенерировать пачку в браузере и вставить в код нормально для тестовых данных или теста, но неправильно для всего, что работает в продакшене.
Если v7 нужен ради сортируемых ключей, есть альтернативы, о которых стоит знать. ULID выражает ту же идею в 26 символах — короче и без учёта регистра; идентификаторы Snowflake умещаются в 64 бита, что вдвое уменьшает индекс по сравнению со 128 битами UUID. А во многих базах данных обычное автоинкрементное целое по-прежнему быстрее и компактнее любого из них — UUID оправдывают свою цену, когда идентификаторы нужно создавать в нескольких местах одновременно, и не иначе.
Частые вопросы
v4 или v7 — какой мне нужен?
Если это первичный ключ базы данных — v7. Если его должно быть невозможно угадать — ссылка для сброса пароля, код приглашения, идентификатор сессии — v4. Вот и всё решение, а большинство даже не узнаёт, что выбор был, потому что почти все генераторы предлагают только v4.
Чем v4 плох в роли ключа базы данных?
Тем, что он полностью случаен, а индекс базы данных отсортирован. Новые случайные ключи попадают в случайные места индекса, поэтому каждая вставка затрагивает новую страницу, кеш перестаёт помогать, а индекс фрагментируется и разрастается. На большой нагруженной таблице это заметное замедление, которое со временем усиливается. Это не теоретическая проблема — именно поэтому её теперь обсуждает документация и Postgres, и MySQL.
Что такое UUID v7?
UUID, первые 48 бит которого — метка времени в миллисекундах, а дальше идут случайные биты. Он по-прежнему глобально уникален и по-прежнему занимает 128 бит, но поскольку время стоит в начале, UUID v7 сортируются в порядке создания. Новые ключи дописываются в конец индекса, а не разбрасываются по нему, — ровно как автоинкрементное целое, но с уникальностью UUID. Его стандартизировали в RFC 9562 в 2024 году, и сейчас это рекомендуемый вариант для новых таблиц.
UUID v7 здесь действительно сортируются?
Да, в том числе внутри одной миллисекунды, — а именно здесь ошибается большинство реализаций. Метка времени имеет точность только до миллисекунды, поэтому генерация тысячи ID в цикле укладывается в одну миллисекунду — и при чисто случайных младших битах эта тысяча НЕ сортируется в порядке создания. Этот генератор использует монотонный счётчик, описанный в RFC 9562, поэтому пачка всегда строго возрастает. Сгенерируйте тысячу и отсортируйте — они выстроятся в порядке создания.
Безопасно ли показывать UUID v7 публично?
С одной оговоркой: по замыслу он раскрывает время своего создания с точностью до миллисекунды. Для ключа базы данных это обычно безвредно или даже полезно. Но если само время создания конфиденциально или идентификатор должен быть неугадываемым, используйте v4: в v7 всё ещё 74 случайных бита — это очень много, — но его метку времени может прочитать любой, у кого есть ID.
Достаточно ли они случайны, чтобы быть безопасными?
Да. Случайность берётся из `crypto.getRandomValues` — криптографически стойкого генератора браузера, а не из `Math.random`. Это различие уже приводило к реальным уязвимостям: `Math.random` быстр, но предсказуем, и построенные на нём токены сессий на практике угадывали. В UUID v4 122 случайных бита — этого достаточно, чтобы коллизии не были практической проблемой.
Они генерируются на моём устройстве?
Да, полностью, и для идентификаторов это важно. UUID, полученный с чужого сервера, — это UUID, который кто-то уже видел, а это лишает смысла генерацию секрета. Эти UUID никогда не покидают ваш браузер. После загрузки страницы отключите Wi-Fi — всё будет работать точно так же. Это самый простой способ проверить обещание конфиденциальности самостоятельно, а не верить нам на слово.
Что такое нулевой (nil) UUID?
Все нули: 00000000-0000-0000-0000-000000000000. Это корректный зарезервированный UUID, который означает «нет значения» или «не задано» там, где null невозможен. Его противоположность — максимальный (max) UUID из одних f — иногда используется как граничное значение при сортировке. Оба предлагаются здесь, потому что они иногда нужны, а набрать их без ошибок неудобно.
Полезно знать: UUID версии 4 берутся из криптографического источника случайности браузера, а не из Math.random, поэтому их безопасно использовать как идентификаторы. Версия 7 содержит метку времени с точностью до миллисекунды — благодаря этому она хорошо сортируется, но это также значит, что по ней примерно видно время создания. Не используйте v7 там, где это важно.
Разместите этот инструмент на своём сайте
Бесплатно для любого блога, страницы класса или справочной статьи. Вставьте один фрагмент кода — и посетители смогут пользоваться инструментом прямо на вашей странице.