Jana UUID dan GUID dengan serta-merta: Integrasikan alat ini ke dalam aliran kerja anda untuk mencipta pengecam yang selamat secara kriptografi dan bebas perlanggaran untuk pangkalan data, sistem teragih, payload API, data ujian, dan penamaan fail — terus dalam pelayar, tanpa sebarang hubungan dengan pelayan.

Apakah UUID?

UUID (Universally Unique Identifier) ialah label 128-bit yang distandardkan oleh RFC 9562 (diterbitkan April 2024, menggantikan RFC 4122 dari tahun 2005). Sifat utamanya ialah UUID boleh dijana secara bebas pada mana-mana mesin, bila-bila masa, tanpa pihak berkuasa penyelarasan pusat — dan masih kekal unik secara global untuk semua tujuan praktikal.

Perwakilan teks standardnya ialah 32 digit heksadesimal yang dibahagikan kepada lima kumpulan oleh tanda sempang:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Di sini M mengekod versi (algoritma yang digunakan untuk menjana UUID) dan N mengekod varian (piawaian susun atur bit — sentiasa 8, 9, a, atau b untuk UUID RFC 9562).

Contoh konkrit UUID v4:

550e8400-e29b-41d4-a716-446655440000

Itu ialah 32 aksara hex = 128 bit data. Kedudukan tanda sempang semata-mata bersifat estetik dan tidak membawa maklumat — ia dibuang apabila UUID disimpan dalam bentuk binari atau padat.

Betapa Uniknya “Unik Secara Universal”?

UUID v4 menggunakan 122 bit kerawakan (6 bit dikhaskan untuk metadata versi dan varian). Untuk memahami risiko perlanggaran: jika anda menjana 1 bilion UUID sesaat, anda memerlukan masa sekitar 85 tahun untuk mencapai kebarangkalian 50% berlakunya satu perlanggaran. Untuk mana-mana sistem sebenar, kebarangkalian perlanggaran pada dasarnya sifar.

UUID vs GUID — Adakah Keduanya Sama?

Ya, untuk tujuan pembangunan moden, UUID dan GUID adalah perkara yang sama.

GUID (Globally Unique Identifier) ialah istilah Microsoft yang diperkenalkan bersama COM/DCOM pada tahun 1990-an. GUID mengikuti susun atur RFC 9562 dan saiz 128-bit yang sama. Perbezaan sejarahnya hanyalah cara Microsoft menyiri beberapa medan dalam format binari — tetapi dalam bentuk rentetan (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx), UUID dan GUID adalah identik dan boleh digunakan secara bergantian.

Dalam amalan: ekosistem Windows dan .NET cenderung menyebut GUID, manakala Linux, macOS, web API, dan pangkalan data cenderung menyebut UUID. Kedua-duanya merujuk kepada piawaian yang sama.

Penjelasan Semua Versi UUID

Nombor versi tidak bermaksud “lebih baharu adalah lebih baik.” Ia mengenal pasti algoritma yang digunakan untuk mencipta UUID. Setiap versi menyelesaikan masalah yang berbeza.

Versi	Algoritma	Boleh Disusun	Kes Penggunaan
v1	Cap masa + alamat MAC	Sebahagian	Sistem lama sahaja
v2	DCE Security (POSIX UID/GID)	Tidak	Lapuk, elakkan
v3	Hash namespace dengan MD5	Tidak	ID deterministik (MD5 rosak, guna v5)
v4	Rawak	Tidak	Tujuan umum — pilihan lalai selamat
v5	Hash namespace dengan SHA-1	Tidak	ID deterministik dari nama + namespace
v6	Cap masa disusun semula + rawak	Ya	Laluan migrasi dari v1
v7	Cap masa Unix + rawak	Ya	Kunci utama pangkalan data, sistem moden

UUID v1 — Cap Masa dan Alamat MAC

v1 mengekod cap masa semasa (dalam selang 100 nanosaat sejak Oktober 1582) berserta alamat MAC mesin penjana. Ini memberikan pengurutan masa separa tetapi membocorkan identiti mesin dan masa penciptaan dalam UUID itu sendiri. Elakkan v1 dalam mana-mana API awam atau sistem yang mementingkan privasi.

UUID v2 — DCE Security

v2 ialah varian v1 yang menggantikan sebahagian cap masa dengan POSIX UID, GID, atau pengecam domain. Ia direka untuk Distributed Computing Environments (DCE) pada awal tahun 1990-an dan kini lapuk. Anda kecil kemungkinannya menemui v2 di luar infrastruktur enterprise lama.

UUID v3 — Hash Namespace dengan MD5

v3 menghasilkan UUID deterministik dengan meng-hash UUID namespace dan nama bersama menggunakan MD5. Dengan namespace dan nama yang sama, v3 sentiasa menghasilkan UUID yang sama. Ini berguna apabila anda memerlukan pengecam stabil yang boleh dihasilkan semula untuk nilai yang diketahui — tetapi MD5 sudah rosak secara kriptografi. Gunakan v5 sebagai gantinya untuk semua kerja baru.

UUID v4 — Rawak Sepenuhnya (Lalai Tujuan Umum)

v4 dijana daripada 122 bit data rawak yang selamat secara kriptografi. Tiada cap masa, tiada alamat MAC, tiada metadata — hanya kerawakan semata-mata. Kelebihannya:

• Mudah dijana dalam setiap bahasa dan platform
• Peribadi — tidak mendedahkan bila atau di mana ia dicipta
• Selamat untuk token, session ID, dan pengecam awam
• Disokong secara universal dalam setiap pangkalan data, framework, dan API

UUID v4 adalah pilihan yang tepat untuk 95% kes penggunaan. Jika anda hanya memerlukan ID yang unik dan prestasi indeks pangkalan data bukan isu, gunakan v4.

UUID v5 — Hash Namespace dengan SHA-1

v5 berfungsi sama seperti v3 tetapi menggunakan SHA-1 dan bukannya MD5. Dengan namespace dan nama yang sama, ia sentiasa menghasilkan UUID yang sama. Gunakan v5 apabila anda perlu menjana pengecam yang boleh dihasilkan semula dan tahan perlanggaran daripada input yang diketahui — contohnya, UUID stabil untuk URL, alamat e-mel, atau SKU produk tertentu.

UUID v6 — Cap Masa Disusun Semula

v6 ialah varian v1 yang disusun semula yang meletakkan cap masa dalam susunan big-endian supaya UUID v6 terurut secara kronologi. Ia wujud terutamanya sebagai jambatan migrasi dari v1 ke v7 untuk sistem yang sudah menggunakan v1. Untuk sistem baharu, terus gunakan v7.

UUID v7 — Lalai Moden untuk Kunci Utama Pangkalan Data

UUID v7 diformalkan dalam RFC 9562 (2024) dan dengan pantas menjadi lalai yang disyorkan untuk projek baharu yang menggunakan UUID sebagai kunci utama pangkalan data.

v7 menyematkan cap masa Unix 48-bit dalam milisaat pada bit paling bererti, diikuti oleh data rawak. Kerana cap masa berada di hadapan, UUID v7 boleh disusun secara leksikografi — kedua-duanya terurut mengikut masa penciptaan sama ada sebagai rentetan mahupun nilai binari.

019047b4-1c5e-7000-b703-24c3f6a5c849
│           │         │
└─ Cap masa Unix 48-bit (ms)  └─ Bit rawak

Sifat pengurutan ini memberi impak besar kepada prestasi pangkalan data.

UUID v4 vs UUID v7 — Yang Mana Perlu Digunakan?

	UUID v4	UUID v7
Penjanaan	Rawak sepenuhnya	Cap masa + rawak
Boleh disusun	Tidak	Ya (mengikut masa penciptaan)
Cap masa tertanam	Tidak	Ya (ketepatan 48-bit ms)
Privasi	Tinggi — tidak mendedahkan apa-apa	Membocorkan masa penciptaan
Prestasi indeks DB	Lemah pada skala besar	Sangat baik
Sokongan pelayar	crypto.randomUUID()	Perlu dibina secara manual
RFC	RFC 9562	RFC 9562

Gunakan UUID v4 apabila:

• Anda memerlukan token awam, session ID, atau rujukan yang tidak telus
• Menyembunyikan masa penciptaan adalah penting (token keselamatan, pautan jemputan)
• Prestasi indeks pangkalan data bukan kesesakan

Gunakan UUID v7 apabila:

• UUID akan menjadi kunci utama pangkalan data
• Anda mahu rekod terurut secara semula jadi mengikut masa penciptaan tanpa lajur created_at berasingan
• Anda membina sistem teragih yang menjana ID merentasi banyak nod

UUID sebagai Kunci Utama Pangkalan Data — Panduan Prestasi

Di sinilah pilihan versi UUID memberi impak teknikal yang paling ketara.

Mengapa UUID v4 Melemahkan Prestasi Pangkalan Data

Pangkalan data hubungan seperti MySQL InnoDB dan PostgreSQL menggunakan indeks B-tree untuk kunci utama. B-tree dioptimumkan untuk penyisipan berjujukan — setiap baris baharu masuk berhampiran penghujung halaman terakhir yang ditulis. Corak ini mengisi halaman dengan cekap dan meminimumkan I/O cakera.

UUID v4 bersifat rawak. Setiap UUID baharu disisipkan ke kedudukan rawak dalam B-tree. Ini menyebabkan:

• Pemisahan halaman: Enjin terpaksa kerap memisahkan halaman penuh untuk penyisipan rawak, yang memfragmentasikan indeks
• Penyingkiran cache: Akses rawak bermakna enjin mesti terus memuatkan halaman lama dari cakera berbanding bekerja di hujung “panas” pokok
• Pembaziran ruang: Penggunaan halaman boleh jatuh kepada 50% akibat fragmentasi
• Pertanyaan julat lebih perlahan: Tiada lokaliti temporal — baris yang dicipta hampir bersamaan tersebar merentas keseluruhan indeks

Pada bilangan baris yang rendah, ini tidak ketara. Pada puluhan juta baris dengan daya pemprosesan tulis yang tinggi, kunci utama UUID rawak menyebabkan kemerosotan prestasi yang ketara.

Mengapa UUID v7 Menyelesaikan Masalah Ini

Awalan cap masa v7 bermakna setiap UUID baharu lebih besar daripada semua UUID yang dijana sebelumnya (dalam milisaat yang sama, penghitung jujukan atau bit rawak mengekalkan susunan). B-tree menerima penyisipan hanya di daun paling kanan — corak cekap yang sama seperti integer auto-increment.

Penanda aras pada skala besar menunjukkan prestasi tulis sehingga 400% lebih pantas dengan UUID berurutan berbanding v4 rawak, dengan fragmentasi indeks yang jauh lebih rendah.

Penyimpanan Binari

Sama ada menggunakan v4 atau v7, menyimpan UUID sebagai rentetan CHAR(36) membazirkan ruang. Gunakan BINARY(16) atau jenis UUID natif pangkalan data anda:

• PostgreSQL: Jenis UUID terbina dalam (disimpan secara dalaman sebagai 16 bait)
• MySQL: BINARY(16) atau fungsi UUID_TO_BIN() / BIN_TO_UUID() dengan argumen swap_flag=1 untuk memindahkan bit cap masa ke hadapan
• MongoDB: BSON subtype UUID natif

Cara Menjana UUID dalam Kod

JavaScript / Node.js

// Node.js 14.17+ dan semua pelayar moden
const id = crypto.randomUUID(); // UUID v4

// Node.js 19+ / library pihak ketiga untuk 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

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

-- UUID v7 melalui sambungan pg_uuidv7
SELECT uuid_generate_v7();

Go

import "github.com/google/uuid"

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

Rujukan Format dan Struktur UUID

550e8400 - e29b - 41d4 - a716 - 446655440000
│          │      │      │      │
│          │      │      │      └── Nod (48 bit)
│          │      │      └───────── Jujukan jam (14 bit) + Varian (2 bit)
│          │      └──────────────── Versi (4 bit) + Time mid (12 bit)
│          └─────────────────────── Time mid (16 bit)
└────────────────────────────────── Time low (32 bit)

Digit versi (M): Aksara ke-13. 4 = rawak, 7 = berawalan cap masa.

Bit varian (N): Aksara ke-17. Sentiasa 8, 9, a, atau b untuk UUID RFC 9562 — dua bit ini mengenal pasti UUID sebagai mengikuti susun atur RFC 9562.

UUID Khas

• UUID nil: 00000000-0000-0000-0000-000000000000 — semua bit sifar, digunakan sebagai nilai null/sentinel
• UUID max: ffffffff-ffff-ffff-ffff-ffffffffffff — semua bit satu, RFC 9562 mendefinisikan ini sebagai UUID kes khas yang sah

Format Output

Nilai UUID yang sama boleh diwakili dengan beberapa cara bergantung pada keperluan sistem:

Format	Contoh
Standard (dengan tanda sempang)	550e8400-e29b-41d4-a716-446655440000
Padat (tanpa tanda sempang)	550e8400e29b41d4a716446655440000
Pendakap	{550e8400-e29b-41d4-a716-446655440000}
Huruf besar	550E8400-E29B-41D4-A716-446655440000
URN	urn:uuid:550e8400-e29b-41d4-a716-446655440000

Kes Penggunaan di Dunia Sebenar

1. Kunci Utama Pangkalan Data

UUID membolehkan sistem teragih mencipta kunci utama tanpa penjana urutan berpusat. Tidak seperti integer auto-increment, kunci utama UUID tidak mendedahkan jumlah baris keseluruhan atau susunan penyisipan kepada pemanggil luar. Gunakan UUID v7 untuk jadual baharu apabila anda mengawal schema.

2. ID Sistem Teragih — Tanpa Penyelarasan

Dalam seni bina microservices, beberapa perkhidmatan yang mencipta rekod secara bebas tidak boleh berkongsi urutan auto-increment tanpa perkhidmatan penyelaras. Setiap nod menjana UUID sendiri dan menyisipkan tanpa risiko perlanggaran — walaupun perkhidmatan-perkhidmatan tersebut tidak pernah berkomunikasi antara satu sama lain.

3. Kunci Idempotency untuk Pembayaran dan API

Pemproses pembayaran seperti Stripe dan API yang menyokong idempotency memerlukan kunci unik bagi setiap permintaan. Menghantar kunci idempotency yang sama dua kali mengembalikan hasil yang di-cache berbanding melaksanakan operasi semula. UUID ialah format standard untuk kunci-kunci ini.

4. Penamaan Fail dan Aset Bebas Perlanggaran

Fail yang dinamakan dengan UUID tidak boleh berlanggar tidak kira berapa ramai pengguna memuat naik secara serentak. Objek bernama UUID dalam S3, GCS, atau mana-mana blob store selamat dicipta secara selari tanpa strategi penguncian.

5. Pengecam Session dan Token

UUID banyak digunakan sebagai session ID, token tetapan semula kata laluan, pautan pengesahan e-mel, dan kod jemputan. Gunakan v4 untuk kes-kes ini — kerawakan yang tidak telus tidak mendedahkan metadata tentang bila token dikeluarkan.

6. ID Deterministik daripada Input yang Diketahui (v5)

Apabila anda memerlukan UUID stabil yang boleh dihasilkan semula untuk input tertentu — UUID kanonik untuk URL, SKU produk, atau e-mel pengguna — jana dengan UUID v5 menggunakan namespace tetap. Input yang sama sentiasa menghasilkan UUID yang sama, menjadikannya selamat untuk menjana ID tanpa perlu mencarinya dalam pangkalan data terlebih dahulu.

Cara Menggunakan Penjana UUID Ini

1. Masukkan bilangan UUID yang anda perlukan (1 hingga 1000).
2. Pilih format output: standard bertanda sempang, padat, pendakap, atau huruf besar.
3. Klik Jana UUID, atau aktifkan Jana Automatik untuk mencipta ID baharu setiap kali halaman dimuatkan.
4. Klik Salin untuk menyalin semua ID ke papan klip, atau Muat Turun untuk menyimpannya sebagai fail .txt.
5. Untuk menormalkan UUID sedia ada, tampal ke panel kedua. Alat ini mengesahkan setiap nilai dan menukarnya ke format standard huruf kecil bertanda sempang.

Data sebagai Parameter

Isikan bilangan penjana lebih awal melalui URL:

https://www.uprek.com/ms/tools/penjana-uuid-guid?count=25

Isikan panel penormalkan dengan rentetan UUID sedia ada:

https://www.uprek.com/ms/tools/penjana-uuid-guid?input=123e4567e89b42d3a456426614174000

Data Anda Tidak Pernah Meninggalkan Pelayar

Apabila anda menggunakan alat ini dalam konteks profesional — mengisi pangkalan data seed, menjana ID untuk alatan dalaman, atau menormalkan UUID daripada eksport pengeluaran — anda tidak perlu menghantar data tersebut ke pelayan pihak ketiga.

Di UPREK, seni bina kami adalah tegas: data anda adalah milik anda. Kami tidak mahukan ia, tidak mengumpulkannya, dan tidak boleh melihatnya.

• Penjanaan 100% Tempatan: UUID dijana menggunakan API pelayar natif crypto.randomUUID(), atau crypto.getRandomValues() sebagai sandaran — kedua-duanya berjalan sepenuhnya dalam enjin JavaScript pelayar anda.
• Tanpa Muat Naik ke Pelayan: Tiada UUID yang anda jana atau tampal ke alat ini pernah dihantar ke pelayan kami.
• Tanpa Log atau Penyimpanan: Kami tidak mencatat, menyimpan, atau memeriksa sebarang pengecam atau teks input yang anda kerjakan.
• Pemadaman Serta-merta: Semua data yang dijana hanya wujud dalam ingatan aktif pelayar anda. Tutup tab dan ia hilang.

Soalan Lazim

Log Perubahan