Pembuat UUID / ULID
Buat UUID v4, UUID v7 berurutan waktu, ULID, atau ID acak pendek secara massal. Pilih jumlah yang Anda butuhkan, hapus tanda hubung, ubah huruf besar/kecil
Buat pengenal unik saat dibutuhkan: UUID v4 (acak), UUID v7 (berurutan waktu), ULID, dan ID acak pendek. Pilih versinya, berapa banyak yang Anda butuhkan, lalu salin daftarnya langsung ke kode, data uji, atau basis data Anda.
Pilihannya penting: v4 adalah default yang aman untuk kunci utama, sedangkan v7 dan ULID dimulai dengan stempel waktu, yang menjaga indeks basis data tetap efisien karena baris baru disisipkan berdekatan. Gunakan ID acak pendek bila Anda hanya perlu token yang tidak transparan, bukan pengenal standar.
Cara membuat UUID atau ULID
Pilih jenis pengenalnya
Atur berapa banyak yang Anda butuhkan
Salin daftarnya
FAQ
Apa perbedaan UUID v4 dan v7?
Versi 4 sepenuhnya acak. Versi 7 menempatkan stempel waktu milidetik di depan, sehingga pengenalnya terurut berdasarkan waktu pembuatan - lebih baik untuk lokalitas indeks basis data dan tetap unik secara global.
Apa itu ULID?
Pengenal 26 karakter yang memakai Crockford Base32: stempel waktu 48 bit diikuti 80 bit acak. ULID dapat diurutkan secara leksikografis, yang berguna di log dan nama file.
Apakah pengenal ini benar-benar unik?
Semuanya dihasilkan dari sumber acak yang aman secara kriptografis. Peluang tabrakan v4 sangat kecil, jadi untuk keperluan praktis ya.
Haruskah saya memakainya sebagai kunci basis data?
Aman, tetapi kunci v4 yang acak menyebarkan penyisipan ke seluruh indeks. Jika performa penyisipan penting, pilih v7 atau ULID yang berurutan waktu.
Bisakah saya membuat banyak sekaligus?
Bisa, atur jumlahnya dan salin seluruh daftar dalam satu kali - praktis untuk menyiapkan data uji.
Apakah ada yang dikirim ke server?
Tidak, pengenalnya dibuat di browser Anda.
Sekilas
| Masukan | teks |
|---|---|
| Beberapa file | Tidak |
| Dijalankan di | Di browser Anda - file tidak pernah diunggah |
| Bekerja offline | Ya — setelah halaman dimuat |
| Harga | Gratis, tanpa pendaftaran, tanpa tanda air |
Menangani rahasia dengan aman
Alat pengembang memproses kredensial lebih sering daripada yang orang sadari, dan risikonya bukan pada algoritmenya melainkan pada ke mana datanya pergi. Hashing bersifat satu arah dan bukan enkripsi - MD5 dan SHA-1 sudah rusak untuk apa pun yang berkaitan dengan keamanan, dan bahkan SHA-256 adalah alat yang keliru untuk menyimpan kata sandi, karena bcrypt, scrypt, atau Argon2 justru ada untuk dibuat lambat. Base64 adalah pengodean, bukan perlindungan: siapa pun bisa mendekodenya, jadi jangan pernah menganggapnya sebagai penyamaran. JWT bisa dibaca siapa pun yang memegangnya, itulah sebabnya payload-nya tidak boleh memuat rahasia, dan mendekode token tidak memverifikasi tanda tangannya - verifikasi memerlukan kuncinya. Semua yang ada di situs ini berjalan lokal di browser Anda, dan itulah alasan situs ini bisa menangani token serta kata sandi dengan aman.
Di mana konversi diam-diam rusak
Sebagian besar bug konversi bukan soal sintaksis, melainkan soal makna. Kolom kode pos pada CSV kehilangan angka nol di depannya begitu spreadsheet menduga kolom itu berisi angka; ID yang panjang melampaui presisi floating-point; tanggal berubah makna tergantung apakah formatnya tanggal-dulu atau bulan-dulu. Kunci JSON tidak berurutan, sedangkan array berurutan, dan alat yang mengurutkan kunci tidak mengubah apa pun sementara alat yang mengurutkan array mengubah datanya. Unicode adalah jebakan lain: teks bisa datang sebagai UTF-8, UTF-16, atau dengan BOM, dan dekoder yang salah menebak mengubah karakter beraksen menjadi mojibake. Sebelum memercayai konversi apa pun, periksa sekilas baris pertama dan terakhir, setiap bidang yang memiliki angka nol di depan, dan setiap bidang yang memuat tanda kutip, koma, atau baris baru.