Для чего нужны UUID
UUID (Universally Unique Identifier), в экосистемах Microsoft также называемый GUID, — это 128-битное значение в стандартной текстовой форме, например:
550e8400-e29b-41d4-a716-446655440000
Системы используют UUID, когда нужны идентификаторы с крайне низкой вероятностью коллизий без центрального распределителя: первичные ключи в распределённых сервисах, ID сообщений, дескрипторы загрузок и имена ресурсов в API. Уникальность вероятностная (или выводится из имён), а не подтверждается запросом к глобальному реестру при каждом создании ID.
Создайте пример с помощью Сгенерировать UUID, затем проверьте формат и поля версии с помощью Проверить UUID.
Подинструменты этого семейства
- Сгенерировать UUID — создаёт UUID версий 1, 3, 4 или 5, с необязательными полями namespace и name, где эти версии их требуют.
- Проверить UUID — проверяет, что строка соответствует макету UUID, и сообщает о соображениях валидности для версий с 1 по 5.
Генерация и проверка дополняют друг друга: выпускайте ID в версии, которую ожидает схема, затем проверяйте пользовательские или импортированные строки, прежде чем принимать их как внешние ключи или ключи кэша.
Версии, с которыми вы реально столкнётесь
Версия 4 (случайная). Самый частый выбор для новых ID приложений. Большинство битов случайны из CSPRNG; биты версии и варианта фиксированы по RFC 4122. Коллизии пренебрежимы при практических объёмах, если генератор корректен.
Версия 1 (на основе времени). Встраивает метку времени и идентификатор узла (исторически MAC-адрес). Полезна для приблизительного упорядочивания по времени, но может раскрывать время создания и идентичность машины — в чувствительных к приватности контекстах часто предпочитают v4 или более новые схемы.
Версия 3 (на основе имени с MD5) и версия 5 (на основе имени с SHA-1). Выводят UUID из namespace UUID плюс строки name. Один и тот же namespace+name всегда даёт один и тот же UUID — удобно для стабильных ID из URL или имён пользователей без таблицы поиска. Для новых проектов v5 предпочтительнее v3, потому что в выводе используется SHA-1 вместо MD5.
Другие версии и последующие предложения (например, сортируемый по времени UUIDv7 в более новых RFC) встречаются в современных стеках; если платформа документирует конкретную версию, следуйте ей, а не смешивайте политики.
Текстовый формат и биты варианта
Канонический текст использует пять hex-групп 8-4-4-4-12. Парсеры должны принимать hex в верхнем или нижнем регистре. Nibble версии находится в третьей группе; биты варианта — в четвёртой. Проверка, которая лишь смотрит, что «похоже на hex с дефисами», слабее проверки, которая также сверяет согласованность версии/варианта с заявленным типом.
Некоторые API принимают форму URN (urn:uuid:…) или GUID в фигурных скобках {…}. Нормализуйте перед сравнением. Двоичное хранение — 16 байт; текстовая форма — для людей и JSON.
Разумный выбор ID
Когда UUID помогают. Дружественные к слияниям первичные ключи, офлайн-выпуск ID, сокрытие от клиентов последовательных счётчиков строк.
Когда мешают. Огромные случайные первичные ключи могут сильнее фрагментировать B-tree-индексы, чем последовательные целые — измерьте на своей СУБД. Журналирование и поддержка усложняются, если каждый ID непрозрачен; сочетайте с человекочитаемыми номерами обращений, когда операторам это нужно.
Стабильность. Для v3/v5 на основе имени задокументируйте namespace UUID, который стандартизирует ваша организация (DNS, URL, OID или собственный корень). Смена namespace молча выдаёт другой ID для того же name.
Замечания по безопасности
Значения UUIDv4 — это идентификаторы, а не секреты аутентификации. Угадать незарегистрированный v4 ID всё же трудно — не считайте это самодостаточной авторизацией; всегда применяйте контроль доступа. Избегайте v1, если биты узла, производные от MAC, раскрыли бы аппаратную идентичность в публичных документах. Не встраивайте пароли или PAN в строки name для v3/v5.
Частые ошибки
- Генерация v4 с сохранением только первой половины «для экономии места», уничтожая гарантии уникальности.
- Регистрозависимые сравнения строк между системами с разной нормализацией.
- Использование nil UUID (
00000000-0000-0000-0000-000000000000) как реального ключа сущности. - Предположение, что проверка формата означает существование ID в вашей базе.
- Смешивание нескольких генераторов с разными политиками версий для одного столбца.
Ограничения и среда
Эти инструменты помогают выпускать и просматривать UUID в стиле RFC в браузере для разработки и обучения. Они не выделяют ID из производственных последовательностей БД и не гарантируют глобальную уникальность при неисправных RNG.
Итог
UUID дают 128-битные идентификаторы в стандартной hex-форме, с версиями для случайной, временной и именной генерации. Этот хаб сочетает многоверсионный генератор с валидатором, чтобы вы могли создавать ID по схеме и рано отклонять некорректные строки. Предпочитайте v4 для общего использования, v5 для стабильных ID из имён и всегда отделяйте авторизацию от непрозрачности идентификатора.