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

Што е UUID v4 и како работи овој генератор

UUID v4 (Universally Unique Identifier, верзија 4) е 36-карактерен идентификатор во стандардниот 8‑4‑4‑4‑12 хексадецимален формат. Канонскиот изглед е xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, каде x се 122 бита случајна вредност, а 4 и y се фиксни битови за верзијата и варијантата. Вкупно, од 128-те бита, 122 се цврста случајност – тоа е 122 бита ентропија. Преостанатите 6 бита се задолжителни: 4 бита ја кодираат верзијата (4), а 2 бита ја кодираат варијантата (обично 10 во бинарно, што дава 8, 9, a или b на таа позиција).

Нашата страница генерира еден или повеќе вакви идентификатори директно во вашиот прелистувач, без никаква комуникација со сервер. Избирате број од 1 до 100, дали да се користат големи букви (A–F наместо a–f) и дали да се вклучат цртичките. Веднаш по промената на која било опција, сите ID-а се регенерираат. Едноставно кликнете на поединечен UUID за да го копирате во клипборд, или притиснете го копчето „Копирај ги сите“ за да ги преземете сите одеднаш. Статусот „Ready.“ или „Generated.“ ве известува за состојбата, а по успешно копирање на сите се прикажува „Copied all!“.

Што го прави овој генератор различен од другите алатки

Клучната карактеристика на оваа страница е чистата 122-битна случајност и тоа што таа не содржи временска компонента. За разлика од UUID v7 или ULID, кои вградуваат временски печат за овозможување хронолошки редослед, UUID v4 вредностите се подредуваат произволно. Нема никаква поврзаност помеѓу времето на создавање и нивната низа.

Токму поради тоа што идентификаторите се сосема случајни, нивното користење како примарен клуч во релациона база на податоци предизвикува значително фрагментирање на B-дрво индексите. Ова е клучна практична разлика во споредба со временски подредените формати. Додека v7 и ULID овозможуваат последователно вметнување на нови записи (новите ID-а секогаш се поголеми од старите), v4 ги расфрла записите низ целиот опсег на индексот, што доведува до чести преструктурирања и полоши перформанси при запишување.

Веројатноста за колизија (два исти UUID v4) е занемарлива за практични цели. Со 122 бита случајност, ризикот е толку мал што може да се игнорира дури и во системи со милијарди записи. На пример, според формулата на роденденскиот проблем, потребни би биле околу 2^61 (~2.3 милијарди) вредности за да се достигне 50% веројатност за колизија. Во реален свет, генераторите со квалитетна случајност (како crypto.randomUUID што го користиме овде) никогаш не произведуваат дупликати за нормални количини.

Страницата исто така нуди специфични контроли за форматирање кои се релевантни само за UUID v4 и v7: можност за префрлување помеѓу мали и големи букви, и вклучување/исклучување на цртичките. Други ID типови на истата алатка (како ULID или NanoID) имаат свои различни опции.

Структура на UUID v4 – 122 бита случајност и 6 фиксни бита

За подобро да се разбере како се гради еден UUID v4, еве преглед на битовите по позиции:

Вкупно: 122 случајни бита + 2 за варијанта + 4 за верзија = 128 бита.

Кога ги исклучувате цртичките, добивате 32 хексацифрени знаци (128 бита / 4 бита по знак). Оваа компактна форма е корисна во URL или средини каде цртичките создаваат проблеми (на пример, во име на датотека). Употребата на големи букви (A–F) е чисто визуелна – стандардот дозволува и помали и големи букви, но некои системи се строги и очекуваат само мали букви.

Влијание врз индексирање на бази на податоци

Кога користите UUID v4 како примарен клуч во релациона база (на пример PostgreSQL, MySQL или SQL Server), се соочувате со проблемот на фрагментирање на B-дрво индексите. Бидејќи новите вредности се случајни, тие се вметнуваат на произволни позиции во индексот. Ова предизвикува:

• Чести пресплитувања на страници: Податоците не се собираат на крајот од индексот, туку се расфрлаат.
• Помалку локалност на кешот: Базата почесто чита различни страници, наместо секвенцијална секвенца.
• Поголемо време за запишување: Секој INSERT бара ажурирање на повеќе индексни страници отколку кај монотон растечки клуч.

Спротивно, UUID v7 вклучува временски печат на почетокот, така што новите ID-а се секогаш поголеми од старите. Ова овозможува индексот да расте на крајот, како кај авто-инкремент клучевите. ULID исто така е временски подреден, но користи различно кодирање со 26 карактери (систем base32).

Сепак, постојат случаи кога случајните ID-а се подобар избор:

• Дистрибуирани системи кои работат без централна координација – нема потреба да се синхронизираат временски печати.
• Системи кои не смеат да откријат редовен редослед (на пример, API клучеви – ако се временски подредени, напаѓачот може да погоди нови вредности).
• Офлајн во средини каде часовниците не се сигурни.

Случаи на употреба – кој има потреба од оваа алатка

Најчести корисници се:

• Апликациски програмери кои треба да креираат голем број уникатни клучеви за објекти, сесии или настани (на пример идентификатор за секоја HTTP барање во микроуслужен систем).
• Дизајнери на бази на податоци кои свесно го прифаќаат индексното фрагментирање во замена за способност да генерираат ID-а без централна точка на неуспех.
• Инженери за безбедност кои бараат непредвидливи идентификатори за API токени, ID на кориснички сесии или коридинатори за пристап – времето не смее да биде предвидливо.
• Тестери и генератори на податоци кои пополнуваат примерок бази со реални уникатни вредности без да се потпираат на секвенцијални броеви.

Алатката генерира до 100 идентификатори одеднаш, што е доволно за брзо пополнување на табели за тестирање или креирање на серија клучеви во една операција.

Прилагодување на форматот – кога да користите големи букви и да отстраните цртички

Опциите „Uppercase“ и „Include hyphens“ се едноставни, но имаат практични последици.

Без цртички (32 хексацифри):

• Идеално за URL, имиња на датотеки, JSON клучеви.
• Полесно за копирање/вметнување во системи кои очекуваат компактен стринг.
• Но, губите читливост – тешко е човек да ги разликува сегментите.

Со големи букви:

• Некои API и бази на податоци ги третираат малите и големите букви еднакво (Case insensitive). Но, стандардот RFC 9562 препорачува мали букви.
• Големите букви можат да бидат подобри за отчитување во светло на терминал со позадина (на пример во логови).
• Ако вашиот систем е строго case-sensitive и очекува мали букви, префрлете го прекинувачот во исклучена позиција.

Менувањето на која било опција веднаш регенерира целиот сет. Ова е намерно – секоја промена во барањата за формат треба да даде нови, конзистентни ID-а. Ако ви требаат идентификатори со различни формати, генерирајте ги одвоено.

FAQ (Често поставувани прашања)

Колку UUID v4 може да генерирам во еден обид?

Бројот мора да биде помеѓу 1 и 100 вклучително. Страницата прифаќа само цели броеви во овој опсег.

Зошто користите 122 бита случајност наместо да ги користите сите 128?

Задолжителните 4 бита служат за да го идентификуваат форматот како UUID v4, а 2 бита за варијанта. Ова е дел од стандардот RFC 9562 и обезбедува интероперабилност – секој систем знае дека тоа е случаен UUID.

Може ли да се појави потполно ист UUID v4 двапати?

Со 122 бита случајност, веројатноста е астрономски мала. За да имате 50% веројатност за колизија, треба да генерирате околу 2.3 милијарди идентификатори. Во секојдневна употреба (стотици или илјадници) – практично невозможно.

Како да копирам еден UUID наместо сите?

Едноставно кликнете со глувчето на самиот идентификатор. Тој веднаш се копира во клипборд, а статусот останува „Copied all!“ само ако го користите копчето за копирање на сите.

Што се случува ако променам формат (големи букви или цртички) додека имам генерирано ID-а?

Сите ID-а се регенерираат моментално со новите поставки. Вашите претходни ID-а се губат – затоа копирајте ги пред да ги менувате опциите.

Дали моите UUID-и се испраќаат до сервер?

Не. Сите генерирања се случуваат во вашиот прелистувач, користејќи го crypto.randomUUID() или crypto.getRandomValues(). Ништо не се испраќа преку интернет. Ова гарантира и приватност и мала латенција.