Что такое глобально-уникальный идентификатор — GUID ?
Глобально-уникальный идентификатор (GUID) — это уникальный номер, используемый в качестве идентификатора в программном обеспечении. Идентификаторы GUID используются в различных приложениях, например в Microsoft Windows, для идентификации интерфейсов, ссылок и других данных.
Идентификаторы GUID обычно представляют собой 128-битные целые числа, которые генерируются случайным образом, гарантируя, что они уникальны на всех устройствах и в любое время.
Идентификаторы часто представляются в виде 32 шестнадцатеричных цифр, отображаемых в пяти группах, разделенных дефисами. Например: 12345678-11234-11234-11234-myrusakov89012.
GUID-идентификаторы используются в различных приложениях, поскольку они обеспечивают удобный и надежный способ уникальной идентификации объектов, таких как, например, покупатели, продукты или транзакции. Они часто используются в качестве первичных ключей в базах данных.
Вероятность того, что два GUID-идентификатора будут одинаковыми, чрезвычайно мала, так как существует 2 ^ 128 (3,4 x 10 ^ 38) возможных GUID-идентификаторов.
Чтобы представить насколько это много, скажем, что в наблюдаемой вселенной насчитывается примерно 10 ^ 80 атомов. Это означает, что вероятность совпадения двух идентификаторов примерно эквивалентна вероятности нахождения двух конкретных атомов из всех атомов во вселенной.
На практике крайне маловероятно (но не исключено совсем), что два GUID-идентификатора когда-либо будут одинаковыми, даже если миллиарды идентификаторов генерируются каждую секунду. Это делает GUID отличным выбором для использования в качестве уникальных идентификаторов.
Есть несколько причин, по которым обычно стоит использовать глобально-уникальный идентификатор (GUID) или что-то подобное в качестве идентификатора клиента, а не простое увеличивающееся целое число:
Уникальность: Идентификатор GUID гарантированно будет уникальным на всех устройствах и в любое время, поэтому вы можете быть уверены, что ни у одного из двух клиентов не будет одинакового идентификатора. С помощью простого увеличивающегося целого числа двум клиентам может быть присвоен один и тот же идентификатор, если процесс генерации идентификатора не управляется должным образом.
Постоянство: GUID идентификатор не подвержен дублированию или повторному использованию, даже если база данных восстановлена из резервной копии. При использовании увеличивающегося целого числа идентификаторы могут не совпадать между резервными копиями, что может привести к путанице.
Безопасность: GUID Идентификатор сложнее угадать перебором, чем простое увеличивающееся целое число, поэтому он может обеспечить дополнительный уровень безопасности информации о клиенте.
Интеграция: GUID-идентификатор может быть легко интегрирован с другими системами, которые могут генерировать свои собственные уникальные идентификаторы, поскольку маловероятно, что идентификаторы будут конфликтовать.
В целом, использование GUID-идентификатора или аналогичного значения в качестве идентификатора клиента может обеспечить множество преимуществ с точки зрения уникальности, постоянства, безопасности и интеграции.
В PHP один из возможных примеров генерации GUID может быть представлен следующим образом:
function generateId()
<
return sprintf(
'%04X%04X-%04X-%04X-%04X-%04X%04X%04X',
mt_rand(0, 65535),
mt_rand(0, 65535),
mt_rand(0, 65535),
mt_rand(16384, 20479),
mt_rand(32768, 49151),
mt_rand(0, 65535),
mt_rand(0, 65535),
mt_rand(0, 65535)
);
>
Чтобы использовать эту функцию, вы можете просто вызвать ее следующим образом:
Это позволит присвоить новый идентификатор переменной $gid. Затем этот идентификатор можно использовать в качестве идентификатора клиента или для любых других целей.
Таким образом глобально-уникальный идентификатор (GUID) — это хороший способ создать уникальный ключ для некоторой сущности, однако имейте ввиду, что так как guid — это в общем-то строки, которые занимают больше место чем просто числа. Поэтому стоит этот вид идентификатор использовать там, где преимуществ от его использования превосходят его недостатки.
Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!
Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.
Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления
Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.
Порекомендуйте эту статью друзьям:
Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):
Она выглядит вот так:
Комментарии ( 0 ):
Для добавления комментариев надо войти в систему.
Если Вы ещё не зарегистрированы на сайте, то сначала зарегистрируйтесь.
Эффективная генерация сортируемых GUID для первичных ключей БД на клиенте
Использовать Guid.NewGuid() в качестве первичного ключа в базе данных — плохая с точки зрения производительности идея. Это связано с тем, что в SQL Server, MySQL и некоторых других БД для первичных ключей создаются кластерные индексы, которые определяют, как строки будут храниться на диске. GUID — это по сути случайное значение, поэтому новая строка может попасть в начало, середину или конец таблицы. Серверу БД в этом случае придётся перемещать другие строки, что приведёт к фрагментации данных, а их извлечение может занять больше времени, если вам нужно извлечь несколько добавленных последовательно записей (например, когда вы добавляете набор связанных сущностей, которые потом будут извлекаться вместе — БД понадобится прочитать данные из разрозненных страниц вместо последовательного чтения набора данных).
Поэтому, чаще всего, лучше пользоваться сгенерированными БД первичными ключами. В SQL Server, например, есть функция NEWSEQUENTIALID() , которая генерирует последовательные GUIDы. Зачем может понадобиться генерировать ключи именно на клиенте и как это правильно сделать?
Проблема
Для создания первичных ключей сущности большинство людей прибегают к одному из следующих подходов:
Использование в качестве первичного ключа int и генерация таких ключей базой данных при вставке новой строки.
Использование GUID и опции генерации на уровне БД.
Самостоятельная генерация GUID в своём приложении и вставка строки с этим идентификатором.
Чтобы дать немного контекста и выяснить, почему вам могут понадобиться последовательные GUID, рассмотрим плюсы и минусы каждого из вышеперечисленных подходов к созданию первичных ключей.
Генерируемый БД Integer в качестве идентификатора
Первый вариант, позволяющий базе данных автоматически генерировать целочисленный первичный ключ, является очень заманчивым подходом; долгое время, особенно в монолитных системах, это было подходом по умолчанию, который удобно интегрировался с ORM. Одна из его приятных особенностей — первичные ключи получают красивые, монотонно возрастающие (и обычно последовательные) идентификаторы.
Это упрощает работу с тестовыми данными и поддержку, когда идентификаторы используюстя в URL-адресах: можно запомнить ID нужной сущности, быстро получить её в коде или по адресу, вбив нужный идентификатор:
Какие недостатки у таких ключей?
Во-первых, подход с генерацией ключей в базе данных затрудняет или делает невозможным использование некоторых паттернов проектирования. Например, общий подход к идемпотентности заключается в создании идентификатора на клиенте и отправке его в запросе. Это позволяет легко устранять дублирование и гарантирует, что вы не вставите один и тот же объект дважды, так как легко обнаружить повторяющиеся запросы на вставку. Такой подход обычно невозможен с идентификаторами, сгенерированными базой данных.
Во-вторых, это усложняет код INSERT, поскольку вы должны убедиться, что возвращаете сгенерированные идентификаторы. EntityFramework под капотом назначает ID сущностям после вставки, но в случае с Dapper вам придётся делать это самим.
Третья проблема возникает только в высоконагруженных приложениях — при вставке большого количества строк БД должна блокировать генератор идентификаторов чтобы избежать использования одного ID несколькими сущностями, это может стать узким местом в приложении. Если БД масштабируется и используется master-master репликация, то всё становится ещё сложнее — в разных БД существуют разные настройки, которые могут генерировать записи с пропусками (например, первый сервер будет генерировать только нечетные идентификаторы, а второй только четные) или генерировать идентификаторы из разных подмножеств.
Резимуруя этот подход:
Читаемые и запоминаемые URL.
Проблемы с идемпотентностью.
В некоторых случаях нужно дополнительно озаботиться возвращением идентификаторов при вставке.
Снижение производительности в высококонкурентной среде.
Генерируемый БД GUID в качестве идентификатора
При использовании сгенерированных БД гуидов мы можем избавиться от части проблем — например, NEWSEQUENTIALID() использует для генерации значений данные оборудования (MAC-адрес сетевой карты и «идентификатор часов»), поэтому сгенерированный с помощью неё иденитфикатор остается глобально уникальным. Это избавляет от необходимости дополнительной настройки генерации последовательности иденификаторов при репликации.
Функция генерирует корректно сортируемые последовательности, так что данные будут вставляться последовательно, а при слиянии данных с нескольких реплик эти данные так же будут локально последовательными.
В MySQL функция UUID() генерирует UUID версии 1, что делает их так же частично сортируемыми.
Стоит сразу заметить, что в PostgreSQL данные хранятся иначе, поэтому использование непоследовательных GUID не влияет катастрофически на производительность базы данных.
В случае генерируемых БД идентификаторов мы всё ещё вынуждены мириться с сложностью реализации идемпотентности в запросах и необходимостью заботиться о возвращении идентификаторов при вставке. Также тот факт, что гуиды являются 128-битными значениями по сравнению с 32-битными целыми числами, приводит к увеличению общего размера данных.
Генерируемый клиентом GUID в качестве идентификатора
Решение проблем генеририуемых БД первичных ключей заключается в использовании созданных клиентом идентификаторов. У этого подхода тоже есть различные плюсы и минусы!
Одним из преимуществ является то, что это просто. Все современные языки имеют доступные генераторы GUID; в .NET это метод Guid.NewGuid() , который возвращает случайный 128-битный идентификатор.
Вы можете установить это значение в качестве ID для добавляемой сущности, и вам не нужно беспокоиться о проверке, с каким идентификатором она была добавлена в БД. Используете ли вы EF Core или Dapper, Postgres или SqlServer, код будет одинаковым. Данные при запросе на вставку перемещаются только в одном направлении, от клиента к базе данных, а не в двух направлениях, как в случае с генерируемым БД первичным ключом.
Если вы создаете идентификаторы в своем клиентском коде, у вас теперь есть доступ к различным шаблонам идемпотентности. Например, представьте, что вы включаете GUID в запрос, но запрос завершается сбоем из-за ошибки сервера. Вы можете просто отправить тот же запрос еще раз, зная, что сервер сможет идентифицировать его как «дубликат», поэтому ему нужно только повторить часть действия, которое привело к ошибке или просто вернуть ответ об успешном создании сущности. Таким образом, вы можете избежать создания дубликатов.
Уникальность гуидов — это и их сильные стороны, и их слабость. С точки зрения разработчика и пользователя, с /book/55DE358F-45F1-E311-93EA-00269E58F20D работать не так просто, как с /book/1 .
Тип Guid в .NET реализует UUID версии 4, то есть генерируемый полностью случайным образом идентификатор. С точки зрения базы данных эта случайность может вызвать большие проблемы. Случайность идентификаторов может привести к серьезной фрагментации индекса, что увеличивает размер вашей базы данных и влияет на общую производительность.
Если подводить итог для опции генерируемого на клиенте GUID, то получится следующее:
Легко использовать и код остаётся универсальным при переходе между разными БД.
Позволяет сделать запросы идемпотентными без дополнительного уровня абстракции.
Нет необходимости читать значения из БД после вставки.
Больший объем данных по сравнению с целочисленными идентификаторами.
Могут вызвать проблемы с производительностью БД из-за фрегментации индекса.
Преимущества сортируемого GUID
У гуидов есть несколько преимуществ, и, кроме проблем с человекочитаемостью, один большой недостаток с фрагментацией индекса, вызванной их полной случайностью. А нам всего-то и нужен сортируемый последовательно-возрастающий глобально-уникальный идентификатор чтобы использовать его в качестве ключа. Где его взять?
Самый простой ответ — нам нужен тот самый UUID версии 1, который используется функциями БД для генерации идентификаторов. Но есть несколько проблем. В BCL нет полной реализации RFC 4211, и, судя по комментариям в github дотнета, такую поддержку прямо сейчас добавлять не планируется. Если поискать по nuget-пакетам, то какого-то одного стандарта де-факто, который бы активно использовался и поддерживался сообществом тоже нет. Я нашёл библиотеку Vlingo.Xoom.UUID, которая завляет поддержку RFC 4211. Ещё один способ из хабростатьи про GUID в качестве первичных ключей предлагает использовать DllImport к библиотеке, которая используется SQL Server для генерации идентификаторов — такой способ вызовет очевидную проблему с переносимостью.
Но у UUID версии 1 на мой взгляд есть недостатки на уровне самого стандарта. Во-первых, для метки времени используется количество 100-наносекундных интервалов, прошедших с 15 октября 1582 года. Это совсем не то, как мы привыкли думать о timestamp в нашем повседневном программировнии. Во-вторых, в случае с UUID версии 1 метка времени внутри идентификатора частично перевернута, то есть старшие биты таймстампа сдвинуты к младшим битам в самом UUID. Это объясняет тот факт, что в примере с NEWSEQUENTIALID() менялись именно старшие разряды идентификатора. Такой порядок делает лексикографическое упорядочивание немного бессмысленным.
Мы могли бы просто переставить биты внутри UUID и вернуть время и упорядоченность к изначальному виду от старших бит к младшим, но это дополнительное усложение, которое всё ещё предполагает использовать непривычный timestamp совсеместно с дополнительной логикой защиты от коллизий (в случае, если в 100нс интервал генерируется несколько идентификаторов). Хочется чего-то более нативного.
Отличные новости — для решения этой задачи 31 марта 2022 года на сайте IETF был официально размещен текст рабочего документа с новыми форматами UUID, специально предназначенными для использования в высоконагруженных приложениях и базах данных — возрастающие по времени, создержащие timestamp, счетчик с инициализацией его сегментов нулем и псевдослучайным значением, а также собственно псевдослучайное значение. Стандарт ещё не принят, но уже сейчас можно найти первые реализации библиотек для UUID версии 7.
Ещё одна хорошая новость — есть библиотека NewId, которая позволяет генерировать лексикографически упорядоченные по времени создания идентификаторы и тоже создана как раз для первичных идентификаторов. Сама библиотека основана на Snowflake_ID, который разработан специально для использования в распределенных системах, и Flake, который развивает идеи UUID версии 1. Самый простой способ понять, что это значит, — показать, как выглядят идентификаторы, сгенерированные NewId.
Пример результата работы программы:
NewId использует в качестве данных для создания идентификатора 3 источника:
Worker/process ID, который отвечает за уникальность между процессами/сервером — именно он отвечает за общую для всех идентификаторов часть, а идентификатор конкретного процесса можно включить дополнительно для избежания коллизий между процессами в рамках одной машины.
Timestamp, который обеспечивает сортируемость идентификатора.
Последовательно возрастающий идентификатор.
Объединив 3 части вместе, вы можете получить идентификатор, который будет частично отсортированным благодаря компоненту метки времени. Включив идентификатор процесса, можно избежать коллизий при генерации идентификаторов несколькими процессами. А использование части с последовательно возрастающим идентификатором позволяет генерировать 2^16-1 идентификаторов в миллисекунду в рамках одного процесса:
Иллюстрация «Flake» ID из поста об этом идентификаторе. NewId основан на том же подходе.
На сколько же NewId снижает фрагментацию индекса?
Сравнение фрагментации индекса при использовании разных генераторов UUID
В сравнительном эксперементе я решил сравнить степень фрагментации и плотность данных от несколько генераторов UUID в качестве первичных ключей:
[DllImport(«rpcrt4.dll», SetLastError = true)]
Vlingo.UUID.TimeBasedGenerator.GenerateGuid c опцией GuidGenerationMode.WithUniquenessGuarantee
В тесте для простой таблицы с идентификатором и текстовым полем будет добавляться 10 тысяч записей, каждая с случайной задержкой 100-500 миллисекунд, таким образом в идентификаторе будут участвовать таймштампы за 50 минут одного дня.
NewId, по-видимому, в значительной степени ориентирован на сервер SQL Server. Поэтому, и потому, что для MySQL я не нашёл понятного способа измерить фрагментацию данных и эффективность использования дискового пространства, тесты проводились именно на SQL Server.
Развернем Docker-образ SQL Server:
Создадим 5 простых таблиц для разных типов сгенерированных идентификаторов:
Создадим в таблицах тестовые данные при помощи старого-доброго ADO.NET:
Чтобы посмотреть размер каждого индекса и его фрагментацию, используем стащенный из этой статьи запрос:
Полученные данные легко объяснить из информации, которую мы уже знаем. Во-первых, сгенерированные случайно идентификаторы приводят к большой фрагментации данных поскольку новые элементы вставляются на случайную позицию. NewId вызвали только 5-процентную фрагментацию, а Vlingo.UUID всего 3-процентную фрагментацию. Ещё при использовании Guid остается больше пустого места на каждый странице с данными (возможно, из-за постоянных перемещений данных во время вставки), поэтому вам нужно больше страниц для хранения того же объема данных (81 против 59). Это тоже станет источником некоторого снижения производительности при использовании гуидов. Что касается UUID версии 7, то остается только думать, что способ, которым SQL Server сортирует ключи не совсем совместим с новым форматом.
Но на самом деле влияние фрагментации при чтении данных совсем не так велико, как может представляться — скорее можно назвать его незначительным. Вот пример замера производительности при чтении 10.000 записей и 100.000 записей в запросе:
Настоящая проблема c производительностью гуидов начинается в больших таблицах при вставке данных — потому что индекс перестраивается случайным образом, а сервер БД не может сделать предсказания для следующего набора данных. Один из бенчмарков сравнивает производительность добавления 5 миллионов записей батч-запросами по 100.000 записей каждая в таблицу c автоинкрементным целым ключом, UUID версии 1, 4 или подхаченной «последовательной» версии 4 после манипуляции с битами. По результатам видно, что после полутора миллионов записей UUID версии 4 начинает деградировать, а время вставки быстро растет:
В другом бенчмарке сравнивается добавление записей в БД, где ключи генерируются разными функциями SQL: uuid_generate_v4() , uuid_time_nextval() и uuid_sequence_nextval() с разным набором параметров. Тесты проводятся в трёх условиях: на изначально пустой таблице, помещающейся в оперативную память таблице и явно не влезающей в оперативную память таблице. С ростом объёма данных тоже видно значительное снижение скорости добавления новых данных:
Выводы
Библиотеки NewId и Vlingo.UUID явно делают свою работу. Первая создана и развивается специально для решения проблемы с первичными ключами в базах данных, где данные строк хранятся в кластерных индексах. Вторая — утилитарный пакет платформы XOOM компании Vlingo и не имеет даже публичной документации.
Стоит ли его использовать? Ответ, как обычно — «зависит». Но это точно хорошая альтернатива, если вам нужно генерировать первичные ключи на клиенте и работать с MySQL или MS SQL Server.
Name already in use
Идентификация (англ. identification , лат. identifico — отождествлять) — процедура распознавания объекта (субъекта) по его идентификатору.
Например, можно идентифирировать человека по имени, электронной почте, номеру телефона или паспорта.
Аутентификация (англ. authentication , греч. αυθεντικός — подлинный) — процедура проверки подлинности.
Например, можно определить подлинность проверкой пароля, отпечатка пальца, наличием пропуска или ключа от двери.
Авторизация (англ. authorization — разрешение, уполномочивание) – предоставление доступа к какому-либо ресурсу.
Стандартная последовательность действий на любом сайте.
- Установление личности (username, email, phone) – идентификация.
- Проверка подлинности (password) – аутентификация.
- Предоставление доступа – авторизация.
Объект и субъект
Объект (лат. objectum — предмет) — философская категория, обозначающая вещь, явление или процесс, на которые направлена предметно-практическая, управляющая и познавательная деятельность субъекта (наблюдателя); при этом в качестве объекта может выступать и сам субъект.
Разновидности идентификаторов. ID , UID , UUID и GUID
Идентификатор (англ. identifier , ID ) — уникальный признак объекта (субъекта), позволяющий отличать его от других объектов (идентифицировать).
Поле ID обычно является главным ключом (англ. primary key ), по которому можно найти конкретный объект в коллекции объектов.
Поле ID чаще всего представлено в виде некоторого хэша, сгенерированного в заданном формате по некоторому алгоритму. Существует множество форматов ID, при этом для генерации могут использовать индексы (последовательное инкрементирование — самый простой случай), даты (англ. timestamps ), рандомные числа, другие поля объекта, которые тоже по некоторому алгоритму становятся хэшем. Далее рассмотрим некоторые варианты ID .
UUID (англ. Universally Uique IDentifier ) — стандарт идентификации, стандартизированный Open Software Foundation как часть среды распределённых вычислений (DCE).
UUID позволяет уникально идентифицировать информацию, не имея при этом центра координации.
То есть любой может создать UUID и использовать его для идентификации чего-либо с достаточным уровнем уверенности, что этот идентификатор не будет использован для чего-либо ещё непреднамеренно.
UUID имеет несколько версий, в которых используются:
- Версии 1 и 2 — время и MAC-адрес.
- Версия 3 — хеширование алгоритмом MD5.
- Версия 4 — генерация случайным образом.
- Версия 5 — хеширование алгоритмом SHA-1.
Библиотека в npm , позволяющая создавать и проверять валидность UUID :
Для проверки подлинности (аутентификации) пользователя обычно на сервер вместе с запросом передаётся заголовок Authorization , в котором размещают тип аутентификации и соответствующие ей данные.
Базовая (Basic) аутентификация подразумевает передачу в заголовок имени пользователя и пароля в виде строки следующего вида username:password , зашифрованной в Base64.
В JavaScript можно кодировать и декорировать Base64 следующим образом.
Сессии ( Sessions ) и Cookie
Когда Cookie устаревают, они удаляются и на клиенте, и на сервере, поэтому описанный выше алгоритм повторяется.
JSON Web Token (JWT)
Токены доступа (Access Tokens) представляют собой учётные данные (credentials), которые используеются для доступа к защищенным ресурсам.
Токен доступа отправляется на сервер с каждым запросом в Authorization заголовке запроса.
Токены доступа можно использовать неограниченное количество раз, но они обычно имеют короткую продолжительность жизни (обычно устанавливают
15 минут), чтобы их нельзя было украсть и постоянно использовать.
Таким образом, если токен доступа украдут, то им можно будет пользоваться не более указанного в нём времени (например, не более 15 минут).
Время истечения токена может быть определено по полям exp (expiration time), определяющим время жизни токена и iat (issued at), определяющим дату создания токена. Подделать это время нельзя, поскольку формула формирования токена нарушится и он станет невалидным.
Токены доступа не хранятся на сервере, на клиенте чаще всего хранятся в Local Storage (и берутся оттуда, чтобы их можно было отправить в заголовке запроса).
Когда токен доступа истекает и требуется новый для доступа к ресурсу, клиенту необходимо обратиться к серверу аутентификации (Auth Server) для получения нового токена.
Токен обновления (Refresh Token) содержит информацию, необходимую для получения нового токена доступа.
Серверу аутентификации отсылается токен обновления и возвращается токен доступа.
Токены обновления одноразовые и обычно имеют долгую продолжительность жизни.
Если токен обновления украден, его можно использовать только один раз, а значит получить только один токен доступа.
Если клиент видит, что его токен доступа невалиден (им уже воспользовались), он может перелогиниться. Таким образом сгенерируется новый токен обновления, а старый станет невалидным.
Токены обновления не хранят в себе какую-то информацию, как JWT-токены, и обычно представляют обычную хеш-строку. Токены обновления необходимо хранить на сервере.
В отличие от токенов доступа токены обновления хранятся на сервере. Они также хранятся и на клиенте.
Id guid что это
GUID (Globally Unique Identifier) — статистически уникальный 128-битный идентификатор. Его главная особенность — уникальность, которая позволяет создавать расширяемые сервисы и приложения без опасения конфликтов, вызванных совпадением идентификаторов. Хотя уникальность каждого отдельного GUID не гарантируется, общее количество уникальных ключей настолько велико (2 128 или 3,4028×10 38 ), что вероятность того, что в мире будут независимо сгенерированы два совпадающих ключа, крайне мала. Тем не менее, случаи совпадения были: на системе Windows 95 GUID’ы ярлыка запуска DOS-программ (.pif) и программы ZipMagic 2000 совпадали.
«GUID» называют некоторые реализации стандарта, имеющего название Universally Unique Identifier (UUID).
В тексте GUID записывается в виде строки из тридцати двух шестнадцатеричных цифр, разбитых на группы дефисами, и окружённой фигурными скобками:
Содержание
Реализация Microsoft
Например, ‘22345200-abe8-4f60-90c8-0d43c5f6c0f6’ [1] соответствует шестнадцатеричному 128-битному числу 0x00523422E8AB604F90C80D43C5F6C0F6
Максимальное значение в GUID соответствует десятичному числу 340 282 366 920 938 463 463 374 607 431 768 211 455.
Microsoft применяет GUID в OLE, COM и DCOM — например, в качестве идентификаторов для классов (CLSID), интерфейсов (IID), библиотек типов (LIBID). Использование GUID гарантирует, что две (возможно, несовместимые) версии одного компонента могут иметь одно и то же имя, но быть отличимыми по GUID.
Алгоритм, который Microsoft использовала для генерации GUID, был широко раскритикован. В частности, в качестве основы для генерации части цифр GUID использовался MAC-адрес сетевого адаптера, что означало, например, что по данному документу MS Word (также получающему при создании свой уникальный GUID) можно было определить компьютер, на котором он был создан. Позже Microsoft изменила алгоритм таким образом, чтобы он не включал в себя MAC-адрес.
Другие реализации
Примечания
- ↑ 12 Последнее 8-байтное данное при записи часто разбивается на 2+6 (подробнее см. в английской версии статьи)
Ссылки
- Идентификаторы
Wikimedia Foundation . 2010 .
Полезное
Смотреть что такое «GUID» в других словарях:
guid — guid; guid·able; guid·ance; guid·er; guid·man; guid·sire; guid·wife; guid·willie; lan·guid·ly; lan·guid·ness; mis·guid·ance; pin·guid; pin·guid·i·ty; lan·guid; mis·guid·ed·ly; mis·guid·ed·ness; mis·guid·er; … English syllables
GUID — [Abk. für Global Unique Identifier], globale Identifikation … Universal-Lexikon
guid|er — «GY duhr», noun. 1. a person or thing that guides; guide; leader. 2. Guider, an adult leader associated with the Girl Guides … Useful english dictionary
GUID — Globally Unique Identifier Un GUID (abréviation de l anglais Globally Unique IDentifier) sert habituellement d identifiant unique pour un composant logiciel, par exemple un plugin. Sa taille est de 16 octets, soit 128 bits, décomposés en… … Wikipédia en Français
GUID — Ein Globally Unique Identifier (GUID) ist eine global eindeutige Zahl mit 128 Bit (das sind 16 Bytes), die in verteilten Computersystemen zum Einsatz kommt. GUID stellt eine Implementierung des Universally Unique Identifier Standards (UUID) dar.… … Deutsch Wikipedia
Guid — Ein Globally Unique Identifier (GUID) ist eine global eindeutige Zahl mit 128 Bit (das sind 16 Bytes), die in verteilten Computersystemen zum Einsatz kommt. GUID stellt eine Implementierung des Universally Unique Identifier Standards (UUID) dar.… … Deutsch Wikipedia
guid — ˈgœ̅d, ˈgu̅e̅d, ˈgid Scotland variant of good * * * guid «good», adjective, noun, interjection, adverb. Scottish. good. * * * guid Sc. form of good … Useful english dictionary
GUID — ● ►en sg. m. ►INTERNET Globally Unique IDentifier. À ce que j ai compris, c est un bidule inventé par Microsoft. Selon eux, différents types d objets ont différents types de GUID . Ça veut dire quoi, globally ? En pratique, cela sert à identifier … Dictionnaire d’informatique francophone
GUID Partition Table — (GPT), zu deutsch GUID Partitionstabelle, ist ein Standard für das Format von Partitionstabellen auf Festplatten oder anderen Datenträgern. Die Spezifikation ist Teil des UEFI Standards, der das BIOS in PCs ersetzen soll. GPT ist dabei der… … Deutsch Wikipedia
guid|ed-mis|sile — guid|ed missile «GY dihd», a missile that can be guided in flight to its target by means of radio signals from the ground or by automatic devices inside the missile which direct its course. Correction or alteration of the course of a missile in… … Useful english dictionary