GUID и UUID: в чем разница?

GUID и UUID обычно обозначают один тип идентификатора: 128-битное значение, рассчитанное на уникальность без получения следующего номера от центрального счетчика. Названия возникли в разных традициях. UUID — термин стандарта, а GUID особенно распространен в программном обеспечении Microsoft и инструментах разработки.

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

Используйте генератор GUID в ClockTools для создания UUID v4 или UUID v7 в браузере, массовой генерации, проверки или подготовки к экспорту. Генерация и проверка выполняются локально в браузере.

GUID и UUID: они одинаковые?

В повседневной разработке GUID и UUID — взаимозаменяемые названия 128-битного идентификатора. Текущий стандарт IETF, RFC 9562, явно отмечает, что UUID также известны как глобальные уникальные идентификаторы. Такое значение, как 550e8400-e29b-41d4-a716-446655440000 поэтому его можно назвать либо UUID, либо GUID без изменения его символов.

Важно различать название и схему генерации. Название GUID не указывает, используется ли версия 4, версия 7, более старая версия на основе времени или платформозависимая схема. Название UUID также не гарантирует, что приложение принимает все стандартные версии. Название определяет общий тип данных; версия и требования системы определяют поведение значения.

Вот почему при сравнении GUID и UUID следует уделять меньше внимания тому, какое слово является «правильным», а больше — системным требованиям, стоящим за этим словом.

Почему используются два названия?

UUID означает универсальный уникальный идентификатор. Этот термин используют стандарты IETF, определяющие структуру, варианты, версии, текстовое представление и особенности генерации. GUID означает глобальный уникальный идентификатор и широко закрепился на платформах Microsoft. Знакомый пример — тип .NET System.Guid.

Оба названия сохранились, потому что экосистемы программного обеспечения сохраняют свой словарь для совместимости. Microsoft API может предоставлять Guidсхема PostgreSQL может использовать uuid столбец, а API JSON может вызвать поле id. Все три могут иметь одно и то же каноническое текстовое значение.

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

Как выглядит UUID?

Общая удобочитаемая форма содержит 32 шестнадцатеричных цифр, разделенных на пять групп:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Длины групп: 8, 4, 4, 4 и 12. Каноническая строка, включающая четыре дефиса, имеет длину 36 символов. M указывает полубайт версии в макетах, предусмотренных стандартом, а биты, представленные N определить вариант. Например, 4 в 550e8400-e29b-41d4-a716-446655440000 идентифицирует UUID версию 4.

Шестнадцатеричный регистр не меняет числовое значение. A716 и a716 представляют одни и те же биты. Дефисы, фигурные скобки, а urn:uuid: префикс или компактная форма могут изменить строку, принятую анализатором, но они не обязательно изменяют базовый идентификатор. Это одна из причин, по которой ClockTools отделяет генерацию от форматирования.

Чем отличаются UUID v4 и UUID v7?

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

UUID v7 упорядочен по времени. Первые 48 бит содержат метку времени Unix в миллисекундах; за ними идут версия, вариант и случайные данные. Более поздние значения обычно сортируются после более ранних. Это может быть удобнее для упорядоченных индексов и журналов: новые записи реже попадают в несвязанные позиции пространства ключей.

Упорядоченность по времени не означает строгую последовательность. Нескольким UUID v7, созданным в одну миллисекунду, все равно нужны дополнительные данные, чтобы оставаться различными; поведение часов также имеет значение. Это не означает и секретности: v7 изначально раскрывает приблизительное время создания. RFC 9562 содержит нормативные структуры и рекомендации по генерации обеих версий.

Какую версию выбрать?

Выберите версию, соответствующую принимающей системе и нужному вам поведению.

Не меняйте версию лишь потому, что она новее. Сначала проверьте драйвер базы данных, библиотеку валидации, схему API и системы, использующие значения дальше. Старый валидатор может отклонить корректный v7, если распознает только более ранние версии.

Может ли один UUID выглядеть по-разному?

Да. Одни и те же базовые биты 128 могут быть представлены в стандартном нижнем регистре, верхнем регистре, фигурных скобках, тексте в кавычках, компактном шестнадцатеричном формате или форме URN. ClockTools также может упаковывать сгенерированные значения в виде строк, CSV, JSON или выходных данных, удобных для SQL. Это выбор представления, а не новые идентификаторы.

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

Для строк запроса URL-адреса или сегментов пути по возможности используйте каноническую форму. Если окружающее значение необходимо экранировать, URL-кодер ClockTools может закодировать полный параметр без изменения самого идентификатора.

Как следует хранить GUID и UUID?

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

Хранение текста остается разумным, когда в системе отсутствует собственный тип или когда для совместимости требуется строка. В этом случае нормализуйте одно представление, определите допустимую длину и избегайте смешивания фигурных скобок, URN, заглавных букв и компактных значений в одном столбце. Согласованное форматирование упрощает проверки на равенство, экспорт и поддержку.

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

Как ClockTools может их генерировать и проверять?

Онлайн-генератор GUID и UUID предлагает следующий порядок действий:

1. Выберите UUID v4 для случайных идентификаторов или UUID v7 для идентификаторов, упорядоченных по времени.
2. Выберите количество от 1 до 1,000.
3. Выберите стандартную форму, верхний регистр, фигурные скобки, кавычки, компактную форму или URN.
4. Если принимающей системе это нужно, выберите обычное представление либо кодирование Base64, Base64URL или URL.
5. Экспортируйте в виде строк, CSV, JSON или SQL или копируйте результаты напрямую.
6. Вставьте существующее значение в валидатор, чтобы проверить его нормализованную форму, версию, вариант и распознанные специальные значения.

Генерация использует криптографический источник случайных данных браузера. UUID v4 устанавливает требуемые биты версии и варианта. UUID v7 объединяет текущее время Unix в миллисекундах со случайными данными и необходимыми битами структуры. Для этих операций страница не отправляет сгенерированные идентификаторы на сервер.

При сравнении двух экспортированных списков используйте Проверка текстовых различий чтобы обнаружить отсутствующую, повторяющуюся или переформатированную запись без сканирования каждой строки вручную.

Каких ошибок следует избегать?

Первая ошибка — считать, что «уникальный» означает «совпадения невозможны». При корректной генерации случайная коллизия UUID крайне маловероятна, но программа все равно должна использовать ограничение уникальности там, где дубликаты вредны. Неисправный источник случайных данных, скопированные тестовые данные, ошибка импорта или ошибка приложения могут создать дубликат даже при верных математических расчетах.

Вторая ошибка — считать UUID подтверждением права доступа. Трудно угадываемый идентификатор может снизить вероятность случайного обнаружения, но сам по себе не дает безопасного доступа. Проверяйте права аутентифицированного пользователя при каждом защищенном запросе.

Третья ошибка — молчаливое изменение представления. Удаление дефисов, декодирование Base64 или преобразование в байты должны быть обратимыми и протестированными. Сохраняйте одно каноническое значение в журналах, чтобы операторы могли отслеживать его между службами. Если анализатор отклоняет идентификатор, проверьте версию и формат перед созданием замены; замена идентификатора может привести к поломке ссылок, которые уже указывают на него.