Откуда берутся пространства имен UUID? - PullRequest
41 голосов
/ 11 октября 2011

Спецификация UUID определяет 4 предопределенных пространства имен, которые он описывает как «потенциально интересные», что означает, среди прочего, «если другие люди сгенерировали UUID в этом пространстве имен, вы можете проверить их»:

  • 6ba7b810-9dad-11d1-80b4-00c04fd430c8 для DNS
  • 6ba7b811-9dad-11d1-80b4-00c04fd430c8 для URL
  • 6ba7b812-9dad-11d1-80b4-00c04fd430c8 для ISO OID
  • 6ba7b814-9dad-11d1-80b4-00c04fd430c8 для X.500 DN

Откуда они взялись?

В частности,

  • Если я генерирую свой UUID пространства имен, нужно ли мне что-то избегать?
  • Я знаю, насколько велико пространство UUID, но имеет ли это какое-либо значение для коллизий?
  • Почему они выбрали четвертый октет для увеличения как своего рода UUID 'номер версии'?
  • Подразумевают ли мои вопросы, что я упускаю что-то фундаментальное в UUID?

Ответы [ 2 ]

42 голосов
/ 19 октября 2011

Во-первых, для ясности, все это обсуждение ограничено UUID версий 3 и 5. По моему (неподтвержденному) опыту, чаще всего используются UUID версии 4 (случайные).

Алгоритм генерации UUID

4122 в пространстве имен начинается неоднозначно:

Выделите UUID для использования в качестве «идентификатора пространства имен»

Нет другого упоминания о распределении "идентификатора пространства имен", и ни я, ни python не обнаружили ни одного стандартизированного пространства, кроме четырех, перечисленных в RFC 4122.

Итак, ответ на ваш первый вопрос,

  • Если я генерирую свое собственное UUID пространства имен, нужно ли мне что-то избегать?

Вам нужно всего лишь избегать четырех стандартных пространств имен.


Следующий вопрос,

  • Я знаю, насколько велико пространство UUID, но имеет ли это какое-либо влияние на коллизии?

Имеет две части:

  1. Будут ли конфликтовать UUID в вашем пространстве имен? Дословно от 4122:

    UUID, сгенерированные из двух разных имен в [вашем] пространстве имен, должны отличаться (с очень высокой вероятностью).

  2. Будет ли UUID вашего пространства имен конфликтовать с другими пространствами имен? Я не смог найти прямой ответ, так как не существует стандарта для распределения идентификаторов пространства имен, но аргумент в разделе 4.1.1 кажется уместным:

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


  • Почему они выбрали четвертый октет для увеличения как своего рода UUID 'номер версии'?

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

Обратите внимание, что восьмой октет (0-index) начинается с 8 во всех случаях, поэтому мы имеем дело с RFC 4122 варианта UUID. Уф.

Теперь проверьте октет 6 для версии: 1, мы имеем дело с версия 1 на основе времени UUID.

Этот ответ имеет удобный алгоритм для извлечения даты Python из UUID версии 1. Применение алгоритма дает время в 4 февраля 1998 . Я еще не нашел смысла в этой дате. Увеличение третьего октета добавляет наименьший кодируемый интервал времени (100 нс) к дате.


  • Подразумевают ли мои вопросы, что я упускаю что-то фундаментальное в UUID?

Неа. Пространства имен UUID обсуждаются очень мало, поскольку случайные UUID очень просты.

2 голосов
/ 10 августа 2015

Если я генерирую свой UUID пространства имен, нужно ли мне что-то избегать?

Нет.Ваш UUID пространства имен может быть любым UUID, сгенерированным любым из обычных способов.Так, например, вы, вероятно, захотите сгенерировать UUID версии 1 или версии 4 для использования в качестве UUID пространства имен.Это можно сделать с помощью программы uuidgen в Linux или OS X. Или вы можете легко сгенерировать версию 1 или версию 4 UUID онлайн.

...