Generator UUID
Hasilkan UUID v4 (acak) atau v7 (terurut waktu) di browser Anda. Menggunakan Web Crypto API untuk keacakan.
- Pilih v4 untuk UUID acak atau v7 untuk yang terurut waktu.
- Atur Jumlah (hingga 1000) dan klik Hasilkan.
- Gunakan Salin semua untuk mengambil seluruh daftar, atau pilih satu baris secara manual.
Apa fungsinya?
UUID v4 adalah 122 bit keacakan kriptografis yang kuat — default di mana-mana untuk kunci idempotensi, ID sesi, dan di mana pun Anda menginginkan pengidentifikasi yang buram dan tak terurut. UUID v7 menyematkan stempel waktu Unix-millisecond 48-bit di byte awal, sehingga nilai yang dihasilkan berdekatan dalam waktu diurutkan berdekatan dalam urutan leksikografis. Ini membuat v7 lebih cocok untuk kunci utama database, di mana sisipan v4 jika tidak dapat memfragmentasi indeks B-tree.
Contoh
Tiga UUID v4 (acak, tanpa urutan):
f47ac10b-58cc-4372-a567-0e02b2c3d479
6ba7b810-9dad-11d1-80b4-00c04fd430c8
d1b2c3e4-5678-4abc-9def-0123456789ab Tiga UUID v7 yang dihasilkan dalam millisecond yang sama (perhatikan prefiks bersama):
018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90
018f8e50-fcaa-7c3d-a41f-8c9b07e2c0d1
018f8e50-fcab-7c01-b3e7-1d9a4f5c6e82 Kesalahan umum dan jebakan
Ini adalah jebakan nyata yang dihadapi pengembang saat menghubungkan UUID ke dalam aplikasi:
- Menggunakan v4 di mana urutan penyisipan penting. Mengindeks 10 juta v4 acak menyebabkan pemisahan halaman berat di B-tree. Jika Anda tetap memakai v4, hiduplah dengan amplifikasi tulis atau ganti kunci utama menjadi v7.
- Menghapus tanda hubung dan kehilangan nibble versi. f47ac10b58cc4372a5670e02b2c3d479 masih merupakan UUID hex 32 karakter yang valid, tetapi karakter ke-13 (4) adalah penanda versi — bukan nibble acak. Jangan menganggap seluruh 32 karakter acak.
- Mengandalkan Math.random(). Pustaka lama yang dibangun di atas Math.random() tidak kuat secara kriptografis dan dapat diprediksi. Gunakan crypto.randomUUID() (browser dan Node 19+) atau pustaka v7 yang membaca dari crypto.
- Memperlakukan v7 sebagai stempel waktu. 48 bit awal membawa waktu tetapi sisanya acak, jadi dua v7 dengan millisecond yang sama tidak diurutkan secara deterministik. Jangan mengandalkan pemecahan tie.
- Menyimpan sebagai VARCHAR(36). Bekerja tetapi menggandakan penyimpanan vs kolom UUID / BINARY(16) 16-byte native dan memperlambat join. Gunakan tipe native database (uuid di Postgres, UNIQUEIDENTIFIER di SQL Server).
- Regex yang memerlukan versi tertentu. /[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-.../i hanya cocok dengan v4. Jika Anda kemudian memancarkan v7, regex tersebut diam-diam menolak ID yang valid.
Pertanyaan yang sering diajukan
Apa perbedaan antara UUID v4 dan v7?
v4 adalah 122 bit keacakan ditambah penanda versi dan varian, tanpa komponen waktu. v7 mengawali dengan stempel waktu Unix-millisecond 48-bit dan mengisi sisanya dengan bit acak, sehingga nilai v7 yang dihasilkan berdekatan dalam waktu diurutkan secara leksikografis. Gunakan v7 sebagai kunci utama database untuk menjaga sisipan B-tree tetap lokal; gunakan v4 ketika Anda tidak menginginkan sinyal urutan sama sekali.
Apakah saya akan mendapatkan UUID duplikat?
Praktis tidak. UUID v4 memiliki 122 bit acak, jadi probabilitas dua berbenturan dalam batch satu miliar kira-kira 10^-18. Anda perlu menghasilkan sekitar 2,7 kuintiliun UUID v4 sebelum mencapai peluang 50% satu tabrakan. Perlakukan generasi unik sebagai pasti dan jangan tambahkan pemeriksaan keunikan.
Apakah v4 acak secara kriptografis?
Alat ini menggunakan crypto.randomUUID() yang diwajibkan spec untuk menarik dari PRNG yang kuat secara kriptografis. Itu cukup untuk ID sesi, kunci idempotensi, dan sebagian besar token keamanan. Ini bukan pengganti token yang ditandatangani atau rahasia API panjang, dan Anda tidak boleh menurunkan kunci enkripsi dari UUID.
Apakah UUID v7 terstandarisasi?
Ya. UUID v7 didefinisikan dalam RFC 9562 (Mei 2024), yang menggantikan RFC 4122 dan memformalkan v6, v7, dan v8 bersama versi asli. Sebagian besar bahasa modern memiliki implementasi v7 — Postgres, MySQL, dan SQL Server semuanya menerima nilai v7 sebagai kolom UUID tanpa perubahan.
Seperti apa bentuk biner dan apakah endianness penting?
UUID adalah 16 byte. Bentuk teks kanonik mengelompokkannya sebagai karakter hex 8-4-4-4-12. Byte ditulis dalam urutan jaringan (big-endian) per RFC 9562, jadi 018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90 dimulai dengan byte 0x01. GUID Microsoft secara historis menyimpan tiga grup pertama little-endian di memori — waspadalah saat interop dengan dump biner .NET.
Apakah Anda menyimpan UUID yang dihasilkan alat ini?
Tidak. Kami tidak menyimpan UUID yang Anda hasilkan di sini. Setiap nilai ditampilkan di area output dan hilang saat Anda me-refresh atau menutup tab — tidak ada yang disimpan, tidak ada telemetri yang dikumpulkan pada nilai. Anda dipersilakan memverifikasi di alat pengembang browser Anda.