Generator UUID Gratis

Tentang UUID

UUID (Universally Unique Identifier) adalah pengenal 128-bit yang dirancang unik di seluruh ruang dan waktu. Versi yang paling umum, UUID v4, dihasilkan menggunakan angka acak atau pseudo-acak. Formatnya adalah 8-4-4-4-12 karakter heksadesimal, misalnya 550e8400-e29b-41d4-a716-446655440000.

Sejarah Empat Dekade: Dari Apollo ke RFC 9562

Konsep UUID berasal dari Apollo Network Computing System (NCS) di pertengahan 1980-an, dirancang di Apollo Computer oleh Paul Leach dan Rich Salz untuk mendukung komputasi terdistribusi tanpa pendaftaran pusat. Format ini diadopsi oleh Open Software Foundation Distributed Computing Environment (OSF DCE) pada 1989 dan distandarisasi secara internasional pada 1995 sebagai ITU-T X.667 / ISO/IEC 9834-8. IETF melipat spesifikasi ke dalam RFC 4122 (Leach, Mealling, Salz) pada Juli 2005, yang menjadi referensi kanonis selama dua dekade. RFC 4122 diperbarui oleh RFC 9562 pada Mei 2024, yang mempertahankan semua versi asli (v1 hingga v5), menambahkan tiga versi baru (v6, v7, v8), dan secara formal mendefinisikan konstanta khusus "Nil UUID" (semua nol) dan "Max UUID" (semua satu). Garis keturunan versi penting karena setiap versi menukar properti yang berbeda: berbasis-waktu (dapat diurutkan, bocor); berbasis-nama (deterministik dari input); acak (universal, opaque); custom (apa pun yang Anda butuhkan). Praktik terbaik modern untuk aplikasi baru telah bergeser dari v4 (acak) ke v7 (timestamp + acak) untuk kunci primer, sementara v4 tetap menjadi jawaban yang tepat untuk pengidentifikasi opaque di mana keterurutan tidak diinginkan.

Delapan Versi, Dalam Bahasa Inggris Sederhana

• v1 (timestamp + alamat MAC). 60 bit timestamp (interval 100-nanodetik sejak epoch Gregorian 1582) plus alamat MAC mesin asal. Kelemahan utamanya: itu membocorkan alamat MAC mesin penghasil, yang merupakan masalah privasi. Penulis virus Melissa secara terkenal diidentifikasi pada 1999 sebagian dengan melacak UUID v1 di dokumen Word kembali ke mesin tertentu.
• v2 (keamanan DCE). Varian v1 yang menyertakan UID/GID POSIX. Hampir tidak pernah digunakan dalam praktik; didokumentasikan untuk kelengkapan.
• v3 (berbasis-nama, MD5). UUID deterministik yang berasal dari hash MD5 dari (UUID namespace + string nama). Input yang sama selalu menghasilkan UUID yang sama: berguna untuk menerjemahkan kunci alami (URL, nama domain, distinguished name) menjadi bentuk UUID.
• v4 (acak). 122 bit keacakan (6 bit yang tersisa adalah tag versi + varian). Versi yang paling banyak digunakan: default yang dikembalikan hampir setiap pustaka "berikan saya UUID".
• v5 (berbasis-nama, SHA-1). Sama dengan v3 tetapi menggunakan SHA-1 alih-alih MD5. Lebih disukai daripada v3 untuk aplikasi baru karena SHA-1 kurang rusak daripada MD5, meskipun keduanya memiliki serangan tabrakan yang dikenal.
• v6 (RFC 9562, Mei 2024: ordered-time). Mengurutkan ulang bit timestamp v1 sehingga sortir leksikografis cocok dengan sortir kronologis. Memecahkan keluhan "v1 tidak mengurutkan berdasarkan waktu"; masih membocorkan alamat MAC secara default.
• v7 (RFC 9562, Mei 2024: timestamp Unix + acak). 48 bit pertama adalah timestamp Unix dalam milidetik; 74 bit yang tersisa adalah acak. Mengurutkan secara alami berdasarkan waktu pembuatan, menyertakan data timestamp tanpa membocorkan identitas mesin, dan merupakan rekomendasi modern untuk kunci primer database. Postgres 18+ memiliki uuidv7() built-in; SQL Server memiliki NEWSEQUENTIALID() dengan properti serupa.
• v8 (custom). Cadangan untuk layout khusus-aplikasi. Bidang versi menandainya sebagai v8 dan bit varian diatur dengan benar; semua yang lain terserah aplikasi. Gunakan saat Anda perlu menyematkan data terstruktur Anda sendiri ke dalam amplop berbentuk UUID.

Mengapa v7 Semakin Disukai dari v4 untuk Kunci Database

Kunci primer acak (UUID v4) memiliki biaya kinerja yang terdokumentasi dengan baik dalam database yang mengorganisir baris berdasarkan kunci primer dalam B-tree atau indeks serupa. Setiap insert baru mendarat di posisi acak dalam indeks, yang memfragmentasi halaman indeks, meningkatkan amplifikasi tulis pada disk, dan menghancurkan cache halaman karena baris yang baru saja dimasukkan tersebar di banyak halaman alih-alih dikelompokkan bersama. Kunci sekuensial (integer auto-incrementing, ULID, UUID v7) semua memasukkan di tepi paling kanan indeks, yang menjaga working set kecil dan amplifikasi tulis minimal. Kritik "random key anti-pattern" kembali ke dokumentasi SQL Server awal seputar NEWID versus NEWSEQUENTIALID, dan telah diartikulasikan ulang oleh komunitas Postgres untuk v4 vs v7. Trade-off-nya: v7 membocorkan waktu pembuatan setiap baris, yang dapat menjadi masalah privasi atau kebocoran-informasi dalam beberapa aplikasi (misalnya Anda dapat mengetahui kapan akun dibuat dengan membaca UUID-nya). Untuk sebagian besar aplikasi, kemenangan kinerja melebihi kebocoran timestamp; untuk aplikasi privasi-tinggi, v4 tetap menjadi jawaban yang tepat.

Probabilitas Tabrakan: Matematika Paradoks Ulang Tahun

UUID v4 memiliki 122 bit keacakan, memberikan sekitar 5,3 × 10³⁶ nilai yang mungkin. Paradoks ulang tahun mengatakan Anda perlu sekitar akar kuadrat dari ukuran namespace untuk memiliki peluang 50% dari tabrakan apa pun: sekitar 2,3 × 10¹⁸ UUID. Untuk meletakkannya dalam istilah manusia: jika Anda menghasilkan 1 miliar UUID per detik secara terus-menerus, Anda akan membutuhkan sekitar 86 tahun untuk memiliki peluang 50% dari satu tabrakan. Untuk tingkat generasi skala-aplikasi biasa (ribuan atau jutaan per hari), risiko tabrakan praktis adalah nol. Penyebab paling mungkin dari "UUID duplikat" dalam sistem nyata adalah generator buggy yang menggunakan Math.random() alih-alih CSPRNG, atau generator dengan entropi yang tidak cukup saat startup, atau proses yang secara tidak sengaja menyemai dua generator secara identik: bukan matematika yang mendasarinya. Generator ini menggunakan crypto.randomUUID() browser (di mana tersedia) atau crypto.getRandomValues(), keduanya menarik dari CSPRNG sistem operasi (Linux getrandom(), Windows BCryptGenRandom, macOS SecRandomCopyBytes): sumber entropi yang sama yang digunakan untuk kunci sesi TLS.

Implementasi Browser: crypto.randomUUID()

Web Crypto API mengekspos crypto.randomUUID() sebagai generator satu-panggilan yang mengembalikan string UUID v4 yang sesuai-RFC 4122. Itu dirilis di Chrome 92 (Juli 2021), Firefox 95 (Desember 2021), dan Safari 15.4 (Maret 2022), dan telah tersedia secara baseline di semua browser modern sejak sekitar 2022. Untuk browser yang lebih lama, fallback standar adalah mengalokasikan Uint8Array 16-byte, mengisinya dengan crypto.getRandomValues(), mengatur nibble versi ke 4 (nibble tinggi byte ke-7 = 0x40), mengatur bit varian ke 10xxxxxx (dua bit tinggi byte ke-9 = 0x80), dan memformat byte sebagai string hex 8-4-4-4-12. Generator ini menggunakan crypto.randomUUID() ketika ada dan fallback manual jika tidak: output identik di kedua arah, hanya sedikit lebih lambat di jalur fallback. Kedua jalur berjalan sepenuhnya di browser Anda; tidak ada yang melintasi jaringan.

Kasus Penggunaan: dan Apa yang Sebenarnya Dibutuhkan Masing-masing

• Kunci primer database: terutama sistem terdistribusi atau sharded di mana mengoordinasikan penghitung integer tidak praktis. v7 adalah rekomendasi modern; v4 jika Anda membutuhkan keopaqueran timestamp.
• ID korelasi permintaan API. Setiap permintaan masuk mendapat UUID yang berjalan melalui setiap layanan hilir dalam rantai panggilan; log dari layanan apa pun dapat diikat kembali ke permintaan asal melalui ID. Stripe, Twilio, dan AWS X-Ray semua melakukan ini.
• Kunci idempotensi untuk permintaan HTTP. Header Idempotency-Key Stripe mengambil UUID; jika klien mencoba kembali permintaan yang sama dengan kunci yang sama, Stripe mengembalikan respons cached alih-alih membebani kartu dua kali. Pola ini sekarang standar di seluruh API pembayaran.
• Token sesi: dengan peringatan. UUID v4 secara kriptografis acak dan memiliki 122 bit entropi, yang lebih dari cukup untuk ID sesi. Tetapi token sesi yang hanya UUID rentan terhadap serangan enumerasi jika endpoint terkait apa pun membocorkannya; praktik terbaik modern adalah menggunakan token yang lebih panjang dan ditandatangani (JWT, Paseto) untuk status sesi.
• Nama file untuk deduplikasi unggahan. Hasilkan UUID untuk setiap unggahan, simpan file di /uploads/{uuid}.ext: Anda tidak akan pernah memiliki tabrakan nama terlepas dari nama file asli, dan Anda tidak dapat secara tidak sengaja menyajikan file pengguna lain dengan menebak URL.
• ID pesan dalam sistem event-driven. Kafka, RabbitMQ, AWS SQS, dan sebagian besar platform pub/sub merekomendasikan UUID per pesan untuk pelacakan dan deduplikasi; v7 semakin menjadi default untuk properti dapat-diurutkan-timestamp.
• Generasi data uji. Pustaka Faker dalam setiap bahasa menggunakan UUID sebagai ID default untuk baris uji yang dihasilkan.
• Pengidentifikasi node sistem terdistribusi. Node baru yang muncul dalam cluster menghasilkan UUID untuk dirinya sendiri; koordinator cluster menggunakan ID itu untuk merutekan lalu lintas dan mengidentifikasi node di log.

Alternatif yang Layak Diketahui

UUID adalah default universal tetapi bukan satu-satunya opsi, dan beberapa alternatif layak diketahui untuk kasus penggunaan tertentu. ULID (Universally Unique Lexicographically Sortable Identifier, Alex Knol, ~2016): 128 bit seperti UUID, tetapi dikodekan sebagai 26 karakter Crockford-Base32 alih-alih 32 digit hex: lebih kompak dan URL-safe case-insensitively. 48 bit pertama adalah timestamp Unix dalam milidetik, sehingga ULID mengurutkan secara leksikografis berdasarkan waktu pembuatan. Konseptual sangat dekat dengan UUID v7, mendahuluinya beberapa tahun. Snowflake (Twitter, 2010): 64 bit: jauh lebih kecil dari UUID, sesuai dengan SQL BIGINT. 41 bit timestamp + 10 bit ID mesin + 12 bit urutan per-milidetik. Digunakan oleh Twitter/X, Discord, Instagram, dan banyak sistem skala-besar di mana kunci primer 64-bit adalah kendala keras. KSUID (Segment, 2017): 27 karakter, timestamp presisi-detik + 128 bit acak. Menukar presisi milidetik untuk representasi string yang lebih kecil dari UUID. nanoid (Andrey Sitnik, 2017): pustaka kecil yang menghasilkan pengidentifikasi URL-safe acak dengan panjang yang dapat dikonfigurasi. Default 21 karakter memberikan ketahanan tabrakan yang serupa dengan UUID v4 dalam jumlah byte yang jauh lebih sedikit. Untuk URL yang menghadap publik di mana Anda akan menyematkan UUID, nanoid lebih pendek dan lebih ramah. Trade-off: pengidentifikasi nanoid tidak memiliki bit penanda versi + varian yang membedakan mereka sebagai UUID, sehingga mereka tidak masuk ke sistem yang mengharapkan nilai berbentuk-UUID.

Keamanan URL dan Variasi Format

UUID dalam bentuk hyphenated kanonisnya (550e8400-e29b-41d4-a716-446655440000) adalah URL-safe: setiap karakter (huruf kecil, digit, hyphen) berada dalam set unreserved yang didefinisikan oleh RFC 3986. Ini berarti Anda dapat menjatuhkan UUID langsung ke jalur URL atau string kueri tanpa percent-encoding. Beberapa sistem melucuti hyphen untuk kekompakan, menghasilkan string hex 32-karakter (550e8400e29b41d4a716446655440000) yang masih URL-safe; konversi reversibel karena struktur UUID tetap. Beberapa sistem membungkus UUID dalam kurawal ({550e8400-e29b-41d4-a716-446655440000}): konvensi GUID Microsoft; kurawal bersifat dekoratif dan tidak pernah berjalan di URL. Beberapa sistem mengkapitalisasi karakter hex; UUID adalah case-insensitive per spesifikasi, tetapi konsistensi dalam sistem penting. Generator ini menawarkan ketiga opsi (huruf besar, kurawal, tanpa dash) untuk kompatibilitas dengan pipeline apa pun yang Anda berikan UUID.

UUID vs GUID: Hal yang Sama, Nama yang Berbeda

UUID adalah istilah standar yang digunakan oleh IETF, ISO, dan sebagian besar proyek sumber-terbuka. GUID (Globally Unique Identifier) adalah istilah Microsoft yang digunakan di Windows, .NET, COM/OLE, SQL Server, Active Directory, dan Windows Registry. Keduanya mengacu pada pengidentifikasi 128-bit identik dalam format hex 8-4-4-4-12 yang sama. Secara fungsional dapat dipertukarkan: GUID yang dihasilkan oleh Windows dapat digunakan di mana saja UUID diharapkan, dan sebaliknya. Satu-satunya perbedaan yang layak diketahui: generasi GUID Microsoft secara historis menggunakan UUID v4 di banyak API tetapi UUID v1 (dengan alamat MAC) dalam beberapa konteks COM/OLE yang lebih lama; ini didokumentasikan dalam spesifikasi COM Microsoft. Jika Anda menerima GUID dari sistem berasal-Microsoft dan ingin tahu versi mana itu, periksa nibble versi (karakter hex ke-13: '1' untuk v1, '4' untuk v4, dll.).

Privasi: Mengapa Hanya-Browser Penting Bahkan di Sini

UUID tidak memiliki makna inheren, jadi mengapa penting bahwa generator berjalan secara lokal? Dua alasan. Pertama, ketika UUID digunakan sebagai token sesi, kunci idempotensi, atau pengidentifikasi tipe-rahasia lainnya, menghasilkannya di server pihak-ketiga berarti server itu melihat nilai sebelum Anda menggunakannya: paparan kecil tetapi nyata. Kedua, generator sisi-server yang menjanjikan "keacakan kriptografi" tidak dapat diverifikasi oleh pengguna; server yang buggy atau jahat dapat mengembalikan nilai non-acak yang terlihat acak, dan Anda tidak akan memiliki cara untuk mendeteksi bias. Generator hanya-browser menjalankan panggilan crypto.randomUUID() yang sama yang akan dijalankan aplikasi Anda di sisi-server; entropi berasal dari sumber sistem operasi yang sama (Linux getrandom(), Windows BCryptGenRandom, macOS SecRandomCopyBytes); tidak ada pihak ketiga yang melihat output. Anda dapat memverifikasi dengan membuka tab Network DevTools saat Anda mengklik Generate: tidak ada permintaan keluar. Bawa halaman offline (mode pesawat) setelah dimuat dan generator masih bekerja.

Pertanyaan yang Sering Diajukan

Apa perbedaan antara UUID dan GUID?

Keduanya pada dasarnya adalah hal yang sama. UUID adalah istilah standar (RFC 4122), sedangkan GUID (Globally Unique Identifier) adalah terminologi Microsoft. Keduanya merujuk pada pengenal 128-bit dalam format heks 8-4-4-4-12 yang sama.

Dapatkah dua UUID sama?

Secara teoretis ya, tetapi probabilitasnya sangat rendah secara astronomis. UUID v4 memiliki 122 bit acak, memberikan sekitar 5.3 × 10³⁶ nilai yang mungkin. Anda harus menghasilkan miliaran UUID per detik selama beberapa dekade untuk memiliki peluang 50% terjadi satu tabrakan.

Apakah UUID ini aman secara kriptografis?

Ya. Generator ini menggunakan Web Crypto API (crypto.getRandomValues) yang menyediakan nilai acak yang kuat secara kriptografis. Keluarannya cocok untuk kasus penggunaan sensitif keamanan seperti token sesi.

Haruskah saya menggunakan UUID v4 atau v7 untuk kunci primer database saya?

v7 adalah rekomendasi modern jika database Anda mendukungnya. v4 (acak) memasukkan di posisi acak dalam indeks B-tree, memfragmentasi indeks, dan menghancurkan cache halaman. v7 (timestamp + acak, RFC 9562 Mei 2024) memasukkan di tepi paling kanan indeks karena ID mengurutkan berdasarkan waktu pembuatan: kinerja tulis yang sama dengan integer auto-increment, dengan distribusi dan keunikan UUID. Postgres 18+ memiliki uuidv7() built-in. Trade-off: v7 membocorkan waktu pembuatan setiap baris, yang dapat menjadi masalah privasi dalam beberapa aplikasi. Untuk sebagian besar kasus penggunaan, kemenangan kinerja melebihi kebocoran timestamp.

Apa itu ULID, KSUID, dan nanoid?

Format ID alternatif. ULID (Alex Knol, ~2016): 128 bit seperti UUID tetapi dikodekan sebagai 26 karakter Crockford-Base32; mengurutkan secara leksikografis berdasarkan timestamp. KSUID (Segment, 2017): 27 karakter, timestamp presisi-detik + 128 bit acak. nanoid (Andrey Sitnik, 2017): pustaka kecil yang menghasilkan ID URL-safe acak dengan panjang yang dapat dikonfigurasi; default 21 karakter memberikan ketahanan tabrakan yang serupa dengan UUID v4 dalam jumlah byte yang jauh lebih sedikit. Snowflake (Twitter, 2010): ID 64-bit yang sesuai dengan SQL BIGINT, digunakan oleh Twitter, Discord, dan Instagram. Gunakan UUID ketika sistem penerima mengharapkan format UUID; gunakan alternatif ketika Anda memiliki persyaratan ukuran, keterurutan, atau ramah-URL tertentu.

Apakah UUID dikirim ke mana pun?

Tidak. Setiap UUID dihasilkan secara lokal di browser Anda menggunakan Web Crypto API. Generator tidak pernah membuat permintaan jaringan: verifikasi di tab Network DevTools saat Anda mengklik Generate, atau bawa halaman offline setelah dimuat dan konfirmasi alat masih berfungsi. Aman untuk menghasilkan token sesi, kunci idempotensi, atau pengidentifikasi lainnya di mana Anda tidak ingin pihak ketiga melihat nilai sebelum Anda menggunakannya.

Alat Terkait