Инструменты разработчика · Генератор UUID
Чтение UUID вручную: где живут биты версии и варианта
· Как это работает
uuid криптография API-интерфейс браузера
Два шестнадцатеричных символа в каждом UUID сообщают вам, какая версия создала его и какому варианту макета он соответствует. Научитесь читать их с первого взгляда и понимать то, о чем они не могут вам сказать.
Какая система создала этот идентификатор? — вопрос лог-криминалистики, на который может ответить полубайт версии
Строка UUID содержит 36 символов: тридцать две шестнадцатеричные цифры и четыре дефиса в позициях 8-4-4-4-12. Два символа в каждом UUID, встречающиеся в позициях 14 и 19, кодируют метаданные: поле версии сообщает вам, какой алгоритм сгенерировал идентификатор, а поле варианта сообщает, какому стандартному макету он соответствует. Чтение этих двух символов без инструментов — это навык криминалистической экспертизы журналов: вы замечаете UUID в дампе базы данных или сообщении об ошибке и сразу понимаете, является ли это меткой времени v1 (которая указывает время создания), случайным значением v4 (которое было сгенерировано из CSPRNG) или чем-то еще. Номер версии занимает биты 48–51 в UUID, который соответствует первому шестнадцатеричному символу третьей группы.
Расположение 128 битов в пяти группах — как 8-4-4-4-12 сопоставляется с байтами и почему группы являются историческими, а не функциональными
Для строки xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx символ в позиции 14 является версией. RFC 9562 определяет версии с 1 по 8: v1 основан на григорианском времени и содержит информацию о времени создания; v4 — случайный; Версия v7 основана на времени Unix и допускает сортировку. Версия 0, 9 и выше зарезервированы или не используются. Если вы видите v1 UUID, вы знаете, что время и аппаратный адрес были перепутаны; если вы видите v4, идентификатор представляет собой случайные байты с установленными битами версии; если вы видите версию 7, она сортируется по времени создания. Эта версия не является дополнительной; у каждого правильно сформированного UUID есть такой. Поле вариантов занимает биты 64–65 UUID, два старших бита октета 8.
Полубайт версии — первый символ третьей группы, что означают от 1 до 8 и что там указывают 0 или 9.
В текстовом представлении xxxxxxxx-xxxx-xxxx-Nxxx-xxxxxxxxxxxx первый символ четвертой группы (позиция 19) кодирует вариант. Для варианта RFC 9562 (стандарт в современном использовании) этот символ должен быть 8, 9, a или b — шестнадцатеричные представления 1000, 1001, 1010 и 1011 в двоичном формате. Любой другой символ (0–7, c–f) указывает на другой вариант: 0–7 — это NCS обратная совместимость; c–d — устаревшие GUID Microsoft с прямым порядком байтов; e–f зарезервированы. Когда вы читаете позицию 19 и видите 8, 9, a или b, вы смотрите на RFC 9562 UUID. Любое другое значение означает, что байты интерпретируются по-другому. 128-битный макет делится на октеты 0–15, но текстовый формат разделяет их по группам для удобства чтения, а не для функциональности.
Поле варианта — почему первым символом четвертой группы является 8, 9, a или b для RFC UUID и какой сигнал c/d (наследие Microsoft) или 0–7 (NCS)
Пять групп представляют исторические границы полей: первые три поля содержат метку времени и версию в UUID v1, четвертое поле содержит последовательность и вариант часов, пятое поле содержит идентификатор узла. Версия 4 и более поздние версии UUID не используют эти имена полей, но те же битовые позиции по-прежнему содержат версию и вариант. Чтение UUID версии 4 означает признание того, что большая часть 128 bits является случайной полезной нагрузкой, но два из них — в позициях 14 и 19 в тексте — фиксированы по стандарту. Эти фиксированные биты доказывают, что идентификатор является вариантом v4 и RFC. Ноль UUID равен 00000000-0000-0000-0000-000000000000, все нули и не содержит никакой версии. Максимальное значение UUID — это ffffffff-ffff-ffff-ffff-ffffffffffff, все символы f, а также зарезервировано и неверсировано.
Рабочий пример — посимвольное декодирование трех образцов идентификаторов, включая v4 и v7.
Каждый второй правильно сформированный UUID имеет версию в третьей группе и вариант в четвертой. Проверьте себя с тремя идентификаторами образцов: 123e4567-e89b-12d3-a456-426614174000 (v1, вариант RFC, поскольку позиция 19 равна a); 9b2e4f1a-4f3e-4c1a-8a7d-1b2c3d4e5f60 (v4, вариант RFC, поскольку позиция 19 равна 8); 018f0c2e-1b5a-7c3d-9e4f-5a6b7c8d9e0f (v7, вариант RFC, поскольку позиция 19 равна 9). Инспектор ToolAcre подтверждает ваши показания. Проверка формата не может сказать вам, что идентификатор уникален, существует в вашей базе данных или был сгенерирован безопасным образом. Версия v1 использует время и аппаратное обеспечение в качестве входных данных, поэтому идентичные UUID версии v1 на разных машинах означают перекос часов или проблемы с синхронизацией. Версия v4 является случайной, поэтому дубликат v4 UUID означает либо нарушение случайности, либо астрономически маловероятное столкновение (примерно одно на 2. 7 триллиона UUID с достоверной случайностью).
Nil и Max — два значения «все ноль» и «все F», которые вообще не содержат версии.
Версия 0 или 9 означает, что строка вообще не является допустимой UUID. Чтение версии и варианта — это первый шаг к пониманию того, что такое идентификатор; проверка его существования или уникальности — это второй и третий шаги, выполняемые вашей базой данных и бизнес-логикой. Понимание битовых позиций помогает отлаживать миграцию данных. При импорте UUID из устаревших систем некоторые инструменты экспортируют поля вариантов, которые не соответствуют стандарту RFC 9562. Вариант поля c или d указывает Microsoft GUID в порядке байтов с прямым порядком байтов. Эти идентификаторы GUID являются допустимыми идентификаторами в системах Microsoft, но не взаимодействуют с UUID RFC 9562 без преобразования порядка байтов. Чтение позиции 19 сразу сообщает вам, какая система сгенерировала идентификатор. Если вы видите 8, 9, a или b, у вас есть RFC стандартный UUID.
Чего вам не может сказать проверка формата: что идентификатор существует в вашей базе данных, что он был сгенерирован безопасным образом или что он уникален.
Если вы видите c или d, у вас есть Microsoft GUID. Если вы видите какой-либо другой символ, идентификатор имеет неверный формат или принадлежит неизвестной системе. Генератор ToolAcre всегда создает RFC 9562 UUID с позицией 19 как один из 8, 9, a или b. Трехбитное поле версии кодирует семь возможных значений (1–7; версии 0 и 8 имеют особое значение). Версия 1 — это григорианская временная метка, версия 3 — пространство имен на основе MD5, версия 4 — случайное, версия 5 — пространство имен на основе SHA-1, версия 6 — это На основе временной метки Unix (предлагается), версия 7 является сортируемой на основе временной метки Unix (стандартизована в RFC 9562), версия 8 зарезервирована для пользовательских форматов. Чтение символа позиции 14 сразу сообщает вам, какой алгоритм использовался. Если вы отлаживаете коллизии UUID или неожиданные сортировки, номер версии — ваша первая подсказка. ToolAcre генерирует UUID v4 исключительно из криптовалюты.
Вывод: два символа, много контекста — используйте правильно сформированную проверку ToolAcre, чтобы подтвердить синтаксический анализ строки, а затем самостоятельно прочитайте фрагмент версии.
получить случайные значения; каждый UUID, который он производит, имеет 4 в позиции 14. Анализ структуры UUID вручную — полезный навык для отладки сложных систем, где инструменты недоступны. В производственном инциденте вам может потребоваться прочитать UUID из дампа базы данных, журнала ошибок или кэша без запуска специального инструмента. Вы ищете позицию 14, чтобы идентифицировать версию (есть ли утечка времени? Является ли она случайной? Можно ли ее сортировать?). Вы ищете позицию 19, чтобы идентифицировать вариант (это стандарт RFC? это Microsoft GUID? он зарезервирован? ). Эти два символа из общего числа 36 несут метаданные. Остальные символы 34 представляют собой полезные данные: метку времени, случайные байты или другие данные, специфичные для алгоритма. Знание того, что представляет собой полезная нагрузка, поможет вам понять роль идентификатора в вашей системе.