Работа с GUID на Ассемблере

GUID (Глобальный уникальный идентификатор) - это 128-битное значение, представленное в виде 32 шестнадцатеричных символов, разделенных дефисами на пять блоков. Формат стандартизирован для обеспечения читаемости, компактности и кроссплатформенной совместимости. Структура классического формата: 8-4-4-4-12 символов. Каждый блок содержит цифры и буквы латинского алфавита от A до F. Такая организация позволяет генерировать практически уникальные идентификаторы, что делает GUID надежным ключом для объектов и данных в различных областях программирования.

Причины выбора формата заключаются в том, что представление GUID с дефисами было принято в рамках технологий OLE/COM от Microsoft, где важна читаемость при отладке и хранении значений в текстовом виде (например, в реестре Windows). Шестнадцатеричная запись с разделителями упрощает визуальный контроль, снижает вероятность ошибок при ручном копировании и облегчает сравнение строк. Фиксированная длина (128 бит) обеспечивает теоретически огромное адресное пространство - порядка 2¹²⁸ возможных значений, что делает коллизии практически невозможными при корректной генерации. Такой текстовый формат оказался удобен для логирования, конфигурационных файлов и текстовых протоколов, что способствовало его широкому распространению. Хотя изначально формат использовался в реализации Microsoft (GUID), он был стандартизирован как UUID в спецификации RFC 4122, где закреплен канонический вид записи: 8-4-4-4-12 шестнадцатеричных символов, разделенных дефисами (например, 550e8400-e29b-41d4-a716-446655440000). Сегодня этот формат стал де-факто стандартом для представления 128-битных уникальных идентификаторов.

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

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
символ M (14-я позиция в строке, нумерация с 0) кодирует версию алгоритма генерации (4 бита), а символ N (19-я позиция) - вариант формата (старшие биты поля варианта). Например, в UUID 550e8400-e29b-41d4-a716-446655440000 значение "4" в позиции M указывает на версию 4 (генерация на основе случайных чисел), а значение "A" (бинарно 10xx) в позиции N соответствует варианту 1 по спецификации RFC 4122. Можете изучить какой-нибудь GUID или попробовать самостоятельно сделать валидный GUID. Для удобства можете использовать мою программу GUID Helper.

Теперь перейдем к программированию. Как я и обещал, мы будем использовать Ассемблер. Для удобства работы с GUID применяется следующая структура:Начнем с проверки GUID. В структуре GUID поле версии занимает старшие 4 бита поля Data3 (смещение +6 в бинарном представлении). Это соответствует 14-й позиции в строковом формате xxxxxxxx-xxxx-Mxxx-xxxx-xxxxxxxxxxxx, где символ M отражает значение версии. Для извлечения версии из бинарного представления необходимо: загрузить 16-битное значение Data3, сдвинуть его вправо на 12 бит - останутся только биты версии (15-12), полученное 4-битное значение интерпретировать согласно спецификации RFC 4122:Проверка версии позволяет определить алгоритм генерации идентификатора, что критично при валидации данных, отладке или выборе метода обработки GUID в приложении. Например, версия 4 требует криптографической случайности, а версия 1 - корректной временной метки и уникального узла.

Поле варианта (variant) определяет формат и происхождение идентификатора. Оно хранится в старших битах первого байта поля Data4 (смещение +8 в бинарном представлении), что соответствует 19-й позиции в строковом формате xxxxxxxx-xxxx-xxxx-Nxxx-xxxxxxxxxxxx, где символ N отражает значение варианта. Для извлечения варианта необходимо: загрузить первый байт поля Data4, сдвинуть его вправо на 6 бит - останутся старшие 2 бита (биты 7-6), интерпретировать полученное значение согласно спецификации:Проверка варианта позволяет определить, соответствует ли GUID современному стандарту RFC 4122 (вариант 1). Большинство систем, включая Windows API и современные базы данных, ожидают именно этот вариант. Идентификаторы с другими вариантами могут быть отвергнуты или обработаны некорректно. При генерации случайного GUID (версия 4) обязательно устанавливайте вариант 1, записывая в Data4[0] значение с битовой маской 10xx xxxx (диапазон 0x80-0xBF).

Теперь перейдем к генерации GUID в ручном режиме. Для этого сначала необходимо получить 16 байт (128 бит) случайных данных удобным для вас способом, например, с помощью функции BCryptGenRandom. Эта функция из API Windows Cryptography API, предоставляет криптографически стойкие случайные данные.Полученные случайные данные нельзя сразу использовать как GUID - нужно правильно установить два служебных поля. Версия (поле M): старшие 4 бита байта по смещению +6 должны содержать значение 0100 (то есть цифру 4). Это указывает на версию 4, генерацию на основе случайных чисел. Вариант (поле N): старшие 2 бита байта по смещению +8 должны быть 10. Это дает диапазон значений 0x80-0xBF, который в строковом представлении проявляется как символы "8", "9", "a" или "b". Только после установки этих битов GUID будет соответствовать стандарту RFC 4122.

Для генерации GUID лучше использовать специальные системные функции: UuidCreate - основная функция из библиотеки rpcrt4.dll, генерирующая криптографически стойкий UUID (обычно версии 4 на основе случайных данных). CoCreateGuid - COM-обертка над UuidCreate из библиотеки ole32.dll. Функционально она не дает никаких преимуществ: просто вызывает UuidCreate и возвращает результат. Используется исключительно для удобства в COM-приложениях, когда ole32.dll уже загружена, а подключать дополнительно rpcrt4.dll не требуется. Обе функции возвращают валидный GUID, соответствующий стандарту RFC 4122. При ручной генерации через случайные числа (например, BCryptGenRandom) необходимо самостоятельно устанавливать биты версии и варианта, системные функции делают это автоматически.Также в WinAPI есть особая функция UuidCreateNil, которая возвращает нулевой (пустой) GUID: {00000000-0000-0000-0000-000000000000}. Это "синтаксический сахар" - тривиальная функция, которая просто заполняет 16 байт по указанному адресу нулями. В производственном коде ее вызов избыточен.Нулевой GUID, также называемый Nil UUID, используется как специальное значение-маркер: проверка инициализации - признак того, что переменная типа GUID еще не заполнена корректным значением; значение по умолчанию - инициализация полей структур или членов классов до получения реального идентификатора; а также безопасное и быстрое значение, не требующее генерации - достаточно обнулить 16 байт структуры или использовать предопределенную константу.

Для сравнения GUID используется функция IsEqualGUID, которая выполняет побайтовую проверку двух 128-битных идентификаторов. Функция игнорирует версию и вариант, сравнивает только "сырые" байты, поэтому два валидных GUID с разными версиями будут признаны разными. Такой подход широко применяется при работе с COM-интерфейсами, базами данных и любыми системами, где требуется явная проверка наличия уникального ключа перед его использованием.UuidCompare - функция для сравнения двух 128-битных идентификаторов с учетом их внутреннего представления. В отличие от простого побайтового сравнения IsEqualGUID, UuidCompare учитывает структуру поля UUID: порядок байт в Data1 (DWORD), Data2 (WORD) и Data3 (WORD) интерпретируется как единое знаковое целое. Функция возвращает: отрицательное значение, если первый UUID меньше второго; ноль, если равны; положительное значение, если первый больше. В Windows поля Data1, Data2, Data3 хранятся в формате little-endian, что важно при кросс-платформенной работе (например, сетевые UUID часто используют big-endian). Поэтому UuidCompare корректно сравнивает идентификаторы именно в контексте Windows-представления. Функция полезна для сортировки списков GUID или построения индексов, где требуется устойчивый порядок элементов. Для простой проверки равенства предпочтительнее использовать IsEqualGUID, она быстрее и не зависит от порядка байт.Для быстрого расчета хеша от GUID существует функция UuidHash, она возвращает 32-битное хеш-значение. Это позволяет ускорить сравнение и индексацию идентификаторов без хранения дополнительных метаданных. Однако для окончательной проверки равенства все равно требуется побайтовое сравнение через IsEqualGUID, так как 32-битный хеш может давать коллизии.Для преобразования бинарного представления GUID в человекочитаемый формат в Windows существует несколько функций, каждая решает свою задачу и имеет свои особенности. Чтобы превратить "непонятный" набор байтов в привычную строку вида {550e8400-e29b-41d4-a716-446655440000}, удобнее всего использовать функцию StringFromGUID2. Она берет ваш идентификатор и аккуратно записывает его в заранее подготовленный буфер, расставляя фигурные скобки и дефисы в нужных местах. Буфер должен вмещать всего 39 символов (38 под текст и один завершающий ноль), а освобождать память не требуется, функция работает напрямую с вашим буфером и не выделяет память самостоятельно. Благодаря этому StringFromGUID2 идеально подходит для повседневных задач: логирования, отладки или отображения идентификатора пользователю.Есть и другие варианты. Функции StringFromCLSID и StringFromIID, первая предназначена для идентификаторов классов, вторая для интерфейсов, но по сути обе являются обертками над одной и той же реализацией. Они выполняют похожее преобразование, однако сами выделяют память под результирующую строку. Это удобно, когда не хочется заботиться о размере буфера, но требует обязательного освобождения памяти через CoTaskMemFree, иначе со временем программа начнет "утекать".Функция UuidToString представляет собой низкоуровневый вариант преобразования GUID, унаследованный из RPC/DCE. В отличие от StringFromGUID2, она возвращают строку без фигурных скобок, просто "голой" последовательностью символов вида 550e8400-e29b-41d4-a716-446655440000. Такой формат часто встречается в сетевых протоколах и кроссплатформенных системах. Эта функция сама выделяет память под результирующую строку средствами RPC. Это избавляет от заботы о размере буфера, но обязывает программиста освободить память после использования и только с помощью специальной функции RpcStringFree. Использование других методов освобождения (например, CoTaskMemFree) приведет к неопределенному поведению.В программе часто возникает обратная задача: есть строка вида {550e8400-e29b-41d4-a716-446655440000}, прочитанная из файла, реестра или введенная пользователем, а нужен "настоящий" 128-битный идентификатор, 16 байт для передачи в API или сравнения. Для этого Windows предоставляет несколько функций, каждая со своими особенностями и областью применения.

Самый распространенный и надежный выбор - функция CLSIDFromString. Она принимает строку в формате Unicode (UTF-16) и заполняет 16-байтную структуру GUID, переданную по указателю. Главное преимущество - гибкость: функция одинаково хорошо понимает строки как с фигурными скобками "{...}", так и без них. Это особенно удобно, когда источник данных непредсказуем, например, один компонент сохраняет с скобками, другой без. Функция сама разбирает формат, проверяет корректность шестнадцатеричных цифр и расставляет байты в правильном порядке. Если используется обычная ANSI-строка из файла в кодировке Windows-1251 или UTF-8, ее сначала нужно преобразовать через MultiByteToWideChar, иначе результат будет неверным или функция вернет ошибку.Для работы с интерфейсами существует аналогичная функция IIDFromString. По сути, это та же реализация, что и CLSIDFromString, внутри вызывается один и тот же код. Различие чисто семантическое: в COM-коде принято использовать IIDFromString при парсинге идентификаторов интерфейсов, а CLSIDFromString - для классов. По работе отличий нет: обе функции принимают строки как с фигурными скобками "{...}", так и без них, работают с широкими строками в формате UTF-16 и заполняют 16-байтную структуру GUID без выделения памяти.UuidFromString - низкоуровневый RPC-вариант для низкоуровневой работы с UUID. Требования здесь строже: строка обязательно должна быть без фигурных скобок. Эти функции заполняют переданный буфер напрямую и не требуют освобождения памяти.GUIDFromString - устаревшая функция, оставшаяся от ранних версий Windows Shell. В отличие от современных аналогов, она ведет себя неочевидно: вместо заполнения 16-байтной структуры GUID она возвращает хэндл, который указывает на внутренний объект в памяти. Чтобы получить сами байты идентификатора, требуется дополнительное преобразование, а после использования необходимо освободить хэндл через GlobalFree. Из-за этой сложности, нестандартного поведения и наличия более простых и безопасных альтернатив, GUIDFromString рекомендуется избегать.Резюмируя сказанное: для большинства задач с GUID достаточно трех функций - UuidCreate для генерации, IsEqualGUID для сравнения и StringFromGUID2 / CLSIDFromString для преобразования в обе стороны. Они безопасны, не требуют ручного управления памятью и работают во всех версиях Windows без сюрпризов. Остальные функции нужны только в специфических сценариях: работе с COM, сетевыми протоколами или унаследованным кодом.

Комментарии

Добавить комментарий

Для вставки цитаты выделите текст и нажмите сюда

Имя*:

Текст комментария (не более 2000 символов)*:

*Все поля обязательны для заполнения.

Комментарии, содержащие рекламу, ненормативную лексику, оскорбления и т.п., а также флуд и сообщения не по теме, будут удаляться. Нарушителям может быть заблокирован доступ к сайту.