Инструменты разработчика · Генератор UUID
RFC 4122 против RFC 9562: что изменилось в стандарте 2024 UUID
· Фон
uuid криптография API-интерфейс браузера
Для UUID приводятся два RFC, и они не говорят об одном и том же. В этом посте рассказывается о том, что RFC 9562 добавило, прояснило и устарело относительно RFC 4122.
Какой RFC я цитирую? — путаница, когда документация и библиотеки ссылаются на разные стандарты.
В документации UUID обычно цитируются два RFC, и они не говорят об идентичных вещах. RFC 4122, опубликованный в 2005, определяет UUID и их пять версий (v1–v5). RFC 9562, опубликованный в 2024, полностью устарел RFC 4122, проясняет неясности, над которыми работали практикующие специалисты, добавляет три новые версии (v6, v7, v8) и обновляет руководство по реализации случайности. Когда библиотека ссылается на RFC 4122, это не является ошибкой: эта библиотека могла быть выпущена до публикации RFC 9562 или у сопровождающих может не быть обновленной документации. Проверка цитат RFC позволяет узнать, когда библиотека в последний раз значительно обновлялась. При написании новых спецификаций или оценке реализаций RFC 9562 является нормативной ссылкой.
Устаревание, а не замена формата — все, что действительно в RFC 4122, остается действительным; биты макета и варианта не изменяются
RFC 9562 формально устаревает RFC 4122 в качестве текущего справочного документа, сохраняя при этом знакомое 128-битное представление, шестнадцатеричные группы, положение версии и структуру основного варианта. Существующие сохраненные строки UUID не нужно перевыпускать только потому, что существует более новая RFC. Практическая миграция заключается в документации, генераторах и политике проверки: ссылайтесь на текущий стандарт, разбирайтесь в добавленных версиях и проверяйте, не основывался ли старый код на двусмысленности, разъясненной в версии. Совместимость по-прежнему следует проверять на границах системы, особенно если библиотека сериализует структуры Microsoft GUID или применяет более узкий набор версий, чем описано в стандарте.
Три новые версии — v6 (переупорядоченное время), v7 (упорядоченное по времени Unix-эпохи) и v8 (определяемое реализацией).
RFC 9562 добавляет к стандарту три новые версии. Версия 6 изменяет порядок битов метки времени v1 для создания лексикографически сортируемых идентификаторов для повышения производительности базы данных. Версия 7 использует 48-битную миллисекундную метку времени Unix, за которой следуют случайные биты, обеспечивая упорядоченную по времени генерацию без проблем конфиденциальности версии 1. Версия 8 — это аварийный выход для макетов, определяемых реализацией. Ни одна из этих версий не меняет работу версий v1-v5 или их значение. UUID версии 1 из 2005 и UUID версии 7 из 2024 могут сосуществовать в одной базе данных, каждая из которых имеет свои биты версии, определяющие метод генерации. В трех новых версиях рассматриваются общие закономерности, возникшие на практике.
Макс UUID присоединяется к Nil — значению all-F, определенному рядом с нулевым значением.
RFC 4122 задокументировал ноль UUID (все нулевые биты) как специальное ссылочное значение в примерах и документации. RFC 9562 включает то же определение Nil, но формально определяет максимальное значение UUID (все биты установлены в единицу) для границ диапазона. Ни Nil, ни Max не являются случайной версией 4 UUID, поскольку у них нет правильных битов версии и варианта. Макс. UUID полезен в качестве верхней границы диапазона в запросах к базе данных: WHERE uuid_column <= MAX_UUID соответствует всем возможным UUID. Nil полезен в качестве индикатора неназначенных значений в столбцах UUID с нулевым значением. RFC 9562 документирует оба документа, не предписывая их использование в данных приложения.
Уточнение рекомендаций — явный совет использовать CSPRNG для случайных полей, для монотонных счетчиков в пределах миллисекунды и для предпочтения упорядоченных по времени версий для локальности базы данных.
RFC 9562 Руководства по передовому опыту отличают устойчивость к столкновениям от непредсказуемости. В случайных полях следует использовать источник, соответствующий модели угроз приложения, а непрозрачность, чувствительная к безопасности, требует CSPRNG. Генераторы, основанные на времени, имеют отдельную проблему монотонности, когда несколько идентификаторов имеют один и тот же тик временной метки; стандарт описывает счетчики и дополнительную точность временных меток как возможные методы, каждый из которых имеет правила состояния и опрокидывания. Версии на основе имени остаются детерминированными идентификаторами, а не доказательствами подлинности. Эти пояснения важны, поскольку один синтаксический анализатор UUID может принимать все макеты, даже если их требования к генерации и свойства раскрытия информации различаются.
Где проявляются идеи ULID — как формат сообщества повлиял на дизайн v7
RFC 9562 сообщает, что его авторы проанализировали несколько существующих схем сортируемых идентификаторов, включая ULID, Snowflake и KSUID, при разработке новых макетов. Это подтверждает скромный вывод: оперативный спрос на упорядоченные по времени распределенные идентификаторы повлиял на пересмотр. Это не доказывает, что какой-то формат сообщества передал точное расположение полей версии 7. Практического сходства достаточно для архитектурной работы: эти семейства размещают информацию о времени спереди, чтобы обычный порядок мог сохранить широкий порядок создания, а затем различаются кодировкой, координацией и поведением внутри такта. Выбирайте между ними по совместимости экосистем и документальным гарантиям, а не по заявлению о прямом происхождении.
Чего это не касается — построчную разницу; этот пост посвящен практическим последствиям для разработчиков
В этом подробном посте рассматриваются практические последствия и реализация RFC 9562 для разработчиков и пользователей, а не построчные различия с RFC 4122. Полные спецификации доступны в организациях по стандартизации, и их стоит прочитать для реализации обработки UUID на языках или платформах — текст содержит достоверные подробности, выходящие за рамки того, что может охватить обзор. В этом посте не описывается механизм битового уровня того, как v6 переупорядочивает байты v1 или как v7 кодирует миллисекунды Unix. И стандарты, и руководства по реализации остаются основным авторитетным справочником по любым вопросам реализации, касающимся расположения битов, кодирования или проверки соответствия.
Вывод: обновите цитаты и значения по умолчанию — генератор ToolAcre следует руководству CSPRNG, которое разделяют оба RFC.
Для любой новой работы обновляйте документацию и спецификации, ссылаясь на RFC 9562. Каждый UUID из RFC 4122 остается действительным до RFC 9562 — миграция носит исключительно перспективный и административный характер. В уточненном руководстве по криптографической случайности подчеркивается, что идентификаторы должны поступать из криптографически безопасных источников в производственных системах. ToolAcre следует рекомендациям по криптографической случайности из обоих RFC, используя исключительно Web Crypto API браузера. Когда вы встречаете UUID в журналах, при экспорте базы данных или в ответах API, правильно сформированная проверка ToolAcre сообщает его версию и вариант по сравнению с RFC 9562. RFC 9562 — это уточнение и модернизация уже стабильного стандарта.