UUID v4: как получить идентификатор и правильно использовать его

UUID v4 подходит, когда записи нужен идентификатор, который можно сгенерировать без общего счётчика. Выбор идентификатора не отменяет ограничение уникальности в базе и проверки доступа: сервер всё равно должен решать, кому принадлежит запись и кто вправе её читать.

UUID имеет 128 бит. У версии 4 часть битов занята версией и вариантом; остаются 122 бита случайной составляющей. Текстовая запись обычно состоит из групп 8-4-4-4-12 шестнадцатеричных символов. RFC 9562, разделы 4 и 5.4, май 2024; проверено 05.10.2026.

Сгенерируйте значения без seed

Откройте генератор UUID, выберите количество и оставьте seed пустым. Пустое поле в интерфейсе означает отсутствие опции; в API необязательный seed нужно опустить, а не передавать строкой нулевой длины. Для обычных новых идентификаторов воспроизводимость не требуется.

Операция data.generate_uuid принимает input=null. Доступны count от 1 до 100 и uppercase; без seed источник байтов — системный криптографический генератор. Метаданные содержат algorithm=system_csprng. Верхний регистр меняет представление, а не содержимое UUID.

Пример параметров для двух новых значений:

{"input":null,"options":{"count":2,"uppercase":false}}

Результат содержит массив output.values из двух строк. При независимой случайной генерации строки обычно различаются, но совпадение теоретически возможно; фиксированный пример ниже служит только для разбора формата, это синтетический идентификатор:

07f7f6ad-b06e-4aaa-8e69-15c2c6d1508c

Его формат проверен на локальном генераторе версии 1. Он получен в отдельном тестовом режиме с seed, поэтому не является примером нового случайного значения для рабочей системы.

Проверьте формат, затем проверьте систему

В третьей группе первая цифра 4 обозначает v4. Первая цифра четвёртой группы для применяемого варианта может быть 8, 9, a или b. RFC 9562, разделы 4.1–4.2, проверено 05.10.2026.

Регулярное выражение полезно для первой проверки ввода:

^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$

Для верхнего регистра используйте соответствующий режим сравнения. Такая проверка подтверждает форму, но не случайность, происхождение, существование записи или право пользователя на доступ. На сервере лучше использовать проверенный UUID-парсер и ограничение уникальности хранилища.

Не генерируйте новую строку при каждом повторе одного импорта, если требуется найти уже созданную запись. Храните присвоенный идентификатор либо используйте отдельный устойчивый ключ исходной системы. Повторная отправка операции с новым UUID сама по себе не делает её идемпотентной.

Сохраните выданный ID вместе с записью

Для пробной сущности сначала получите идентификатор, затем сохраните его и используйте тот же ID при повторном чтении. Не вызывайте генератор заново, чтобы «узнать идентификатор» существующей записи: новый результат не связан с предыдущей сущностью. Связь создаёт ваше приложение, а не формат UUID.

Проверьте путь через базу, API и клиентский интерфейс одним искусственным значением. Если один слой меняет регистр, другой хранит строку буквально, а третий обрезает поле, корректный UUID может перестать находиться. Согласуйте представление и длину поля; сравнивайте целое значение после обратного чтения, включая все группы.

Попытка повторно вставить уже сохранённый ID должна обрабатываться известным правилом хранилища, а не создавать вторую запись молча. Отдельно проверьте, что клиент не может заменить чужой идентификатор в запросе и получить доступ к чужой сущности. Это проверки системы использования ID, которые веб-генератор не выполняет и не подтверждает своим успешным ответом.

Когда сначала нужно выбрать другой контракт

Если база требует сортировки ключей по времени, или идентификатор должен неизменно получаться из имени, сначала согласуйте подходящую версию и библиотеку в приложении. Генератор Neraviko в описываемой версии выпускает v4; опции переключения на v5 или v7 здесь нет. Не заменяйте проектное требование случайным UUID только потому, что его легко получить.

UUID — идентификатор, не пароль и не токен авторизации. Для рабочего создания больших потоков значений разумнее генерировать их внутри приложения системным генератором, чем вручную переносить из веб-инструмента.

Перед использованием проверьте:

• действительно ли нужен независимый случайный идентификатор;
• seed не задан для рабочих новых записей;
• все значения прошли проверку формата и сохраняются в согласованном представлении;
• база обеспечивает уникальность, а API — авторизацию;
• повторный импорт имеет явное правило сопоставления записей.

Инструмент выполняет генерацию на сервере. По контракту сырые запросы и результаты не сохраняются и не логируются по умолчанию. Параметры и доступность версии проверены по исходному коду 05.10.2026; перед внедрением сверяйте контракт с текущей версией сервиса.

Математическая модель вероятности коллизии UUID v4; 122 независимых случайных бита; не относится к seed и не гарантирует уникальность.

Модель для UUID v4 с независимыми равномерно случайными значениями: p ≈ 1 − exp(−n(n−1)/(2 × 2^122)). Это birthday/Poisson approximation, а не измерение Neraviko. При n=10^18 получается около 0,08975; обычные меньшие объёмы видны на логарифмических осях. Модель не учитывает дефекты генератора и повторные импорты. RFC 9562: UUID v4.