Gumawa agad ng UUID at GUID: I-integrate ang tool na ito sa iyong workflow para makagawa ng cryptographically secure, collision-resistant na identifier para sa mga database, distributed system, API payload, test data, at pagpapangalan ng file — direkta sa browser, walang koneksyon sa server.

Ano ang UUID?

Ang UUID (Universally Unique Identifier) ay isang 128-bit na label na na-standardize ng RFC 9562 (inilabas noong Abril 2024, pinalitan ang RFC 4122 mula 2005). Ang pangunahing katangian nito ay maaari itong ma-generate nang independyente sa kahit anong makina, kahit kailan, nang walang sentral na coordinating authority — at mananatiling natatangi sa buong mundo para sa lahat ng praktikal na layunin.

Ang standard na text representation nito ay 32 hexadecimal digit na nahahati sa limang grupo ng mga hyphen:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Dito ang M ay nagko-encode ng version (ang algorithm na ginamit para gumawa ng UUID) at ang N ay nagko-encode ng variant (ang pamantayan ng bit layout — laging 8, 9, a, o b para sa RFC 9562 UUID).

Halimbawa ng UUID v4:

550e8400-e29b-41d4-a716-446655440000

Iyon ay 32 hex character = 128 bit ng data. Ang posisyon ng mga hyphen ay puro aesthetic at walang impormasyong dinadala — inaalis ang mga ito kapag ang UUID ay nakaimbak sa binary o compact na anyo.

Gaano Ka-unique ang “Universally Unique”?

Gumagamit ang UUID v4 ng 122 bits ng randomness (6 bits ang nakalaan para sa version at variant metadata). Para maunawaan ang collision risk: kung gagawa ka ng 1 bilyong UUID bawat segundo, kailangan mong panatilihin ang rate na iyon sa loob ng humigit-kumulang 85 taon bago maabot ang 50% na posibilidad ng isang collision. Para sa kahit anong tunay na sistema, ang posibilidad ng collision ay halos zero.

UUID vs GUID — Pareho Ba Sila?

Oo, para sa mga layunin ng modernong development, ang UUID at GUID ay iisa.

Ang GUID (Globally Unique Identifier) ay termino ng Microsoft, ipinakilala kasama ang COM/DCOM noong 1990s. Sumusunod ang GUID sa parehong RFC 9562 layout at 128-bit na sukat. Ang makasaysayang pagkakaiba ay ang paraan ng Microsoft sa pag-serialize ng ilang field sa binary format — ngunit sa string form (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx), ang UUID at GUID ay magkapareho at maaaring gamitin nang palitan.

Sa praktis: ang Windows at .NET ecosystem ay karaniwang nagsasabi ng GUID, habang ang Linux, macOS, web API, at mga database ay karaniwang nagsasabi ng UUID. Parehong tumutukoy sa iisang pamantayan.

Paliwanag sa Lahat ng Bersyon ng UUID

Ang version number ay hindi nangangahulugang “mas bago ay mas magaling.” Tinutukoy nito ang algorithm na ginamit para gumawa ng UUID. Ang bawat version ay naglulutas ng ibang problema.

Version	Algorithm	Maaaring Uriin	Kaso ng Paggamit
v1	Timestamp + MAC address	Bahagyang	Para sa legacy system lamang
v2	DCE Security (POSIX UID/GID)	Hindi	Lipas na, iwasan
v3	Namespace hash gamit MD5	Hindi	Deterministikong ID (MD5 sira na, gumamit ng v5)
v4	Random	Hindi	Pangkalahatang layunin — ligtas na default
v5	Namespace hash gamit SHA-1	Hindi	Deterministikong ID mula sa pangalan + namespace
v6	Na-reorder na timestamp + random	Oo	Daan ng migration mula v1
v7	Unix timestamp + random	Oo	Database primary key, modernong sistema

UUID v1 — Timestamp at MAC Address

Ino-encode ng v1 ang kasalukuyang timestamp (sa 100-nanosecond na agwat mula Oktubre 1582) kasama ang MAC address ng nag-generate na makina. Nagbibigay ito ng bahagyang time-ordering ngunit naglalantad ng parehong machine identity at creation time sa loob mismo ng UUID. Iwasan ang v1 sa kahit anong pampublikong API o sistema kung saan mahalaga ang privacy.

UUID v2 — DCE Security

Ang v2 ay variant ng v1 na pinapalitan ang bahagi ng timestamp ng POSIX UID, GID, o domain identifier. Idinisenyo para sa Distributed Computing Environments (DCE) noong unang bahagi ng 1990s at halos lipas na. Malamang na hindi ka makakatagpo ng v2 sa labas ng lumang enterprise infrastructure.

UUID v3 — Namespace Hash gamit MD5

Ang v3 ay gumagawa ng deterministikong UUID sa pamamagitan ng pag-hash ng namespace UUID at pangalan nang magkasama gamit ang MD5. Sa parehong namespace at pangalan, ang v3 ay laging gumagawa ng parehong UUID. Kapaki-pakinabang ito kapag kailangan mo ng stable, reproducible na identifier para sa isang kilalang value — ngunit ang MD5 ay cryptographically broken na. Gamitin ang v5 para sa lahat ng bagong gawain.

UUID v4 — Purong Random (Default para sa Pangkalahatang Layunin)

Ang v4 ay ginagawa mula sa 122 bits ng cryptographically secure na random data. Walang timestamp, walang MAC address, walang metadata — randomness lamang. Mga kalamangan nito:

• Madaling gawin sa bawat wika at platform
• Private — walang inilalantad tungkol sa kung kailan o saan ito ginawa
• Ligtas para sa token, session ID, at pampublikong identifier
• Universally supported sa bawat database, framework, at API

Ang UUID v4 ang tamang pagpipilian para sa 95% ng mga kaso ng paggamit. Kung kailangan mo lang ng natatanging ID at hindi bottleneck ang database index performance, gamitin ang v4.

UUID v5 — Namespace Hash gamit SHA-1

Ang v5 ay gumagana nang katulad ng v3 ngunit gumagamit ng SHA-1 sa halip na MD5. Sa parehong namespace at pangalan, lagi itong gumagawa ng parehong UUID. Gamitin ang v5 kapag kailangan mong gumawa ng reproducible, collision-resistant na identifier mula sa kilalang input — halimbawa, stable na UUID para sa isang URL, email address, o product SKU, na nagmula sa isang kilalang namespace.

UUID v6 — Na-reorder na Timestamp

Ang v6 ay reorganized na variant ng v1 na naglalagay ng timestamp sa big-endian order para ang mga UUID v6 ay ma-sort nang kronolohiko. Umiiral ito pangunahin bilang migration bridge mula v1 patungong v7 para sa mga sistema na gumagamit na ng v1. Para sa mga bagong sistema, direktang pumunta sa v7.

UUID v7 — Modernong Default para sa Database Primary Key

Ang UUID v7 ay pormal na ginawa sa RFC 9562 (2024) at mabilis na nagiging inirerekomendang default para sa mga bagong proyekto na gumagamit ng UUID bilang database primary key.

Nagsasama ang v7 ng 48-bit Unix timestamp sa millisecond sa pinaka-significant na bits, sinusundan ng random data. Dahil nasa harap ang timestamp, ang mga UUID v7 ay lexicographically sortable — nag-aayos ang mga ito sa creation order bilang parehong string at binary value.

019047b4-1c5e-7000-b703-24c3f6a5c849
│           │         │
└─ 48-bit Unix timestamp (ms)  └─ Mga random bit

Ang sorting property na ito ay may malaking epekto sa database performance.

UUID v4 vs UUID v7 — Alin ang Dapat Gamitin?

	UUID v4	UUID v7
Paglikha	Purong random	Timestamp + random
Maaaring uriin	Hindi	Oo (ayon sa creation time)
Naka-embed na timestamp	Hindi	Oo (48-bit ms precision)
Privacy	Mataas — walang inilalantad	Naglalantad ng creation time
DB index performance	Mahina sa malaking scale	Napakagaling
Browser support	crypto.randomUUID()	Kailangan ng manual na pagbuo
RFC	RFC 9562	RFC 9562

Gamitin ang UUID v4 kapag:

• Kailangan mo ng pampublikong token, session ID, o opaque na reference
• Mahalaga ang pagtatago ng creation time (security token, invite link)
• Hindi bottleneck ang database index performance

Gamitin ang UUID v7 kapag:

• Ang UUID ay magiging database primary key
• Gusto mong natural na ma-sort ang mga record ayon sa creation time nang walang hiwalay na created_at column
• Nagtatayo ka ng distributed system na gumagawa ng ID sa maraming node

UUID bilang Database Primary Key — Gabay sa Performance

Dito pinaka-malinaw na makikita ang teknikal na epekto ng pagpili ng UUID version.

Bakit Nagpapabagal ng Database Performance ang UUID v4

Gumagamit ang mga relational database tulad ng MySQL InnoDB at PostgreSQL ng B-tree index para sa primary key. Na-optimize ang B-tree para sa sequential insertion — ang bawat bagong row ay pumupunta malapit sa dulo ng huling nakasulat na pahina. Ang pattern na ito ay mahusay na nagpupuno ng pahina at nagpapababa ng disk I/O.

Ang UUID v4 ay random. Ang bawat bagong UUID ay inilalagay sa random na posisyon sa B-tree. Nagdudulot ito ng:

• Page split: Kailangang madalas na hatiin ng engine ang mga puno na pahina para sa random na insertion, na nagpapabago ng index
• Cache eviction: Ang random na access ay nangangahulugang kailangang patuloy na mag-load ng engine ng mga lumang pahina mula sa disk sa halip na magtrabaho sa “mainit” na dulo ng puno
• Nasayang na espasyo: Ang paggamit ng pahina ay maaaring bumaba sa 50% dahil sa fragmentation
• Mas mabagal na range query: Walang temporal locality — ang mga row na malapit na nagawa ay nakakalat sa buong index

Sa mababang bilang ng row, hindi ito kapansin-pansin. Sa sampung milyun-milyong row na may patuloy na mataas na write throughput, ang mga random na UUID primary key ay nagdudulot ng kapansin-pansing pagbaba ng performance.

Bakit Nireresulta ng UUID v7 ang Problemang Ito

Ang timestamp prefix ng v7 ay nangangahulugang ang bawat bagong UUID ay mas malaki kaysa sa lahat ng nabuong UUID bago nito (sa loob ng parehong millisecond, ang sequence counter o random bits ang nagpapanatili ng order). Ang B-tree ay tumatanggap ng mga insertion sa pinakakanang leaf lamang — ang parehong mahusay na pattern tulad ng auto-incrementing integer.

Nagpapakita ang mga benchmark sa malaking scale ng hanggang 400% na mas mabilis na write performance sa mga ordered UUID kumpara sa random v4, na may katumbas na mas mababang index fragmentation.

Binary Storage

Kahit gumagamit ng v4 o v7, ang pag-iimbak ng UUID bilang CHAR(36) string ay nagsasayang ng espasyo. Gamitin ang BINARY(16) o ang native UUID type ng iyong database:

• PostgreSQL: Built-in na uri ng UUID (naka-imbak nang panloob bilang 16 bytes)
• MySQL: BINARY(16) o ang mga function na UUID_TO_BIN() / BIN_TO_UUID() na may swap_flag=1 argument para ilipat ang timestamp bits sa harap
• MongoDB: Native UUID BSON subtype

Paano Gumawa ng UUID sa Code

JavaScript / Node.js

// Node.js 14.17+ at lahat ng modernong browser
const id = crypto.randomUUID(); // UUID v4

// Node.js 19+ / third-party library para sa v7
import { v7 as uuidv7 } from 'uuid';
const id = uuidv7();

Python

import uuid

id_v4 = str(uuid.uuid4())
id_v5 = str(uuid.uuid5(uuid.NAMESPACE_URL, 'https://example.com'))

Java

import java.util.UUID;

UUID id = UUID.randomUUID(); // v4
String idStr = id.toString();

C# / .NET

Guid id = Guid.NewGuid(); // v4
string idStr = id.ToString(); // "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

PostgreSQL

-- Native UUID v4 (PostgreSQL 13+)
SELECT gen_random_uuid();

-- UUID v7 sa pamamagitan ng pg_uuidv7 extension
SELECT uuid_generate_v7();

Go

import "github.com/google/uuid"

id := uuid.New()         // v4
idStr := id.String()

Sanggunian sa Format at Istruktura ng UUID

550e8400 - e29b - 41d4 - a716 - 446655440000
│          │      │      │      │
│          │      │      │      └── Node (48 bits)
│          │      │      └───────── Clock sequence (14 bits) + Variant (2 bits)
│          │      └──────────────── Version (4 bits) + Time mid (12 bits)
│          └─────────────────────── Time mid (16 bits)
└────────────────────────────────── Time low (32 bits)

Version digit (M): Ang ika-13 na character. 4 = random, 7 = may timestamp prefix.

Variant bits (N): Ang ika-17 na character. Laging 8, 9, a, o b para sa RFC 9562 UUID — ang dalawang bit na ito ang nagtatukoy na sumusunod ang UUID sa RFC 9562 layout.

Mga Espesyal na UUID

• Nil UUID: 00000000-0000-0000-0000-000000000000 — lahat ng bit ay zero, ginagamit bilang null/sentinel na value
• Max UUID: ffffffff-ffff-ffff-ffff-ffffffffffff — lahat ng bit ay isa, tinutukoy ito ng RFC 9562 bilang valid na espesyal na kaso

Mga Format ng Output

Ang parehong UUID value ay maaaring irepresenta sa iba’t ibang paraan depende sa kailangan ng consuming system:

Format	Halimbawa
Standard (may hyphen)	550e8400-e29b-41d4-a716-446655440000
Compact (walang hyphen)	550e8400e29b41d4a716446655440000
May braces	{550e8400-e29b-41d4-a716-446655440000}
Uppercase	550E8400-E29B-41D4-A716-446655440000
URN	urn:uuid:550e8400-e29b-41d4-a716-446655440000

Mga Tunay na Kaso ng Paggamit

1. Database Primary Key

Nagbibigay-daan ang UUID sa mga distributed system na gumawa ng primary key nang walang sentral na sequence generator. Hindi tulad ng auto-incrementing integer, ang mga UUID primary key ay hindi nagpapakita ng kabuuang bilang ng row o insertion order sa mga external na caller. Gamitin ang UUID v7 para sa mga bagong table kapag ikaw ang kumokontrol sa schema.

2. ID ng Distributed System — Walang Kinakailangang Koordinasyon

Sa microservices architecture, ang maraming serbisyo na gumagawa ng mga record nang independyente ay hindi maaaring mag-share ng auto-increment sequence nang walang coordinating service. Ang bawat node ay gumagawa ng sarili nitong UUID at nag-iinsert nang walang panganib ng collision — kahit hindi pa nagkakausap ang mga serbisyo.

3. Idempotency Key para sa Bayad at API

Ang mga payment processor tulad ng Stripe at mga API na sumusuporta sa idempotency ay nangangailangan ng natatanging key sa bawat request. Ang pagpapadala ng parehong idempotency key nang dalawang beses ay nagbabalik ng cached na resulta sa halip na muling isagawa ang operasyon. Ang UUID ang standard na format para sa mga key na ito.

4. Collision-Safe na Pagpapangalan ng File at Asset

Ang mga file na pinangalanan ng UUID ay hindi maaaring magbangga kahit ilang user ang nag-uupload nang sabay-sabay. Ang mga object na may UUID na pangalan sa S3, GCS, o kahit anong blob store ay ligtas na likhain nang parallel nang walang locking strategy.

5. Session at Token Identifier

Malawak na ginagamit ang UUID bilang session ID, password reset token, email verification link, at invite code. Gamitin ang v4 para sa mga kasong ito — ang opaque na randomness ay hindi nagpapakita ng anumang metadata tungkol sa kung kailan inilabas ang token.

6. Deterministikong ID mula sa Kilalang Input (v5)

Kapag kailangan mo ng stable, reproducible na UUID para sa isang partikular na input — canonical UUID para sa isang URL, product SKU, o user email — gawin ito gamit ang UUID v5 na may fixed namespace. Ang parehong input ay laging gumagawa ng parehong UUID, na ligtas para gumawa ng ID nang hindi na kailangang hanapin ito sa database.

Paano Gamitin ang UUID Generator na Ito

1. Ilagay ang dami ng UUID na kailangan mo (1 hanggang 1000).
2. Piliin ang output format: standard na may hyphen, compact, may braces, o uppercase.
3. I-click ang Gumawa ng UUID, o i-enable ang Auto Generate para lumikha ng bagong ID sa bawat page load.
4. I-click ang Kopyahin para kopyahin ang lahat ng ID sa clipboard, o I-download para i-save ang mga ito bilang .txt file.
5. Para i-normalize ang mga existing UUID, i-paste ang mga ito sa pangalawang panel. Vina-validate ng tool ang bawat value at kino-convert sa standard na lowercase hyphenated format.

Data bilang Parameter

I-pre-fill ang bilang ng generator sa pamamagitan ng URL:

https://www.uprek.com/tl/tools/tagagawa-ng-uuid-guid?count=25

I-pre-fill ang normalizer panel ng isang existing UUID string:

https://www.uprek.com/tl/tools/tagagawa-ng-uuid-guid?input=123e4567e89b42d3a456426614174000

Hindi Kailanman Umaalis ang Iyong Data sa Browser

Kapag ginagamit mo ang tool na ito sa propesyonal na konteksto — pagpuno ng database seed, paggawa ng ID para sa panloob na tooling, o pag-normalize ng UUID mula sa production export — hindi mo dapat kailangang ipadala ang data na iyon sa isang third-party server.

Sa UPREK, malinaw ang aming arkitektura: ang iyong data ay sa iyo. Hindi namin ito gusto, hindi namin ito kinokolekta, at hindi namin ito makikita.

• 100% Lokal na Paglikha: Ang mga UUID ay nilikha gamit ang native browser API na crypto.randomUUID(), o crypto.getRandomValues() bilang fallback — parehong tumatakbo nang buo sa loob ng JavaScript engine ng iyong browser.
• Walang Upload sa Server: Walang UUID na ginawa mo o ni-paste sa tool na ito ang kailanman ipinapadala sa aming mga server.
• Walang Log o Storage: Hindi namin ino-log, iniiimbak, o sinusuri ang anumang identifier o input text na pinagtatrabahuhan mo.
• Agarang Pagtanggal: Lahat ng nabuong data ay umiiral lamang sa aktibong memorya ng iyong browser. Isara ang tab at wala na ito.

Mga Madalas Itanong

Talaan ng mga Pagbabago