Инструменты разработчика · Генератор UUID
GUID против UUID: скобки Microsoft, порядок байтов и объяснение вариантов
· Фон
uuid криптография API-интерфейс браузера
GUID — это имя Microsoft для UUID, но фигурные скобки, верхний регистр и порядок байтов могут привести к тому, что один и тот же идентификатор будет выглядеть по-разному на разных платформах. В этом посте объясняется каждое различие и способы безопасного сравнения.
Один и тот же идентификатор, который не совпадает в разных системах — служба .NET и служба Java расходятся во мнениях по одной записи.
Служба .NET генерирует GUID и отправляет его службе Java, которая пытается сопоставить значение с UUID из PostgreSQL. Сравнение строк не удается, и системы сообщают, что идентификаторы не совпадают, хотя все три службы работают с одним и тем же базовым 16 bytes. Различия кажутся косметическими — фигурные скобки, регистр, порядок байтов — но они приводят к сбою сравнения строк и сбивают с толку точки интеграции, которые не нормализуются на границе. GUID — это терминология Microsoft, обозначающая то, что RFC 9562 называет UUID: 128-битный идентификатор с той же битовой структурой. Эти два названия относятся к одной и той же фундаментальной структуре, но их представление различается, что застает разработчиков врасплох. Понимание причин возникновения путаницы предотвращает ошибки интеграции.
GUID — это UUID — общий 128-битный формат, откуда возникла разница в именах.
GUID означает глобальный уникальный идентификатор и глобальный уникальный идентификатор и является именем, которое Microsoft использует для того, что в стандартах RFC называется UUID. 128-битная раскладка и система версии /variant идентичны. RFC 4122 и RFC 9562 определяют формат и значение UUID; Microsoft реализует их и использует термин GUID. Разница в именах историческая: Microsoft использовала GUID до того, как UUID были стандартизированы IETF, а терминология Microsoft застряла в экосистеме .NET. На уровне битов GUID и UUID полностью взаимозаменяемы. На уровне форматирования они различаются по представлению: код .NET часто записывает GUID с фигурными скобками и прописными буквами, тогда как канонические UUID RFC используют строчные буквы и не содержат фигурных скобок.
Фигурные скобки и прописные буквы — форма {XXXXXXXX-...} в стиле реестра и способы ее нормализации
UUID в канонической форме RFC записывается как восемь, четыре, четыре, четыре и двенадцать строчных шестнадцатеричных символов, разделенных дефисами: 550e8400-e29b-41d4-a716-446655440000. .NET GUID обычно отображается с фигурными скобками и заглавными буквами: {550E8400-E29B-41D4-A716-446655440000}. Фигурные скобки взяты из формата реестра Windows; Прописные буквы — это соглашение об отображении. Обе формы представляют собой один и тот же 128 bits. Чтобы сопоставить GUID из .NET с UUID из PostgreSQL, удалите фигурные скобки и нормализуйте регистр, а затем сравните строки. ToolAcre правильно сформированная проверка принимает каноническую форму и автоматически удаляет фигурные скобки. Нормализация — это незначительное преобразование текста, сохраняющее весь смысл.
Смешанный порядок байтов — как первые три поля хранятся с прямым порядком байтов в структуре GUID и почему Guid.ToByteArray отличается от порядка байтов RFC.
Опасное различие между GUID и UUID заключается в порядке байтов. RFC 9562 указывает, что первые три поля (8, 4 и 4 шестнадцатеричные группы) хранятся в обратном (сетевом) порядке байтов. .NET Структура Guid хранит первые три поля с прямым порядком байтов: перед записью в хранилище байты меняются местами. Один и тот же 16 bytes, написанный с помощью .NET Guid.ToByteArray() и интерпретированный кодом, совместимым с RFC, создает совершенно разные текстовые представления. A UUID 550e8400-e29b-41d4-a716-446655440000 в порядке RFC хранится в виде байтов 55 0e 84 00 e2 9b 41 d4 a7 16 44 66 55 44 00 00.
Устаревший вариант Microsoft — что означают буквы c или d в первом символе четвертой группы
Помимо порядка байтов, устаревшие идентификаторы Microsoft иногда используют нестандартное поле варианта. Если RFC 9562 указывает, что первый символ четвертой группы должен быть 8, 9, a или b, устаревшие GUID Microsoft могут использовать c, d, e или f. Это все еще действительные UUID, но они соответствуют устаревшему варианту, предшествовавшему стандартизации RFC. Если вы встретите GUID с c или d в первом символе четвертой группы, у вас есть допустимое 128-битное значение, которое не соответствует битам варианта RFC. Современный .NET генерирует GUID, совместимый с RFC, поэтому новые идентификаторы не должны вызывать эту проблему. Биты устаревших вариантов встречаются редко, но их важно распознавать.
Рабочий пример — тот же 16 bytes, отображенный в порядке RFC и в порядке структуры GUID, показывающий, какие именно символы меняются местами.
Возьмите UUID 550e8400-e29b-41d4-a716-446655440000 и преобразуйте его в форму массива байтов .NET GUID, используя соглашение с прямым порядком байтов. В порядке RFC байты следующие: первое поле (550e8400) равно 55 0e 84 00, второе поле (e29b) равно e2 9b, третье поле (41d4) равно 41 d4, четвертое и пятое равны a7 16 44 66 55 44 00 00. В .NET с прямым порядком байтов: первое поле становится 00 84 0e 55, второе становится 9b e2, третье становится d4 41, а остальные остаются с прямым порядком байтов. Полный массив байтов: 00 84 0e 55 9b e2 d4 41 a7 16 44 66 55 44 00 00. Если система Java читает эти байты, ожидая порядка RFC, она интерпретирует их как 00840e55-9be2-d441-a716-446655440000.
Что здесь не распространяется — SQL Сервер NEWSEQUENTIALID и упорядочивание, которые являются отдельной темой хранилища.
SQL Поведение функции сервера NEWSEQUENTIALID и ее особые свойства упорядочивания идентификаторов относятся к уровню хранения и темам, специфичным для базы данных. В этом посте основное внимание уделяется различиям в формате и порядке байтов на уровне приложения и сериализации. Глубокие проблемы обработки UUID и порядка байтов, специфичные для базы данных, лучше всего рассматривать в документации, специфичной для этой платформы базы данных. В разных системах баз данных используются разные подходы и подходы к хранению, индексированию, сортировке и встроенной поддержке UUID. Некоторые базы данных автоматически определяют биты версии и варианта, в то время как другие требуют явного объявления типа и обработки порядка байтов на границе между системами и хранилищем.
Вывод: нормализация на границе — проверка ToolAcre принимает каноническую форму, которая является формой для стандартизации при обмене идентификаторами.
Нормализуйте границу, когда идентификаторы пересекают границу системы .NET/non-.NET. Удалите фигурные скобки, нормализуйте регистр и поменяйте местами первые три поля, если байты получены из .NET Guid.ToByteArray(). Каноническая форма RFC является эталонным стандартом: восемь, четыре, четыре, четыре и двенадцать строчных шестнадцатеричных символов с дефисами, без фигурных скобок, порядок байтов с обратным порядком байтов. При обмене с системами .NET согласуйте нормализованную форму и явно примените преобразования в коде интеграции. Тщательно документируйте обработку порядка байтов и тестируйте преобразования. Основные фундаментальные сходства между GUID и UUID означают, что большинство 128 bits идентичны.