Что такое Генератор коротких UUID
UUID всегда занимает 16 байт, но привычная запись расточительна: 36 символов, из которых четыре — дефисы, а 32 используют лишь 16 символов, допустимых в URL. Перекодирование тех же байт в base64url даёт 22 символа — экономия 39% без потерь, и результат можно вставлять в query-строку, имя файла или cookie без экранирования.
Энтропию вы выбираете сами. 8 байт дают 64 бита, 12 байт — 96, а полные 16 байт сохраняют 128 бит UUID. Граница дней рождения делает компромисс наглядным: при 64 битах коллизия становится реальной уже после нескольких сотен миллионов значений, 96 бит безопасны для любой разумной таблицы, а 128 бит практически недостижимы.
Вы теряете структуру. У сжатого UUID нет нибла версии и битов варианта, поэтому он больше не описывает сам себя: база не извлечёт из него метку времени, а валидатор не скажет, какая это версия. Если метаданные нужны — берите настоящий v4 или v7; если нужен компактный непрозрачный ключ — короткая форма подходит лучше.
Как использовать
- Укажите сколько идентификаторов нужно.
- Выберите байт случайности: 8 байт — 11 символов, 12 — 16, 16 — 22-символьный сжатый UUID.
- Нажмите Сгенерировать, затем скопируйте одно значение или выгрузите весь пакет.
Сценарии
- Короткие ссылки и файлы, когда 36-символьное имя неудобно читать и вставлять.
- Компактные ключи базы, когда текстовый столбец на 22 символа дешевле столбца на 36.
- Ключи кеша и request id, где значение должно быть лишь уникальным, а не разбираемым.
Сравнение Генератор коротких UUID с другими форматами
| Вариант | Когда использовать |
|---|---|
Канонический UUID | 36 символов, 128 бит, самоописывающий (есть версия и вариант). |
Base64url UUID | 22 символа, 128 бит, без метаданных — сжатие без потерь. |
12 случайных байт | 16 символов, 96 бит — достаточно для очень больших таблиц. |
8 случайных байт | 11 символов, 64 бита — годится для кеша, рискованно как постоянный первичный ключ. |
Примеры кода
JavaScript
// Node 18+ и современные браузеры: 16 байт -> 22 символа
const bytes = crypto.getRandomValues(new Uint8Array(16));
const id = Buffer.from(bytes).toString('base64url'); // 22 символа
// Вариант только для браузера
const id2 = btoa(String.fromCharCode(...bytes))
.replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');
Python
import os, base64
# 16 байт -> 22 символа без выравнивания, безопасно для URL
id_ = base64.urlsafe_b64encode(os.urandom(16)).rstrip(b'=').decode()
# 8 байт -> 11 символов
short = base64.urlsafe_b64encode(os.urandom(8)).rstrip(b'=').decode()
# Обратно в канонический вид
import uuid
raw = base64.urlsafe_b64decode(id_ + '==')
print(uuid.UUID(bytes=raw))
Частые вопросы
Короткие идентификаторы остаются уникальными?
Настолько, насколько вы дали бит. 16 байт содержат ровно те же 128 бит, что и UUID, поэтому вероятность коллизии такая же. Восемь байт сокращают пространство до 264: коллизия вероятна после нескольких сотен миллионов значений — это нормально для кеша, но мало для постоянного реестра.
Можно ли превратить короткий ID обратно в UUID?
Да, если использовались 16 байт: декодируйте base64url и получите исходные 16 байт, то есть корректный UUID в бинарном виде. С 8 или 12 байтами восстанавливать нечего — этих бит там никогда не было.
Стоит ли использовать это как первичный ключ?
Только если столбец текстовый и базе не нужно читать метку времени из ключа. Если важен порядок, лучше подойдёт упорядоченный по времени UUID v7 в родном типе uuid.