Версии GUID: разбираем v1–v7 и какую выбрать

2026-07-09

Теги: Windows · GUID · Руководство · QuickGUID

---

Откройте любую библиотеку UUID — и вы увидите uuid1(), uuid3(), uuid4(), uuid5() и всё чаще uuid7(). Спецификация определяет восемь версий. Какую из них использовать на самом деле?

Короткий ответ: v4 для почти всего, v7 для первичных ключей баз данных, v5 когда нужно, чтобы одинаковый вход всегда давал одинаковый GUID. Остальная часть статьи объясняет почему — с раскладками байтов, настоящими причинами каждой версии и шпаргалкой по коду для разных языков.

Если вы новичок в GUID, начните с Что такое GUID? для основ структуры и уникальности. Этот пост — технический спутник, он разбирает каждую версию глубже.

Ландшафт версий GUID/UUID

Каждая версия — это отдельный рецепт заполнения одних и тех же 128 бит. Ниббл версии (первая шестнадцатеричная цифра третьего сегмента) говорит, какой рецепт использовали.

Версия	Источник генерации	Сортируемая	Типичное применение
v1	Время + MAC	Да	Унаследованные системы (риск приватности)
v2	DCE Security	Да	Редко, специализированно
v3	MD5-хеш пространства имён	Нет	Устарела (используйте v5)
v4	Случайная	Нет	Стандарт по умолчанию
v5	SHA-1-хеш пространства имён	Нет	Детерминированные ID
v6	Переупорядоченное время v1	Да	Прямая замена v1
v7	Метка времени в миллисекундах	Да	Первичные ключи БД
v8	Определяется поставщиком	Свой	Специализированно

Версии v1, v4, v5 и v7 покрывают 99 % реального использования. Пройдёмся по каждой.

v1: Время и MAC-адрес

v1 — это исходный рецепт из RFC 4122. Он упаковывает три вещи в 128 бит:

| time_low (32) | time_mid (16) | ver+time_hi (16) | var+clk_seq (16) | node/MAC (48) |

• 60-битная метка времени — интервалы по 100 наносекунд с 15.10.1582 (дата принятия григорианского календаря). Метка времени разбита по time_low, time_mid и time_hi.
• 14-битная последовательность часов — счётчик, различающий два GUID, сгенерированные в одном тике часов, или когда системные часы перевели назад.
• 48-битный узел — MAC-адрес сетевой карты.

Проблема MAC-адреса

Поле узла — это аппаратный отпечаток. Любой опубликованный v1-GUID несёт MAC-адрес вашей машины — и в отличие от IP-адреса, MAC-адрес задуман как глобально уникальный и постоянный. Это реальная утечка приватности.

Это не теория. Исследователи показали, что документы можно отследить до машины, которая их создала, просто прочитав v1-GUID, встроенные в метаданные файла. Сама Microsoft убрала генерацию v1 из телеметрии Office после того, как это продемонстрировали. Современные ОС по той же причине рандомизируют MAC-адрес, показываемый сетям Wi-Fi.

Вердикт: избегайте v1 в новом коде. Он выживает в унаследованных системах, COM-интерфейсах и некоторых аппаратно-смежных инструментах — но нет причин генерировать его самому сегодня.

v2: DCE Security

v2 — это версия, с которой вы по сути никогда не столкнётесь. Она берёт раскладку v1 (метка времени + MAC) и накладывает поверх неё POSIX UID/GID — локальные идентификаторы пользователя и группы из модели безопасности DCE (Distributed Computing Environment), — чтобы UUID мог нести информацию контроля доступа вдобавок к уникальности.

v2 существует для аутентификации DCE/RPC и ACL в унаследованных корпоративных системах. Если только вы не поддерживаете ПО, явно говорящее на DCE Security, вы никогда не сгенерируете и не потребите v2. Он здесь исключительно для полноты списка версий — чтобы вы не гадали, что значит «2» в этом ниббле, если однажды её встретите.

v3: Почему её списали

v3 идентична v5, кроме того, что использует MD5 вместо SHA-1. У MD5 есть практические атаки на коллизии — два разных входа можно так подобрать, чтобы они давали один хеш. Это ломает гарантию детерминизма v3 в условиях активного противника.

RFC 4122 сохранил v3 для обратной совместимости, но v5 её заменил. Нет причин генерировать v3 сегодня. Если встретите v3 в дикой природе, считайте его унаследованным.

v4: Случайный стандарт

v4 — это то, что вы получаете практически от каждого вызова «сгенерировать GUID»: [guid]::NewGuid(), Guid.NewGuid(), crypto.randomUUID(), uuid.uuid4(), NEWID(). Он заполняет 122 из 128 бит криптографически стойкой случайностью (остальные 6 бит — маркеры версии и варианта).

Никакой метки времени, никакого MAC, никакого состояния машины — чистая случайность. Это делает v4 безопасным для раскрытия, тривиально параллелизуемым и достаточно устойчивым к коллизиям для любой реалистичной нагрузки. Полную математику коллизий (и почему вирусное заявление «миллиард лет» неверно понимает парадокс дней рождения) см. в основной статье.

Вердикт: это ваш стандарт. Выбирайте v4, если только у вас нет конкретной причины выбрать что-то другое.

v5: Детерминированные ID пространства имён

Это та версия, о которой большинство разработчиков слышало, но никогда не использовало по-настоящему — а она решает вполне полезную задачу.

v5 позволяет получить тот же GUID из того же входа каждый раз. Дайте ему UUID пространства имён и строку имени — и он вернёт детерминированный идентификатор:

import uuid

# Одинаковый вход → одинаковый GUID, при каждом запуске, на любой машине
dns_guid = uuid.uuid5(uuid.NAMESPACE_DNS, 'example.com')
url_guid = uuid.uuid5(uuid.NAMESPACE_URL, 'https://prunelab.net/blog/guid-explained')

print(dns_guid)  # всегда  cf14e0a3-... (то же значение)
print(dns_guid == uuid.uuid5(uuid.NAMESPACE_DNS, 'example.com'))  # True

Как это работает

Внутренне v5 конкатенирует байты UUID пространства имён с UTF-8-байтами имени, прогоняет результат через SHA-1, берёт первые 16 байт, а затем ставит биты версии (5) и варианта. Само пространство имён — это UUID; NAMESPACE_DNS, NAMESPACE_URL, NAMESPACE_OID и NAMESPACE_X500 предопределены, но можно использовать любой UUID как пространство имён.

Когда v5 — правильный инструмент

• Воспроизводимые тестовые фикстуры — генерируйте ID для тестовых данных, которые остаются стабильными между прогонами, чтобы падающий тест каждый раз указывал на одну и ту же сущность.
• Идентификаторы, производные от URL — превратите URL в GUID без обращения к базе. Две системы, независимо вычисляющие uuid5(NAMESPACE_URL, url) для одного URL, всегда сойдутся.
• Идемпотентная дедупликация — импортируйте одну запись дважды, и GUID столкнётся сам с собой, так что дубликат определяется только по ключу.

Ключевой контраст с v4: v4 возвращает уникальное значение на каждый вызов (даже для одинаковых входов); v5 возвращает стабильное значение для одинаковых входов. Они не взаимозаменяемы.

Вердикт: обращайтесь к v5 всякий раз, когда вам нужен GUID, который воспроизводимо выводится из некоторой входной строки.

v6: Починка v1, которая вам, скорее всего, не нужна

v6 содержит ровно те же данные, что v1 — ту же метку времени, ту же последовательность часов и MAC, — но переупорядочивает биты метки времени так, чтобы значение естественным образом сортировалось в хронологическом порядке. В v1 метка времени неудобно разбита (low, mid, high); в v6 она хранится high-first, поэтому лексикографическая сортировка строк равна сортировке по времени.

v6 был стандартизирован в 2024 году в RFC 9562 вместе с v7. Он существует в основном как прямой путь миграции для систем, уже привязанных к модели часы-и-MAC у v1: вы сохраняете существующую логику метки времени и просто переписываете раскладку битов.

Для новых систем v7 почти всегда лучший выбор. v7 использует метку времени в миллисекундах (проще, чем григорианский 100-нс отсчёт v1/v6), не встраивает MAC-адрес и имеет более чистое случайное заполнение. v6 отвечает на «как модернизировать v1, не меняя модель генерации»; v7 отвечает на «что использовать дальше».

v7: Упорядоченный по времени для баз данных

v7 — самое важное добавление со времён v4. Он решает проблему, которую v4 создаёт в базах данных.

Проблема v4 в базе данных

Когда база данных использует GUID как первичный ключ, этот ключ поддерживает индекс на B+-дереве. B+-деревья остаются эффективными, когда вставки примерно упорядочены — новые значения попадают на правый край и заполняют существующие страницы. Случайные v4-GUID разбросаны по всему пространству ключей, поэтому каждая вставка бьёт по случайной странице. На больших таблицах это вызывает постоянные расщепления страниц, фрагментацию индекса, трэш кэша и усиление записи. Починка в SQL Server (NEWSEQUENTIALID()) — проприетарный, непереносимый хак, который течёт последовательностью.

Раскладка v7

| unix_ts_ms (48) | ver (4) | rand_a (12) | var (2) | rand_b (62) |

• 48-битная Unix-метка в миллисекундах — ведущее поле, поэтому значения растут со временем.
• 4-битная версия — установлена в 7.
• 12-бит rand_a — случайно, либо опционально монотонный счётчик для упорядочивания в пределах одной миллисекунды.
• 2-битный вариант — стандартный маркер RFC 9562.
• 62-бит rand_b — случайно.

Поскольку метка времени идёт первой, v7-GUID, сгенерированные последовательно, естественным образом упорядочены: вставки в индекс скапливаются на правом краю, страницы заполняются чисто, а B+-дерево ведёт себя как с автоинкрементным целым — оставаясь при этом глобально уникальным без центрального координатора.

Когда v7 НЕ стоит того

• Хранилища в памяти (Redis, memcached) — нет B+-дерева, нет стоимости фрагментации. v4 подойдёт.
• Маленькие таблицы — разница между v4 и v7 незаметна ниже миллионов строк.
• Неключевые столбцы — если GUID просто хранимый атрибут, а не ключ индекса, порядок не важен.
• GUID, которые должны быть непрозрачными — v7 течёт миллисекундой генерации, что может быть нежелательно в контекстах, чувствительных к безопасности.

Вердикт: если GUID — кластеризованный первичный ключ в настоящей базе данных, используйте v7. В остальных случаях v4.

v8: Определяется поставщиком

v8 — это запасной выход: RFC 9562 позволяет поставщику определять собственную раскладку битов, лишь бы ниббл версии содержал 8, а биты варианта были корректны. Всё остальное — ширина метки времени, источник случайности, кодировка — на усмотрение разработчика.

v8 вы встретите лишь в системах, спроектировавших собственную схему UUID по конкретной причине (например, чтобы встроить shard ID или node ID в UUID для маршрутизации). Если вы не строите такую систему, v8 не имеет значения; а если строите, правила диктует ваша собственная схема, а не что-либо в этой статье.

Какую версию вам стоит использовать на самом деле?

Путеводитель по решению:

• «Генерирую ID для общего использования?» → v4. Это ответ в 90 % случаев.
• «Первичный ключ БД или нужно упорядочивание по времени?» → v7. Особенно для кластеризованных индексов на больших таблицах.
• «Нужен один и тот же GUID для одного и того же входа каждый раз?» → v5. Детерминированное отображение из строки.
• «Работаю с унаследованной системой, ожидающей v1?» → v1 (сохраните совместимость), но планируйте миграцию на v7.
• «Кто-то посоветовал v3?» → Не надо. Используйте v5 вместо неё (MD5 в v3 сломан).
• «Я хочу самое новое.» → Это не причина. v7 — новое и решает реальную проблему (порядок в БД); v6 — новое и в основном подспорье для миграции с v1. Выбирайте по сценарию, а не по новизне.

Если всё ещё сомневаетесь — берите v4. Стандарт по умолчанию существует не просто так.

Генерация GUID по версии и языку

Язык / инструмент	v4 (по умолчанию)	v5 (детерминированный)	v7 (упорядоченный)
PowerShell	[guid]::NewGuid()	—	—
C# / .NET	Guid.NewGuid()	—	Guid.CreateVersion7() (.NET 9+)
Python	uuid.uuid4()	uuid.uuid5(uuid.NAMESPACE_URL, 'name')	uuid.uuid7() (3.14 beta) / библиотека
JavaScript	crypto.randomUUID()	—	(npm uuid v11+)
Node.js (библ. uuid)	uuid.v4()	uuid.v5('name', NAMESPACE)	uuid.v7()
SQL Server	NEWID()	—	—
PostgreSQL	gen_random_uuid()	—	(расширение)

Несколько замечаний: нативная поддержка v7 в 2026 году всё ещё встраивается в стандартные библиотеки. Пакет uuid для Node.js (v11+) и .NET 9 поставляют её нативно; Python добавляет uuid.uuid7() в 3.14; более старым рантаймам нужна библиотека. Поддержка v5 почти повсеместна, потому что это чистая SHA-1-математика без требования источника энтропии.

Часто задаваемые вопросы

Заменит ли v7 v4 в качестве стандарта?

Нет. v4 остаётся общим стандартом. v7 выигрывает только когда GUID — упорядоченный первичный ключ; для большинства остальных применений (сессионные токены, ID запросов, хеши контента, всё не-БД) случайность v4 не недостаток, а ведущая метка времени v7 лишь утекала бы информацией о тайминге без пользы.

Безопасно ли ещё использовать v1?

Нет. v1 встраивает MAC-адрес вашей сетевой карты — постоянный аппаратный отпечаток. Сама Microsoft убрала v1 из телеметрии Office после того, как исследователи отследили машины по документам через встроенные GUID. Для нового кода избегайте v1 целиком; для унаследованного v1 планируйте миграцию на v7.

В чём разница между v3 и v5?

Оба — детерминированные хеши пространства имён (одинаковый вход → одинаковый GUID). v3 использует MD5, v5 использует SHA-1. У MD5 есть практические атаки на коллизии, поэтому v3 считается сломанным для целей целостности и был заменён на v5. Нет причин генерировать v3 сегодня.

Могу ли я преобразовать v4-GUID в v7?

Нет. Версия — это не ярлык, который можно переставить; каждая версия использует совершенно разную логику генерации. У v4 нет метки времени для извлечения, поэтому единственный способ «получить v7» — сгенерировать новый. Если нужно мигрировать столбец первичного ключа с v4 на v7, вы фактически добавляете новый столбец и переписываете его.

Поддерживает ли .NET v7 нативно?

Да. Guid.CreateVersion7() был добавлен в .NET 9 (выпущен в ноябре 2024 года). Если вы на .NET 8 или старше, используйте пакеты NuGet GenVault или UUIDv7, либо обновитесь.

QuickGUID: генерация v4 и v7, конвертация любого формата

Для повседневной работы с GUID QuickGUID — нативный набор инструментов Windows, покрывающий весь процесс:

• Пакетная генерация v4 или v7, до 1 000 за раз
• Конвертация 10+ форматов: стандартный, без дефисов, в фигурных скобках, Base64, массив байт C, макрос DEFINE_GUID — всё с живым предпросмотром
• Умная экстракция: вставьте логи или исходный код, автоматически найдите и преобразуйте каждый GUID
• Живые декораторы: кавычки, префиксы/суффиксы, регистр — переключаются глобально и копируются напрямую

Полностью бесплатно, 100% офлайн.

В заключение

Система версий существует потому, что разные задачи требуют разных гарантий: v4 даёт неотслеживаемую случайность, v5 даёт воспроизводимость, v7 даёт упорядоченность. По умолчанию v4, обращайтесь к v7 на ключах БД и используйте v5, когда одинаковые входы должны давать одинаковые GUID.

Новичок в GUID? Начните с Что такое GUID? — там основы структуры, формат с дефисами и почему 128 бит достаточно, чтобы коллизии на практике перестали быть проблемой.