Generator UUID v4

Generator UUID v4: 122 Bit Acak Murni untuk Identifikasi Universal

Halaman ini menghasilkan UUID versi 4—pengenal acak sepanjang 36 karakter dalam format kanonis 8‑4‑4‑4‑12. Tidak seperti pengenal berbasis waktu, UUID v4 hanya mengandalkan 122 bit entropi murni; enam bit sisanya sudah ditetapkan untuk identifikasi versi dan varian. Setiap kali opsi diubah—jumlah (1 sampai 100), huruf besar/kecil, atau penggunaan tanda hubung—seluruh daftar langsung diperbarui. Tidak ada data yang dikirim ke server; semua terjadi di peramban Anda menggunakan crypto.randomUUID atau API sejenis.

---

Anatomi UUID v4: Standar RFC 4122

UUID v4 dirancang dalam tiga lapisan bit. Empat bit pertama dari 128 bit total menunjukkan versi (nilai 0100, atau angka 4). Dua bit berikutnya di posisi tertentu menandai varian (10xxxx, atau varian 1 dalam RFC 4122). Sisa 122 bit adalah data acak. Representasi heksadesimalnya menghasilkan 36 karakter: 8 heksa, tanda hubung, 4 heksa, tanda hubung, 4 heksa, tanda hubung, 12 heksa. Contoh: 550e8400-e29b-41d4-a716-446655440000.

Lembar fakta menegaskan bahwa bit versi dan varian bersifat tetap, sehingga pengacak berfokus hanya pada 122 bit. Artinya, setiap UUID v4 yang sah pasti memiliki digit ke-13 sama dengan "4" (versi) dan digit ke-17 berupa "8", "9", "a", atau "b" (varian). Tanda hubung bukan bagian dari nilai biner—hanya pemisah visual. Jika tombol Include hyphens dimatikan, string menjadi 32 karakter heksa tanpa pemisah. Opsi Uppercase hanya mengubah tampilan huruf a–f menjadi A–F; nilai biner tidak berubah.

---

Keacakan dan Kemungkinan Tabrakan

Dengan 122 bit acak, total kemungkinan UUID v4 mencapai 2^122 ≈ 5,3 × 10^36. Kemungkinan tabrakan—dua UUID identik dihasilkan—sangat kecil. Untuk 1 miliar UUID, peluang setidaknya satu tabrakan sekitar 10^-18, jauh lebih kecil dari peluang meteor jatuh ke rumah Anda. Dalam praktik, pengguna yang menghasilkan 100 UUID per detik selama satu miliar tahun baru mendekati risiko signifikan.

Lembar fakta menekankan bahwa UUID v4 tidak membawa informasi waktu. Setiap nilai sepenuhnya independen terhadap urutan pembuatan. Ini menjadi kritis saat digunakan sebagai kunci utama di basis data relasional.

---

Dampak pada Pengindeksan Basis Data: Fragmentasi B‑Tree

Sistem manajemen basis data seperti PostgreSQL, MySQL, atau Oracle secara default menyimpan indeks kunci utama dalam struktur B‑tree. B‑tree mengandalkan kedekatan nilai untuk meminimalkan jumlah halaman yang perlu ditulis ulang saat data baru ditambahkan. Jika kunci utama berurutan (misal: integer auto‑increment, UUID v7, ULID), baris baru selalu ditambahkan di ujung kanan indeks. Sebaliknya, UUID v4 yang acak menyebar secara merata di seluruh ruang kunci. Setiap kali baris baru disisipkan, halaman indeks mana pun bisa menerima entri baru, memaksa basis data untuk sering membelah halaman dan menulis ulang data.

Akibatnya:

• Performa tulis menurun — operasi INSERT membutuhkan lebih banyak I/O.
• Fragmentasi indeks meningkat — ukuran fisik indeks membengkak.
• Cache hit ratio berkurang — halaman yang sering diakses berubah secara acak.

Lembar fakta menyebutkan bahwa halaman ini memperingatkan pengguna tentang fragmentasi indeks B‑tree. Inilah alasan utama mengapa pengenal berbasis waktu (UUID v7, ULID) atau integer berurutan lebih disukai untuk aplikasi yang membutuhkan performa tulis tinggi. Namun, untuk sistem terdistribusi tanpa koordinasi pusat, UUID v4 tetap menjadi pilihan standar—tidak ada titik gagal tunggal dalam pembuatan ID.

---

Perbandingan dengan UUID v7 dan ULID

UUID v7 menggunakan 48 bit untuk stempel waktu milidetik (hingga tahun 10889 M) dan 74 bit sisanya untuk keacakan. Ini memberikan jaminan urutan global (selama jam sistem tidak mundur). ULID menggabungkan 40 bit timestamp (hingga tahun 10889 M juga) dan 80 bit acak, direpresentasikan dalam 26 karakter Base32 yang case‑insensitive.

Lembar fakta mencatat bahwa halaman ini juga menyediakan opsi format UUID v7, ULID, dan NanoID dalam dropdown. Setiap format memiliki aturan tersendiri. Untuk UUID v4, toggles huruf besar dan tanda hubung bersifat spesifik karena format heksa dapat diubah tanpa kehilangan makna, tidak seperti Base32 ULID yang huruf besar/kecil tidak relevan.

---

Kasus Penggunaan yang Tepat untuk UUID v4

1. Token API dan ID Sesi (Keamanan) — Sifat acak mencegah enumerasi. Penyerang tidak bisa menebak token berikutnya hanya dengan melihat pola waktu. Lembar fakta menyebut insinyur keamanan membutuhkan ID yang tidak dapat ditebak.

2. Sistem Terdistribusi Tanpa Koordinasi — Setiap node dapat menghasilkan UUID v4 secara independen tanpa perlu memeriksa basis data pusat. Ini penting untuk aplikasi offline‑first atau edge computing.

3. Pengujian dan Data Buatan — Penguji dan pembuat data memerlukan kunci unik dalam jumlah besar yang realistis. UUID v4 mudah dihasilkan massal (1–100 per generasi di halaman ini) dan tidak memerlukan urutan.

4. Identifikasi Objek dalam Event Log — Ketika urutan waktu tidak penting tetapi keunikan absolut diperlukan, UUID v4 memberikan solusi sederhana.

5. Persyaratan Regulasi (Anonimitas) — ID yang tidak mengandung stempel waktu membantu memisahkan identitas dari kronologi.

---

Penyesuaian Format: Kapan dan Mengapa

• Huruf besar (Uppercase on) — Berguna saat UUID ditampilkan di antarmuka pengguna yang membutuhkan keterbacaan tinggi, misalnya nomor seri perangkat keras. Beberapa sistem penerima (misal, parser case‑sensitive) mengharuskan format seragam. Namun, perhatikan bahwa UUID adalah case‑insensitive secara standar; a dan A sama secara semantik.

• Tanpa tanda hubung — Saat UUID perlu dimasukkan ke dalam URL, bilah alamat, atau bidang yang membatasi karakter (misal, kode promo 32 karakter). Tanda hubung dihilangkan untuk menghemat ruang tanpa kehilangan informasi. ID menjadi 32 karakter heksa — sama seperti representasi biner tanpa pemisah.

Kedua opsi hanya memengaruhi tampilan, bukan nilai. Bit acak tidak berubah. Tombol Uppercase dan Include hyphens segera memicu regenerasi, tetapi sebenarnya hanya memformat ulang string yang sama.

---

FAQ: Pertanyaan Umum tentang UUID v4

1. Apakah UUID v4 yang dihasilkan oleh halaman ini benar‑benar acak? Ya. Peramban Anda menggunakan crypto.getRandomValues atau crypto.randomUUID. Keduanya berasal dari sumber entropi sistem operasi (perangkat keras atau sistem file). Tidak ada campur tangan server atau generator semu biasa.

2. Bisakah saya menghasilkan lebih dari 100 UUID sekaligus? Tidak. Batas maksimal adalah 100 per klik. Jika Anda membutuhkan lebih banyak, cukup ulangi generasi. Halaman ini dirancang untuk penggunaan cepat, bukan produksi massal jutaan ID.

3. Mengapa UUID v4 tidak cocok untuk indeks basis data berperforma tinggi? Karena nilai acak tidak memiliki lokalitas temporal. Setiap penyisipan dapat menulis ke halaman indeks mana pun, menyebabkan fragmentasi B‑tree dan penurunan kecepatan tulis. Jika aplikasi Anda memerlukan pengurutan berdasarkan waktu, gunakan UUID v7 atau ULID.

4. Apakah huruf besar dan kecil memengaruhi kesetaraan UUID? Menurut RFC 4122, UUID adalah case‑insensitive. 550e8400-e29b-41d4-a716-446655440000 dan 550E8400-E29B-41D4-A716-446655440000 identik. Namun, beberapa perangkat lunak (misal, file system case‑sensitive) mungkin memperlakukannya berbeda. Halaman ini memberi Anda kendali atas tampilan untuk menyesuaikan dengan lingkungan target.

5. Dapatkah UUID v4 digunakan sebagai kunci primer di MySQL atau PostgreSQL? Bisa, tetapi dengan konsekuensi. Jika Anda memiliki beban tulis rendah (ribuan baris per hari) atau menggunakan indeks berbasis hash, dampak fragmentasi kecil. Untuk transaksi tinggi (jutaan baris per jam), pertimbangkan UUID v7 atau integer berurutan.

6. Apa yang terjadi jika saya mematikan tanda hubung dan menghasilkan 100 UUID? Anda akan melihat 100 baris masing‑masing terdiri dari 32 karakter heksa. Ini setara dengan UUID v4 tanpa pemisah visual. Sangat berguna saat menyusun string unik untuk URL atau label yang dibatasi panjangnya.