UUID версий 4 и 7: до 1000 значений сразу, регистр, дефисы, фигурные скобки, кавычки, префикс urn:uuid: и свой разделитель. Значения v7 идут по возрастанию времени создания. Всё считается в браузере.
Значения пересобираются сами при смене версии или количества — нажимать «Сгенерировать» не нужно.
Пока нечего показать: .
UUID — идентификатор на 128 бит, который выдаётся без спроса и без согласования. Счётчик так не умеет: он живёт в одном месте, и два сервиса не могут выдать номера независимо. UUID можно сгенерировать где угодно — на сервере, в браузере, в очереди на другом конце мира — и совпадения при этом не будет. Поэтому его берут для записей в базе, имён файлов, сессий, ключей идемпотентности в API и всего, что переживает слияние данных из разных источников.
Версии различаются тем, что в них заложено. Версия 4 — случайные 122 бита: предсказать значение нельзя, порядок в списке случайный. Версия 7 — время создания в миллисекундах плюс 74 случайных бита: значения идут по возрастанию, список сортируется сам, и в базе новые записи ложатся в конец индекса, а не в случайные его места. Внутри одной миллисекунды порядок держит счётчик в 12 свободных битах, иначе сортировка была бы приблизительной — по миллисекунде, а не по значению.
Формат вывода — отдельная задача от генерации. Одним системам нужны 32 символа без дефисов, другие ждут фигурные скобки, кавычки или префикс urn:uuid:, а вставлять список приходится то построчно, то через запятую. Здесь это настраивается, а не правится руками: переключение формата не меняет сами значения, поэтому уже скопированный список остаётся тем же.
Всё считается в браузере: значения берутся из системного генератора (crypto.getRandomValues), страница никуда их не отправляет и не сохраняет. Перезагрузка страницы стирает результат вместе с настройками.
Версия 4 — это 122 случайных бита: значение нельзя предсказать, но и порядка в списке нет, он случайный. Версия 7 начинается с времени создания в миллисекундах, а случайными остаются 74 бита; за счёт этого значения, сгенерированные подряд, идут по возрастанию, и такой список можно сортировать как есть. Для первичного ключа в базе лучше v7: новые записи вставляются в конец индекса, а не в случайные его места, и страницы индекса не разъезжаются. Для токенов, ссылок и всего, где важна непредсказуемость, — v4 и только v4: по v7 видно время создания.
Это несколько зарезервированных бит, по которым читатель значения понимает, как оно получено. Версия занимает старший полубайт первой цифры третьего блока — тринадцатой шестнадцатеричной цифры значения: 4 у случайного UUID, 7 у упорядоченного по времени. Вариант — два старших бита семнадцатой шестнадцатеричной цифры, первой в четвёртом блоке; в RFC 4122 это 8, 9, a или b. Именно из-за них UUID версии 4 совпадает с шаблоном 8-4-4-4-12 не полностью: в третьем блоке первая цифра всегда 4, в четвёртом — всегда 8, 9, a или b, а остальные 122 бита случайны. Программы пользуются этими битами, чтобы не разбирать значение целиком, а сразу понять, есть ли в нём время.
Теоретически да, практически — нет. У версии 4 случайны 122 бита, то есть 5,3 · 10³⁶ вариантов. Чтобы вероятность совпадения достигла одного шанса из миллиарда, нужно сгенерировать около 10¹⁵ значений — это в сотни раз больше, чем секунд в году, и в миллиарды раз больше, чем UUID во всех существующих базах вместе. Отдельно сгенерированные значения версии 7 не повторяются и подавно: у них разное время в старших битах, а внутри одной миллисекунды за порядок отвечает счётчик, а не случайность — на 4096 значений приходится одна миллисекунда, и до совпадения дело не доходит. Проверить это на глаз нельзя, но и повода беспокоиться нет: коллизии UUID в реальных системах не встречались.
Это и не задумано как секрет: время создания — та самая часть, ради которой версию 7 и берут, чтобы значения сортировались. Плохо это только там, где по идентификатору можно судить о человеке или компании: например, по номеру заказа видно, когда его оформили, и конкурент считает объём продаж. Если такое знание нежелательно, берите v4 — в нём времени нет вовсе, или не показывайте UUID наружу. Для внутренних ключей базы время в идентификаторе безобидно и часто полезно.
Везде, где идентификатор нужно выдать, не спрашивая согласия у соседей. Запись в базе: счётчик требует единого места, а UUID можно сгенерировать на любом сервере и в любом браузере, не боясь совпадения при слиянии данных. Идентификаторы файлов, сессий, заказов, сообщений и ключи идемпотентности в API. Имена таблиц и очередей при переносе между средами. Промежуточные ключи в отчётах и выгрузках, где разные источники не должны пересекаться. Идентификаторы в BLE-сервисах, уведомлениях и файловых системах. По стандарту RFC 9562 UUID — это 128 бит, и он же описывает версии: 4 случайная, 7 по времени, остальные — устаревшие (1, 3, 5 по имени и хешу) или зарезервированные (6, 8).
Нет. UUID собирается из значений системного генератора браузера (crypto.getRandomValues) прямо на странице, никуда не передаётся и не сохраняется. Обновите страницу — значений не станет. Инструментом можно пользоваться офлайн, а сеть при этом не нужна ни на одном шаге.