Генератор на UUID v4

Генераторът на UUID v4 е безплатен инструмент, който създава универсален уникален идентификатор версия 4 за използване като идентификатор на запис, обект или заявка.

Как генераторът на UUID v4 обработва данните ми?

Генерирането се извършва на сървъра. Входните данни се изпращат до него чрез HTTPS и не се съхраняват. Затова не би било вярно да се твърди, че генерирането протича изцяло в браузъра ти или че данните никога не напускат устройството ти.

За създаването на UUID v4 не е необходимо да въвеждаш личен текст, име или парола. Стойността се генерира като идентификатор, а не се изчислява от предоставена от теб информация. Не придавай поверително значение на получения идентификатор, тъй като всеки, който го вижда, може да го копира и използва повторно.

Какво представлява UUID v4?

UUID v4 е 128-битов идентификатор, чиято променлива част се генерира случайно или псевдослучайно. Няколко бита са запазени за обозначаване на версията и варианта на UUID. Този формат често се използва, когато отделни системи трябва да създават идентификатори, без първо да искат следващия свободен номер от централна услуга.

Стандартният запис съдържа 32 шестнадесетични знака, разделени с тирета в пет групи. Той следва модела 8-4-4-4-12 и е дълъг 36 знака заедно с четирите тирета.

Пример със синтактично валиден формат е 550e8400-e29b-41d4-a716-446655440000. При UUID версия 4 първият знак от третата група е 4. Двата най-значими бита, които определят варианта, са 10. Затова първият шестнадесетичен знак в четвъртата група е 8, 9, a или b.

Тази стойност е идентификатор, а не кодирана информация. Не можеш да я декодираш, за да възстановиш дата на създаване, име на профил, адрес на машина или пореден номер.

Коя версия на UUID да избера?

Избери версия 4, когато ти трябва независимо генериран, непрозрачен идентификатор и не е необходимо еднакви входни данни винаги да дават един и същ резултат. Накратко, v1 използва време и информация за възела, v2 е форматът DCE Security, v3 извежда UUID от пространство от имена и име чрез MD5, v4 е случаен, v5 извежда UUID чрез SHA-1, v6 пренарежда данните, базирани на време, v7 съчетава Unix времеви печат със случайни данни, а v8 е предназначен за експериментални формати или такива, специфични за даден доставчик.

• Използвай UUID v4 за идентификатори на записи, препратки към качени файлове, идентификатори на API заявки и тестови данни, когато са подходящи случайно разпределени идентификатори.
• Използвай UUID v5, когато определено пространство от имена и име трябва винаги да създават един и същ идентификатор. Той е полезен при повторяемо импортиране и правила за премахване на дубликати.
• Обмисли UUID v7, когато идентификаторите на записите трябва приблизително да следват реда на създаване и базата данни или софтуерът ти го поддържа.
• Използвай обикновено последователно цяло число, когато стойностите се създават от една база данни и компактните, естествено подредени ключове са по-важни от децентрализираното генериране.

По-старите версии продължават да се използват в съществуващи системи, но при нов проект избирай според действителните му изисквания, вместо да приемаш, че всички версии на UUID са взаимозаменяеми.

Използване на UUID v4 на практика

Генерирай UUID, вземи стойността от полето с резултат UUID v4 и запази целия каноничен низ, освен ако приемащата система не изисква друго представяне.

1. Създай нов UUID за обекта или събитието, което се нуждае от идентификатор.
2. Запази и петте групи и четирите тирета, когато го предаваш между системи.
3. Съхрани го в поле от тип UUID, ако базата данни предлага такова. В противен случай използвай текстово или двоично поле с размер, подходящ за избраното представяне.
4. Добави ограничение за уникалност, ако базата данни трябва да отхвърля дублирани генерирани стойности на UUID v4.

UUID обикновено се използва за идентифициране на поръчка, преди тя да достигне основната база данни, за свързване на записи в дневници от няколко услуги, за именуване на качен обект или за задаване на постоянни идентификатори на редове, подготвени за импортиране. Данни, създадени независимо в различни набори, често се обединяват по-лесно чрез UUID, отколкото чрез локални поредици от цели числа, защото във всеки източник може да има еднакви стойности.

Интервалите, препинателните знаци, буквите с диакритични знаци и знаците извън латиницата не създават проблем при UUID v4, защото идентификаторът не се извежда от текст. Ако ти трябва идентификатор, базиран на име с такива знаци, използвай схема за UUID, базирана на име, и определи точните правила за кодиране и нормализиране на знаците. В противен случай визуално еднакъв текст може да създаде различни поредици от байтове и съответно различни идентификатори.

Може ли два UUID v4 да са еднакви?

Да, теоретично е възможно съвпадение, но при обичайна употреба на UUID v4 то не представлява практически проблем, ако генерирането използва подходящ източник на случайни стойности. UUID v4 разполага със 122 променливи бита, тъй като останалите обозначават версията и варианта. Това оставя изключително голям набор от възможни стойности.

Следователно "универсално уникален" е практическо описание, а не математическа гаранция. Погрешното копиране или повторно използване на стойности, дефекти в реализацията или лошо генериране на случайни числа при неподходящ източник създават по-реалистичен риск от дублиране, отколкото чистата случайност. Системите, които не могат да допуснат дубликати, трябва все пак да налагат уникалност на ниво база данни или приложение.

UUID също не доказва, че дадена заявка е автентична. Не използвай видим UUID като единствено средство за оторизация и не приемай, че даден обект е защитен само защото адресът му се отгатва трудно. Проверките за достъп трябва да се прилагат към самия ресурс, към който сочи UUID.

Често задавани въпроси

Има ли значение дали UUID е с главни или малки букви?

Не, шестнадесетичните букви в текстовия запис на UUID обикновено се разглеждат без значение от регистъра, така че A и a представляват една и съща стойност. Каноничният запис обичайно е с малки букви. Уеднаквяването на регистъра преди текстово сравнение предотвратява непоследователни резултати в системи, които различават главни и малки букви при сравняване на низове.

Мога ли да използвам UUID v4 в URL или име на файл?

Да, каноничният формат съдържа шестнадесетични знаци и тирета, които са подходящи за обикновени сегменти от URL пътища и за разпространените файлови системи. Не добавяй фигурни скоби, освен ако конкретен API не ги изисква. Имай предвид, че публикуването на UUID в URL не прави ресурса поверителен.

Трябва ли да премахна тиретата от UUID?

Премахни ги само ако приемащият формат изрично очаква 32 шестнадесетични знака. Много библиотеки и полета от тип UUID в бази данни приемат каноничния формат с тирета. Хората го разпознават по-лесно и е по-малко вероятно да го объркат с несвързана шестнадесетична стойност.

Подходящ ли е UUID v4 за парола или API тайна?

Не, идентификаторът и тайната служат за различни цели. Някои реализации на UUID може да използват подходящ източник на случайни стойности, но самият формат UUID не гарантира изискванията за обработване, секретност или ентропия, необходими за пароли, сесийни токени и API идентификационни данни. Създавай такива данни и токени чрез механизъм, предназначен за тази цел, а не чрез генератор на UUID v4.

Може ли UUID v4 да е лична информация според GDPR?

Да, UUID може да представлява лични данни, когато идентифицира или може да бъде свързан с лице, което може да бъде идентифицирано, въпреки че самите знаци не разкриват пряко име. Обработвай UUID, свързани с клиентски профили, устройства или записи за активност, според конкретния контекст и правилата на организацията за съхранение и достъп.

Мога ли да използвам UUID v4 като първичен ключ в база данни?

Да, много бази данни поддържат директно първични ключове от тип UUID. Случайно разпределените ключове може да водят до по-малко локализирано добавяне в индексите в сравнение с подредени цели числа или идентификатори, базирани на време. Затова провери препоръките за съответната база данни при таблици с много операции за запис. Запази ограничението за уникалност и използвай едно и също представяне при импортиране, заявки и в програмния код.