Uuid converter что это

Обновлено: 07.07.2024

В этом разделе представлены сведения об универсальных уникальных идентификаторах (UUID) и служебной программе uuidgen в следующих разделах:

Что такое UUID?

Все интерфейсы должны быть однозначно идентифицированы в сети, чтобы клиенты могли их найти. В небольших сетях только имя интерфейса может быть достаточным для его распознавания. Однако это обычно нецелесообразно для больших сетей. Таким образом, разработчики обычно присваивают каждому интерфейсу универсальный уникальный идентификатор (UUID, взаимозаменяемый с термином GUID или глобальный уникальный идентификатор). UUID — это строка, содержащая набор шестнадцатеричных цифр. Каждый интерфейс имеет другой UUID. Дополнительные сведения см. в разделе строковый UUID.

Текстовое представление UUID — это строка, состоящая из 8 шестнадцатеричных цифр, за которыми следует дефис, за которым следуют три группы, разделенные дефисами 4 шестнадцатеричных цифр, за которыми следует дефис, за которым следуют 12 шестнадцатеричных цифр. Следующий пример является допустимой строкой UUID:

Пустые UUID называются пустыми UUID, а не нулевыми UUID. Термин nil означает все, что равно нулю, пусто, пусто или не инициализировано. Пустая строка, пустая запись базы данных или неинициализированный UUID являются примерами пустых значений.

Значение null — это конкретное нулевое значение. Он часто используется в программировании C и C++ вместе с указателями. Nil является более общим термином, чем null. Неинициализированные UUID интерфейсов объектов всегда должны называться пустыми UUID, а не нулевыми UUID.

Использование uuidgen

Корпорация Майкрософт предоставляет служебную программу с именем uuidgen для создания идентификаторов UUID. Служебная программа Uuidgen создает UUID в формате IDL-файла или в формате языка C.

При запуске служебной программы uuidgen из командной строки можно использовать следующие параметры команды.

Uuidgen, параметр Описание
/I Выводит UUID в шаблон интерфейса IDL.
/s Выводит UUID в виде инициализированной структуры C.
/o < имя файла> Перенаправляет выходные данные в файл; указывается сразу после параметра /o .
/n < число> Указывает число создаваемых UUID.
/v Отображает сведения о версии uuidgen.
/h или ? Отображает сводку по параметрам команды.

Как правило, используется служебная программа Uuidgen, как показано в следующем примере.

uuidgen-i-Омяпп. idl

Эта команда создает UUID и сохраняет его в файле MIDL, который можно использовать в качестве шаблона. При выполнении предыдущей команды содержимое файла MyApp. idl будет выглядеть следующим образом:

Следующим шагом будет замена имени заполнителя, INTERFACENAME, фактическим именем интерфейса.


Вы наверняка уже использовали в своих проектах UUID и полагали, что они уникальны. Давайте рассмотрим основные аспекты реализации и разберёмся, почему UUID практически уникальны, поскольку существует мизерная возможность возникновения одинаковых значений.

Современную реализацию UUID можно проследить до RFC 4122, в котором описано пять разных подходов к генерированию этих идентификаторов. Мы рассмотрим каждый из них и пройдёмся по реализации версии 1 и версии 4.

Теория


Информация о реализации UUID встроена в эту, казалось бы, случайную последовательность символов:


Значения на позициях M и N определяют соответственно версию и вариант UUID.

Версия

Номер версии определяется четырьмя старшими битами на позиции М. На сегодняшний день существуют такие версии:


Вариант

Это поле определяет шаблон информации, встроенной в UUID. Интерпретация всех остальных битов в UUID зависит от значения варианта.

Мы определяем его по первым 1-3 старшим битам на позиции N.


Сегодня чаще всего используют вариант 1, при котором MSB0 равняется 1 , а MSB1 равняется 0 . Это означает, что с учётом подстановочных знаков — битов, отмеченных х — единственными возможными значениями будут 8 , 9 , A или B .

1 0 0 0 = 8
1 0 0 1 = 9
1 0 1 0 = A
1 0 1 1 = B

Так что если вы видите UUID с такими значениями на позиции N, то это идентификатор в варианте 1.

Версия 1 (время + уникальный или случайный идентификатор хоста)

В этом случае UUID генерируется так: к текущему времени добавляется какое-то идентифицирующее свойство устройства, которое генерирует UUID, чаще всего это MAC-адрес (также известный как ID узла).

Тактовая последовательность — это просто значение, инкрементируемое при каждом изменении часов.

Временная метка, которая используется в этой версии, представляет собой количество 100-наносекундных интервалов с 15 октября 1582 года — даты возникновения григорианского календаря.

Возможно, вы знакомы с принятым в Unix-системах исчислением времени с начала эпохи. Это просто другая разновидность Нулевого дня. В сети есть сервисы, которые помогут вам преобразовать одно временное представление в другое, так что не будем на этом останавливаться.

Хотя эта реализация выглядит достаточно простой и надёжной, однако использование MAC-адреса машины, на которой генерируется идентификатор, не позволяет считать этот метод универсальным. Особенно, когда главным критерием является безопасность. Поэтому в некоторых реализациях вместо идентификатора узла используется 6 случайных байтов, взятых из криптографически защищённого генератора случайных чисел.

Сборка UUID версии 1 происходит так:

  1. Берутся младшие 32 бита текущей временной метки UTC. Это будут первые 4 байта (8 шестнадцатеричных символов) UUID [ TimeLow ].
  2. Берутся средние 16 битов текущей временной метки UTC. Это будут следующие 2 байта (4 шестнадцатеричных символа) [ TimeMid ].
  3. Следующие 2 байта (4 шестнадцатеричных символа) конкатенируют 4 бита версии UUID с оставшимися 12 старшими битами текущей временной метки UTC (в которой всего 60 битов) [ TimeHighAndVersion ].
  4. Следующие 1-3 бита определяют вариант версии UUID. Оставшиеся биты содержат тактовую последовательность, которая вносит небольшую долю случайности в эту реализацию. Это позволяет избежать коллизий, когда в одной системе работает несколько UUID-генераторов: либо системные часы переводятся назад для генератора, либо изменение времени замедляется [ ClockSequenceHiAndRes && ClockSequenceLow ].
  5. Последние 6 байтов (12 шестнадцатеричных символов, 48 битов) — это «идентификатор узла», в роли которого обычно выступает MAC-адрес генерирующего устройства [ NodeID ].


Поскольку эта реализация зависит от часов, нам нужно обрабатывать пограничные ситуации. Во-первых, для минимизации коррелирования между системами по умолчанию тактовая последовательность берётся как случайное число — так делается лишь один раз за весь жизненный цикл системы. Это даёт нам дополнительное преимущество: поддержку идентификаторов узлов, которые можно переносить между системами, поскольку начальное значение тактовой последовательности совершенно не зависит от идентификатора узла.

Помните, что главная цель использования тактовой последовательности — внести долю случайности в наше уравнение. Биты тактовой последовательности помогают расширить временную метку и учитывать ситуации, когда несколько UUID генерируются ещё до того, как изменяются процессорные часы. Так мы избегаем создания одинаковых идентификаторов, когда часы переводятся назад (устройство выключено) или меняется идентификатор узла. Если часы переведены назад, или могли быть переведены назад (например, пока система была отключена), и UUID-генератор не может убедиться, что идентификаторы сгенерированы с более поздними временными метками по сравнению с заданным значением часов, тогда нужно изменить тактовую последовательность. Если нам известно её предыдущее значение, его можно просто увеличить; в противном случае его нужно задать случайным образом или с помощью высококачественного ГПСЧ.

Версия 2 (безопасность распределённой вычислительной среды)

Главное отличие этой версии от предыдущей в том, что вместо «случайности» в виде младших битов тактовой последовательности здесь используется идентификатор, характерный для системы. Часто это просто идентификатор текущего пользователя. Версия 2 используется реже, она очень мало отличается от версии 1, так что идём дальше.

Версия 3 (имя + MD5-хэш)

Если нужны уникальные идентификаторы для информации, связанной с именами или наименованием, то для этого обычно используют UUID версии 3 или версии 5.

Они кодируют любые «именуемые» сущности (сайты, DNS, простой текст и т.д.) в UUID-значение. Самое важное — для одного и того же namespace или текста будет сгенерирован такой же UUID.

Обратите внимание, что namespace сам по себе является UUID.


В этой реализации UUID namespace преобразуется в строку байтов, конкатенированных с входным именем, затем хэшируется с помощью MD5, и получается 128 битов для UUID. Затем мы переписываем некоторые биты, чтобы точно воспроизвести информацию о версии и варианте, а остальное оставляем нетронутым.

Важно понимать, что ни namespace, ни входное имя не могут быть вычислены на основе UUID. Это необратимая операция. Единственное исключение — брутфорс, когда одно из значений (namespace или текст) уже известно атакующему.

При одних и тех же входных данных генерируемые UUID версий 3 и 5 будут детерминированными.

Версия 4 (ГПСЧ)

Самая простая реализация.

6 битов зарезервированы под версию и вариант, остаётся ещё 122 бита. В этой версии просто генерируется 128 случайных битов, а потом 6 из них заменяется данными о версии и варианте.

Такие UUID полностью зависят от качества ГПСЧ (генератора псевдослучайных чисел). Если его алгоритм слишком прост, или ему не хватает начальных значений, то вероятность повторения идентификаторов возрастает.

В современных языках чаще всего используются UUID версии 4.

Её реализация достаточно простая:

  1. Генерируем 128 случайных битов.
  2. Переписываем некоторые биты корректной информацией о версии и варианте:

  1. Берём седьмой бит и выполняем c 0x0F операцию AND для очистки старшего полубайта. А затем выполняем с 0x40 операцию OR для назначения номера версии 4.
  2. Затем берём девятый байт, выполняем c 0x3F операцию AND и с 0x80 операцию OR.

Версия 5 (имя + SHA-1-хэш)

Единственное отличие от версии 3 в том, что мы используем алгоритм хэширования SHA-1 вместо MD5. Эта версия предпочтительнее третьей (SHA-1 > MD5).

Практика

Одним из важных достоинств UUID является то, что их уникальность не зависит от центрального авторизующего органа или от координации между разными системами. Кто угодно может создать UUID с определённой уверенностью в том, что в обозримом будущем это значение больше никем не будет сгенерировано.

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

UUID можно использовать в качестве первичных ключей в базах данных, в качестве уникальных имён загружаемых файлов, уникальных имён любых веб-источников. Для их генерирования вам не нужен центральный авторизующий орган. Но это обоюдоострое решение. Из-за отсутствия контролёра невозможно отслеживать сгенерированные UUID.

Есть и ещё несколько недостатков, которые нужно устранить. Неотъемлемая случайность повышает защищённость, однако она усложняет отладку. Кроме того, UUID может быть избыточным в некоторых ситуациях. Скажем, не имеет смысла использовать 128 битов для уникальной идентификации данных, общий размер которых меньше 128 битов.

Уникальность

Может показаться, что если у вас будет достаточно времени, то вы сможете повторить какое-то значение. Особенно в случае с версией 4. Но в реальности это не так. Если бы вы генерировали один миллиард UUID в секунду в течение 100 лет, то вероятность повторения одного из значений была бы около 50 %. Это с учётом того, что ГПСЧ обеспечивает достаточное количество энтропии (истинная случайность), иначе вероятность появления дубля будет выше. Более наглядный пример: если бы вы сгенерировали 10 триллионов UUID, то вероятность появления двух одинаковых значений равна 0,00000006 %.

А в случае с версией 1 часы обнулятся только в 3603 году. Так что если вы не планируете поддерживать работу своего сервиса ещё 1583 года, то вы в безопасности.

Впрочем, вероятность появления дубля остаётся, и в некоторых системах стараются это учитывать. Но в подавляющем большинстве случаев UUID можно считать полностью уникальными. Если вам нужно больше доказательств, вот простая визуализация вероятности коллизии на практике.

UUID - это аббревиатура универсального уникального идентификатора, который представляет собой уникальный идентификатор, сгенерированный машиной в определенном диапазоне (от определенного пространства имен до мира). UUID имеет следующие значения:

Чтобы гарантировать уникальность UUID, спецификация определяет элементы, включая MAC-адрес сетевой карты, временную метку, пространство имен (Namespace), случайное или псевдослучайное число, время и другие элементы, а также алгоритм для генерации UUID из этих элементов. Сложные характеристики UUID означают, что он может быть сгенерирован только компьютером, обеспечивая его уникальность.

  • Обозначение без ручного управления, идентификация без ручного управления

UUID нельзя указать вручную, если вы не рискуете дублировать UUID. Сложность UUID определяет, что «нормальные люди» не могут напрямую знать, какой объект связан с UUID.

  • Возможность повторения в определенном диапазоне крайне мала.

Основная цель алгоритма, определенного спецификацией генерации UUID, - обеспечить его уникальность. Но эта уникальность ограничена и может быть гарантирована только в пределах определенного диапазона, который связан с типом UUID (см. Версию UUID).

Буквы в нем в шестнадцатеричной системе счисления, независимо от регистра.

-Timestamp + номер версии UUID, разделенный на три сегмента, занимающих 16 символов (60 бит + 4 бит),
- Порядковый номер часов и зарезервированное поле, занимающее 4 символа (13 бит + 3 бит),
- идентификатор узла занимает 12 символов (48 бит),

GUID (глобальный уникальный идентификатор) - это псевдоним UUID; но в практических приложениях GUID обычно относится к UUID, реализованному Microsoft.

UUID имеет несколько версий, и каждая версия имеет разные алгоритмы и разные диапазоны приложений.

Во-первых, это особый случай - Nil UUID - обычно мы его не используем, он состоит из всех 0 чисел, как показано ниже:

UUID, версия 1: UUID на основе времени

Поскольку метка времени имеет полные 60 бит, вы можете потратить ее столько, сколько захотите, со 100 наносекундами как 1, считая с 15 октября 1582 года (может длиться 3655 лет, действительно сжечь больше цифр, 1582 интересно)

Идентификатор узла также имеет 48 битов, обычно выражаемых MAC-адресом, если есть несколько сетевых карт, просто используйте одну. Если у вас нет сетевой карты, используйте случайные числа, чтобы составить числа, или возьмите кучу другой информации, например имена хостов, и хешируйте их вместе.

16-битный порядковый номер используется только во избежание предыдущего изменения метки узла (например, смены сетевой карты), проблем с системой часов (например, замедления часов после перезапуска), пусть он будет случайным, чтобы избежать дублирования.

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

Спящий режимCustomVersionOneStrategy.java, Что решает две проблемы версии 1 до

Стоит отметить, что 64-битный Long, состоящий из машинного процесса и идентификатора процесса, почти не изменился, и достаточно другого Long.

Вариант версии 1-MongoDB

-Timestamp (4 байта, 32 бита): находится на втором уровне и может длиться 136 лет с 1970 года.

-Последовательность инкремента (3 байта 24 бита, максимум 16 миллионов): это Int, который начинается со случайного числа (свидетель) и непрерывно увеличивается на единицу, и не существует такой вещи, как отметка времени, которая вернется к нулю через одну секунду. . Поскольку имеется только 3 байта, 4 байта Int необходимо усечь на 3 байта.

-Machine ID (3 байта 24 бит): соедините Mac-адреса всех сетевых карт вместе, чтобы получить HashCode, и тот же int должен быть усечен, а затем 3 байта. Если вы не можете получить сетевую карту, используйте случайное число, чтобы смешать ее.

-Process ID (2 байта 16 бит): получить номер процесса из JMX. Если вы его не получили, используйте хэш или случайное число имени процесса, чтобы смешать его.

Видно, что дизайн каждого поля MongoDB немного разумнее, чем Hibernate, например, временная метка находится на втором уровне. Общая длина также была уменьшена до 12 байтов 96 бит, но если вы используете 64 бит Long для сохраненияНе могу встать, Может быть выражено только как массив байтов или шестнадцатеричная строка.

Вдобавок, похоже, есть ошибка в последовательности автоматического увеличения для Java-версии драйвера.

Диспетчер снежинок Twitter

Snowflake также является диспетчером, сервисом на основе Thrift, но вместо простого самоприращения с помощью redis он похож на UUID версии 1.

Есть только одна длинная 64-битная длина, поэтомуIdWorkerРаспределены по:

-Timestamp (42bit) Количество миллисекунд с 2012 года (по сравнению с 1970 годом) может длиться 139 лет.
- последовательность автоинкремента (12 бит, максимум 4096), автоинкремент в миллисекундах и сброс на 0 через одну миллисекунду.
-DataCenter ID (5 бит, максимум 32), значение конфигурации.
- ID рабочего (5 бит, максимум 32), значение конфигурации. Поскольку это идентификатор диспетчера, достаточно 32 диспетчеров в центре обработки данных. Зарегистрируйтесь в ZK.

Можно видеть, что, поскольку это диспетчер чисел, идентификатор машины и идентификатор процесса опускаются, поэтому он может быть выражен только одним Long.

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

UUID версии 2: защищенный UUID DCE


Безопасный UUID DCE (распределенной вычислительной среды) и алгоритм UUID на основе времени одинаковы, но первые 4 позиции временной метки будут заменены на POSIX UID или GID. Эта версия UUID редко используется на практике.

UUID версии 3: UUID на основе имени (MD5)

UUID на основе имени получается путем вычисления хеш-значения MD5 имени и пространства имен. Эта версия UUID гарантирует: уникальность UUID, сгенерированных разными именами в одном пространстве имен; уникальность UUID в разных пространствах имен; повторное создание UUID с одним и тем же именем в одном пространстве имен одинаково.

UUID версии 4: случайный UUID

Сгенерировать UUID на основе случайного числа или псевдослучайного числа. Вероятность повторения этого UUID можно рассчитать, но случайные вещи похожи на покупку лотерейного билета: вы не можете рассчитывать на то, что он принесет вам целое состояние, но дерьмовая удача обычно приходит случайно.

UUID версии 5: UUID на основе имени (SHA1)

похож на алгоритм UUID версии 3, за исключением того, что при вычислении значения хеш-функции используется алгоритм SHA1 (алгоритм безопасного хеширования 1).

Из различных версий UUID видно, что версия 1/2 подходит для использования в распределенной вычислительной среде и имеет высокую степень уникальности; версия 3/5 подходит для уникальных имен в определенном диапазоне. И в средах, где UUID требуются или могут генерироваться повторно; что касается версии 4, я лично рекомендую не использовать ее (хотя это самый простой и удобный вариант).

Обычно мы рекомендуем использовать UUID для идентификации объектов или постоянных данных, но лучше не использовать UUID в следующих ситуациях:

  • Объект типа отображения. Например, кодовая таблица только с кодами и названиями.
  • Обслуживаемые вручную несистемные объекты. Например, некоторые основные данные в системе.

Для объектов с естественными характеристиками неповторяющихся имен лучше всего использовать UUID версии 3/5. Например, пользователи в системе. Если UUID пользователя версии 1, если вы случайно удалите его, а затем перестроите пользователя, вы обнаружите, что этот человек по-прежнему является этим человеком, а пользователь больше не является этим пользователем. (Хотя отметка как удаленная также является решением, это усложняет реализацию.)

Я не ожидал, что кто-то самостоятельно реализует генератор UUID после прочтения этой статьи, поэтому предыдущее содержание не содержит деталей алгоритма. Вот несколько доступных генераторов Java UUID:

  • Java UUID Generator (JUG): генератор UUID с открытым исходным кодом, протокол LGPL, поддержка MAC-адресов. : Специальная лицензия с исходным кодом.
  • Встроенный генератор UUID в Java 5 и выше: кажется, что можно сгенерировать только UUID версии 3/4.

Кроме того, в Hibernate есть также генератор UUID, но это не UUID какой-либо (стандартной) версии, и это настоятельно не рекомендуется.

Метод генерации

Собраны некоторые методы генерации UUID, организованные следующим образом

Shell

    В большинстве сред Unix / Linux есть небольшой инструмент под названием uuidgen, который может генерировать UUID для стандартного вывода, запустив

Прочитать файл /proc/sys/kernel/random/uuid Получите UUID, например:

libuuid

Необходимо связать библиотеку uuid при компиляции под Linux

В Ubuntu libuuid можно установить с помощью следующей команды:

boost uuid

Библиотека BoostЭто переносимая библиотека C ++ с открытым исходным кодом, которая обеспечивает реализацию UUID.

Следующий код может генерировать UUID

Qt QUuid

Qt - этоКроссплатформенностьВ среде программирования C ++ класс QUuid реализует такие функции, как генерация, сравнение и преобразование UUID.

функция QUuid createUuid(); Может использоваться для генерации случайного UUID. Примеры следующие

CoCreateGuid

Функция CoCreateGuid предоставляется под Windows для генерации GUID. Используемый заголовочный файл - objbase.h, связываемая библиотека - ole32.lib, а прототип функции:

UUID поддерживается выше JDK 1.5, использование выглядит следующим образом:


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

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

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

СОДЕРЖАНИЕ

История

В 1980-х годах Apollo Computer первоначально использовала UUID в сетевой вычислительной системе (NCS), а затем в распределенной вычислительной среде (DCE) Open Software Foundation (OSF ). Первоначальный дизайн DCE UUID был основан на NCS UUID, дизайн которого, в свою очередь, был вдохновлен ( 64-битными ) уникальными идентификаторами, определенными и широко используемыми в Domain / OS , операционной системе, разработанной Apollo Computer. Позже платформы Microsoft Windows приняли дизайн DCE как «глобальные уникальные идентификаторы» (GUID). RFC 4122 зарегистрировал пространство имен URN для UUID и резюмировал более ранние спецификации с тем же техническим содержанием. Когда в июле 2005 года RFC 4122 был опубликован в качестве предлагаемого стандарта IETF , ITU также стандартизировал UUID на основе предыдущих стандартов и ранних версий RFC 4122.

Стандарты

UUID стандартизированы Open Software Foundation (OSF) как часть распределенной вычислительной среды (DCE).

UUID задокументированы как часть ISO / IEC 11578: 1996 « Информационные технологии - Взаимодействие открытых систем - Удаленный вызов процедур (RPC)», а недавно - в Рек. МСЭ-Т Rec. X.667 | ИСО / МЭК 9834-8: 2005.

Engineering Task Force Интернет (IETF) опубликовала стандарты-Track RFC 4122, технически эквивалент ITU-T Rec. X.667 | ИСО / МЭК 9834-8.

Формат

123e4567-e89b-12d3-a456-426614174000 xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Четырехбитовые поля M и 1-3-битные поля N кодируют формат самого UUID.

Четыре бита цифры M - это версия UUID, а от 1 до 3 наиболее значимых битов цифрового N кода - вариант UUID. (См. Ниже. ) В этом примере M равно 1 , а N равно a (10xx 2 ), что означает, что это UUID версии 1, варианта 1; то есть основанный на времени UUID DCE / RFC 4122.

RFC 4122 Раздел 3 требует, чтобы символы создавались в нижнем регистре, при этом регистр не учитывался при вводе.

Идентификаторы GUID Microsoft иногда обозначаются фигурными скобками:

Этот формат не следует путать с « реестром Windows форматом», который относится к формату в фигурных скобках.

RFC 4122 определяет пространство имен Uniform Resource Name (URN) для UUID. UUID, представленный как URN, выглядит следующим образом:

Кодирование

Двоичное кодирование UUID зависит от системы. UUID варианта 1, в настоящее время наиболее распространенный вариант, закодированы в формате с прямым порядком байтов . Например, 00112233-4455-6677-8899-aabbccddeeff кодируется в байтах 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff .

UUID варианта 2, исторически использовавшиеся в библиотеках Microsoft COM / OLE , используют формат с прямым порядком байтов , при этом первые три компонента UUID являются прямым порядком байтов , а последние два - прямым порядком байтов . Например, 00112233-4455-6677-8899-aabbccddeeff кодируется в байтах 33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff .

Варианты

Поле «вариант» UUID или позиция N указывают их формат и кодировку. RFC 4122 определяет четыре варианта длины от 1 до 3 бит:

Варианты 1 и 2 используются текущей спецификацией UUID. В текстовом представлении варианты 1 и 2 одинаковы, за исключением битов варианта. В двоичном представлении существует разница в порядке байтов. Когда для преобразования между прямым порядком байтов варианта 1 и прямым порядком байтов варианта 2 требуется перестановка байтов, указанные выше поля определяют перестановку. Первые три поля представляют собой 32- и 16-разрядные целые числа без знака и подлежат замене местами, в то время как последние два поля состоят из неинтерпретируемых байтов и не подлежат замене местами. Этот обмен байтами применяется даже для версий 3, 4 и 5, где канонические поля не соответствуют содержимому UUID.

Хотя некоторые важные идентификаторы GUID, такие как идентификатор интерфейса IUnknown модели компонентных объектов , номинально являются UUID варианта 2, многие идентификаторы, генерируемые и используемые в программном обеспечении Microsoft Windows и называемые «идентификаторами GUID», являются стандартным вариантом 1 RFC 4122 / DCE 1.1. UUID сетевого порядка байтов, а не UUID варианта 2 с прямым порядком байтов. Текущая версия средства Microsoft создает стандартные UUID варианта 1. В некоторой документации Microsoft указано, что «GUID» является синонимом «UUID», как это стандартизовано в RFC 4122. В самом RFC 4122 говорится, что UUID «также известны как GUID». Все это говорит о том, что «GUID», изначально относящийся к варианту UUID, используемому Microsoft, стал просто альтернативным именем для UUID, при этом сохранились идентификаторы GUID варианта 1 и варианта 2. guidgen

Версии

Для обоих вариантов 1 и 2 в стандартах определены пять «версий», и каждая версия может быть более подходящей, чем другие, в конкретных случаях использования. Версия указывается M в строковом представлении.

UUID версии 1 генерируются из времени и идентификатора узла (обычно MAC-адреса ); UUID версии 2 генерируются из идентификатора (обычно идентификатора группы или пользователя), времени и идентификатора узла; версии 3 и 5 производят детерминированные UUID, генерируемые хешированием идентификатора и имени пространства имен ; и UUID версии 4 генерируются с использованием случайного или псевдослучайного числа.

Nil UUID

Нулевой UUID, особый случай, - это UUID 00000000-0000-0000-0000-000000000000 ; то есть все биты установлены в ноль.

Версия 1 (дата, время и MAC-адрес)

13- или 14-битная «уникальная» тактовая последовательность расширяет временную метку для обработки случаев, когда тактовая частота процессора не продвигается достаточно быстро или когда имеется несколько процессоров и генераторов UUID на узел. Когда UUID генерируются быстрее, чем могут продвигаться системные часы, младшие биты полей временной метки могут быть сгенерированы путем увеличения их каждый раз, когда создается UUID, для имитации временной метки с высоким разрешением. Поскольку каждый UUID версии 1 соответствует одной точке в пространстве (узлу) и времени (интервалы и последовательность часов), вероятность того, что два правильно сгенерированных UUID версии 1 будут непреднамеренно одинаковыми, практически равна нулю. Поскольку время и последовательность часов составляют 74 бита, 2 74 (1,8 × 10 22 , или 18 секстиллионов) UUID версии 1 могут быть сгенерированы для каждого идентификатора узла с максимальной средней скоростью 163 миллиарда в секунду для каждого идентификатора узла.

В отличие от других версий UUID, UUID версии 1 и -2, основанные на MAC-адресах сетевых карт, частично зависят от идентификатора, выданного центральным органом регистрации, а именно части идентификатора организационного уникального идентификатора (OUI) MAC-адреса. , который выдается IEEE производителям сетевого оборудования. Уникальность UUID версии 1 и версии 2 на основе MAC-адресов сетевых карт также зависит от того, правильно ли производители сетевых карт назначают уникальные MAC-адреса своим картам, что, как и другие производственные процессы, подвержено ошибкам. Кроме того, некоторые операционные системы позволяют конечному пользователю настраивать MAC-адрес, особенно OpenWRT .

Использование MAC-адреса сетевой карты узла для идентификатора узла означает, что UUID версии 1 можно отследить до компьютера, который его создал. Иногда документы можно отследить до компьютеров, на которых они были созданы или отредактированы, с помощью UUID, встроенных в них программным обеспечением для обработки текстов . Эта дыра в конфиденциальности была использована при обнаружении создателя вируса Melissa .

Версия 2 (дата, время и MAC-адрес, версия безопасности DCE)

RFC 4122 резервирует версию 2 для UUID "безопасности DCE"; но не содержит подробностей. По этой причине во многих реализациях UUID не используется версия 2. Однако спецификация UUID версии 2 обеспечивается спецификацией служб аутентификации и безопасности DCE 1.1.

UUID версии 2 аналогичны версии 1, за исключением того, что 8 младших битов тактовой последовательности заменяются номером "локального домена", а младшие 32 бита временной метки заменяются целочисленным идентификатором, имеющим значение в пределах указанного локальный домен. В системах POSIX номера локальных доменов 0 и 1 предназначены для идентификаторов пользователей ( UID ) и групп ( GID ) соответственно, а другие номера локальных доменов определяются сайтом. В системах, отличных от POSIX, все номера локальных доменов определяются сайтом.

Возможность включения 40-битного домена / идентификатора в UUID требует компромисса. С одной стороны, 40 бит позволяют использовать около 1 триллиона значений домена / идентификатора для каждого идентификатора узла. С другой стороны, когда значение часов усечено до 28 старших битов, по сравнению с 60 битами в версии 1, часы в UUID версии 2 будут «тикать» только один раз каждые 429,49 секунды, то есть чуть более 7 минут, поскольку в отличие от каждых 100 наносекунд для версии 1. И с тактовой последовательностью всего 6 бит, по сравнению с 14 битами в версии 1, только 64 уникальных UUID для каждого узла / домена / идентификатора могут быть сгенерированы за 7-минутный такт часов, по сравнению с 16 384 значения тактовой последовательности для версии 1. Таким образом, версия 2 может не подходить для случаев, когда требуются UUID для каждого узла / домена / идентификатора со скоростью, превышающей примерно один каждые семь минут.

Версии 3 и 5 (на основе имен пространств имен)

Версия-3 и версия-5 UUID , порождены хэширования в пространстве имен идентификатор и имя. Версия 3 использует MD5 в качестве алгоритма хеширования, а версия 5 использует SHA-1 .

Идентификатор пространства имен сам по себе является UUID. Спецификация предоставляет UUID для представления пространств имен для URL , полных доменных имен , идентификаторов объектов и отличительных имен X.500 ; но любой желаемый UUID может использоваться как указатель пространства имен.

Чтобы определить UUID версии 3, соответствующий заданному пространству имен и имени, UUID пространства имен преобразуется в строку байтов, объединяется с именем ввода, затем хешируется с помощью MD5, что дает 128 бит. Затем 6 или 7 бит заменяются фиксированными значениями, 4-битной версией (например, 0011 2 для версии 3) и 2- или 3-битным «вариантом» UUID (например, 10 2 указывает на RFC 4122 UUID или 110 2 с указанием устаревшего идентификатора GUID Microsoft). Поскольку таким образом заранее определены 6 или 7 бит, только 121 или 122 бита вносят вклад в уникальность UUID.

UUID версии 5 аналогичны, но вместо MD5 используется SHA-1. Поскольку SHA-1 генерирует 160-битные дайджесты, дайджест обрезается до 128 бит перед заменой битов версии и варианта.

UUID версии 3 и версии 5 обладают тем свойством, что одно и то же пространство имен и имя будут сопоставляться с одним и тем же UUID. Однако ни пространство имен, ни имя не могут быть определены из UUID, даже если один из них указан, за исключением поиска методом перебора. RFC 4122 рекомендует версию 5 (SHA-1) вместо версии 3 (MD5) и предостерегает от использования UUID любой версии в качестве учетных данных безопасности.

Версия 4 (случайная)

UUID версии 4 генерируется случайным образом. Как и в других UUID, 4 бита используются для обозначения версии 4 и 2 или 3 бита для обозначения варианта (10 2 или 110 2 для вариантов 1 и 2 соответственно). Таким образом, для варианта 1 (то есть для большинства UUID) случайный UUID версии 4 будет иметь 6 предварительно определенных битов варианта и версии, оставляя 122 бита для случайно сгенерированной части, всего 2122 , или 5,3 × 10 36 (5,3 undecillion ) возможные UUID версии 4 варианта 1. Существует вдвое меньше возможных UUID версии 4 варианта 2 (унаследованных идентификаторов GUID), потому что доступно на один случайный бит меньше, а для варианта используется 3 бита.

Столкновения

Конфликт возникает, когда один и тот же UUID генерируется более одного раза и назначается разным референтам. В случае стандартных UUID версии 1 и версии 2, использующих уникальные MAC-адреса от сетевых карт, коллизии маловероятны, с повышенной вероятностью только тогда, когда реализация отличается от стандартов, случайно или намеренно.

В отличие от UUID версии 1 и версии 2, сгенерированных с использованием MAC-адресов, с UUID версии 1 и -2, которые используют случайно сгенерированные идентификаторы узлов, UUID версии 3 и версии 5 на основе хэша и случайные UUID версии 4, коллизии могут происходить даже без проблем с реализацией, хотя и с такой малой вероятностью, что ее обычно можно игнорировать. Эта вероятность может быть точно вычислена на основе анализа проблемы дня рождения .

Например, количество случайных UUID версии 4, которые необходимо сгенерировать, чтобы иметь 50% -ную вероятность хотя бы одного столкновения, составляет 2,71 квинтиллион, вычисляемый следующим образом:

Это число эквивалентно генерации 1 миллиарда UUID в секунду в течение примерно 85 лет. Файл, содержащий такое количество UUID, по 16 байт на UUID, будет около 45 эксабайт .

Наименьшее количество UUID версии 4, которое должно быть сгенерировано, чтобы вероятность обнаружения коллизии была p , аппроксимируется формулой

Таким образом, вероятность найти дубликат в 103 триллионах UUID версии 4 составляет один на миллиард.

Использует

Значительное использование включает инструменты пользовательского пространства файловой системы ext2 / ext3 / ext4 ( e2fsprogs использует libuuid, предоставляемый util-linux ), LVM , зашифрованные разделы LUKS , GNOME , KDE и macOS , большинство из которых являются производными от исходной реализации Теодора Ц'о .

Одно из применений UUID в Solaris (с использованием реализации Open Software Foundation) - это идентификация работающего экземпляра операционной системы с целью объединения данных аварийного дампа с событием управления сбоями в случае паники ядра.

Обычно используется в протоколах Bluetooth для определения служб и общего профиля Bluetooth.

В COM

Существует несколько разновидностей идентификаторов GUID, используемых в объектной модели компонентов (COM) Microsoft :

Как ключи базы данных

Случайный характер стандартных UUID версий 3, 4 и 5 и порядок полей в стандартных версиях 1 и 2 могут создавать проблемы с локализацией или производительностью базы данных, когда UUID используются в качестве первичных ключей . Например, в 2002 году Джимми Нильссон сообщил о значительном улучшении производительности Microsoft SQL Server, когда UUID версии 4, используемые в качестве ключей, были изменены для включения неслучайного суффикса, основанного на системном времени. Этот так называемый подход «COMB» (комбинированный идентификатор времени-GUID) сделал UUID нестандартными и значительно более вероятным для дублирования, как признал Нильссон, но Нильссон требовал только уникальности в приложении. Путем переупорядочивания и кодирования UUID версий 1 и 2 так, чтобы метка времени была первой, можно предотвратить потерю производительности при вставке.

Некоторые веб-фреймворки, такие как Laravel, поддерживают UUID «сначала временная метка», которые могут эффективно храниться в индексируемом столбце базы данных. Это делает COMB UUID с использованием формата версии 4, но где первые 48 бит составляют метку времени, выложенную, как в UUIDv1. Более определенные форматы, основанные на идее COMB UUID, включают:

Читайте также: