Alat pengembang · generator UUID
UUID Versi 1 hingga 8 Dijelaskan: Yang Mana yang Harus Anda Hasilkan?
· Latar belakang
uuid kriptografi browser-apis
Delapan versi berbagi satu format tetapi memecahkan masalah yang berbeda: pengurutan waktu, reproduktifitas, keacakan, atau tata letak khusus. Posting ini menjelaskan masing-masing dan memberikan jalur keputusan.
Satu format, delapan resep — mengapa versi camilan penting saat Anda memilih fungsi perpustakaan
Standar UUID mendefinisikan format 128-bit sebagai tiga puluh enam karakter heksadesimal dengan tanda hubung. RFC 9562 mendefinisikan delapan resep berbeda—versi satu hingga delapan—untuk mengisi bagian-bagian tersebut dengan pola dan makna yang berbeda. Versi nibble (karakter pertama dari grup ketiga) mengidentifikasi metode mana yang menghasilkan nilai, yang berfungsi sebagai label. Memilih versi yang salah berarti menyimpan informasi sementara yang tidak perlu, kehilangan jaminan pemesanan untuk kinerja database, atau kesalahpahaman peran keamanan pengidentifikasi. Posting ini membahas setiap versi, masalah konkret apa yang dipecahkannya, kapan pengembang menghadapinya dalam praktik, dan memberikan kerangka keputusan untuk memilih versi yang tepat untuk kebutuhan sistem spesifik Anda.
v1 dan v6: waktu plus simpul — tata letak berbasis waktu asli dan versi yang disusun ulang yang mengurutkan dengan benar
Versi 1 menggabungkan stempel waktu 60-bit dengan pengidentifikasi node (awalnya alamat MAC, meskipun implementasi modern menggunakan nilai acak untuk menghindari kebocoran informasi perangkat keras). Stempel waktu mencatat interval 100-nanodetik sejak 15 Oktober, 1582. Bidang node dapat mengungkapkan kapan pengidentifikasi dibuat dan dari mana asalnya secara geografis, itulah sebabnya penerapan modern menghindari alamat MAC. Versi 6 mengatur ulang stempel waktu dan informasi node yang sama untuk meningkatkan kemampuan penyortiran dengan memindahkan bit waktu tingkat tinggi ke depan, membuat UUID v6 mengurutkan dengan benar dalam urutan leksikografis. Jika aplikasi Anda memerlukan UUID yang secara alami mengurutkan berdasarkan waktu pembuatan dengan lokalitas indeks yang unggul, v6 adalah pilihan modern.
v2: DCE Keamanan — varian yang jarang digunakan yang menyematkan pengidentifikasi POSIX
Versi 2 jarang digunakan di sistem baru. Ini menyematkan POSIX pengidentifikasi pengguna atau grup ke dalam tata letak UUID, sehingga hanya berguna di lingkungan lama di mana pengidentifikasi tersebut memiliki makna organisasi. Desain v2 mengasumsikan model komputasi tertentu (DCE Keamanan) yang tidak umum dalam sistem terdistribusi modern. Sebagian besar organisasi mengasosiasikan UUID dengan pengguna atau grup di lapisan aplikasi mereka melalui gabungan database atau tabel pencarian, bukan dengan mengkodekan ID pengguna ke dalam pengidentifikasi itu sendiri. Pemisahan masalah ini mempermudah perubahan model otorisasi, memigrasikan data pengguna, dan memelihara jejak audit. Mengkodekan kredensial secara langsung ke dalam UUID menciptakan hubungan yang erat dan membuat sistem lebih sulit untuk dikembangkan.
v3 dan v5: berbasis nama — ID deterministik yang di-hash dari namespace dan nama dengan MD5 atau SHA-1
UUID versi 3 dan 5 bersifat deterministik: namespace dan nama yang sama selalu menghasilkan pengenal yang sama, ideal untuk mewakili pemetaan stabil dari data eksternal. Versi 3 menggunakan MD5 dan versi 5 menggunakan SHA-1 sebagai algoritma hash, yang mencerminkan usia dan adopsi masing-masing. Saat rekaman pelanggan tiba untuk diimpor, UUID v5 yang berasal dari namespace tetap akan identik di beberapa proses impor, sehingga mencegah duplikasi rekaman. Determinisme ini berarti UUID dapat direproduksi dan diprediksi oleh siapa saja yang mengetahui namespace dan inputnya. Nilai praktisnya terlihat jelas dalam skenario integrasi data: merekonsiliasi catatan pelanggan dari berbagai sistem, mencegah duplikat dalam impor berulang, dan menetapkan ID stabil ke item.
v4: acak — 122 bits dari CSPRNG dan pilihan default saat memesan tidak menjadi masalah
Versi 4 adalah pilihan default ketika pemesanan tidak diperlukan dan Anda ingin pembuatan independen tanpa koordinasi pusat. UUID v4 terdiri dari 122 bits dari sumber acak yang aman secara kriptografis, dengan enam bit disetel ke nilai tetap (versi nibble 4 dan RFC 9562 bit varian 10). Intinya adalah keacakan: setiap panggilan menghasilkan nilai yang berbeda, kemungkinan terjadinya tabrakan semakin kecil, dan tidak diperlukan keadaan atau koordinasi eksternal. Ini adalah versi yang ToolAcre dihasilkan menggunakan crypto.randomUUID() atau crypto.getRandomValues(). Versi ini cocok untuk referensi objek, data tidak terstruktur, dan sebagian besar peran di luar kunci utama atau konteks pengurutan.
v7 dan v8: Waktu Unix dan kustom — versi modern yang diurutkan berdasarkan waktu untuk kunci database dan pintu keluar untuk tata letak yang dipesan lebih dahulu
Versi 7, distandarisasi dalam RFC 9562, menghadirkan properti urutan waktu modern ke dalam format UUID. Ia menggunakan stempel waktu Unix milidetik 48-bit, presisi sub-milidetik 12 bits, dan gabungan 62 bit acak. Stempel waktu milidetik Unix berlaku hingga tahun 10889, sehingga cocok untuk sistem. Hasilnya diurutkan dengan benar dalam urutan leksikografis dan sesuai dengan kolom 128-bit UUID standar tanpa penanganan khusus atau konversi pengkodean. Jika aplikasi Anda memerlukan pengidentifikasi yang mengurutkan berdasarkan waktu pembuatan dalam format standar UUID, v7 adalah praktik terbaik saat ini. Versi 8 adalah standar umum untuk format yang ditentukan implementasi, hanya berguna jika Anda memerlukan tata letak bit tertentu yang tidak tercakup dalam v1-v7.
Contoh praktis — jalur keputusan diterapkan pada tiga skenario: referensi API publik, kunci utama, dan ID stabil untuk catatan yang diimpor
Tiga skenario dunia nyata menggambarkan pemilihan versi: Pertama, referensi API publik harus stabil di seluruh API instance, tidak boleh membocorkan waktu pembuatan, dan harus sama di seluruh server dimulai ulang sehingga instance yang berbeda menghasilkan referensi yang sama untuk dokumen yang sama. Gunakan v5 dengan namespace dan nama dokumen yang stabil. Kedua, kunci utama untuk tabel yang terus berkembang harus unik, tidak menyebabkan fragmentasi indeks, dan harus dapat dihasilkan oleh aplikasi apa pun tanpa koordinasi pusat. Gunakan v7 untuk pengidentifikasi yang dapat diurutkan dengan dukungan ekosistem standar UUID. Ketiga, catatan yang diarsipkan memerlukan pencarian stabil memerlukan pengidentifikasi yang tidak dapat diubah.
Kesimpulan: pilih berdasarkan properti, bukan berdasarkan kebiasaan — generator ToolAcre menghasilkan UUID acak dari CSPRNG browser untuk kasus yang memerlukan v4
Pemilihan versi mengikuti desain skema dan persyaratan sistem Anda, bukan berdasarkan konvensi atau keakraban. UUID acak (v4) adalah default karena tidak memerlukan status atau koordinasi dan menghasilkan pengidentifikasi independen yang cocok untuk sebagian besar peran. Versi yang diurutkan waktu (v6, v7) memecahkan masalah lokalitas indeks dengan mengorbankan kebocoran informasi sementara atau persyaratan sinkronisasi jam. Versi deterministik (v3, v5) mencegah impor duplikat dan mengaktifkan pemetaan eksternal yang stabil dengan mengorbankan prediktabilitas—siapa pun yang mengetahui namespace Anda dapat menghitung ulangnya. ToolAcre menghasilkan UUID v4 acak dari generator browser yang aman secara kriptografis. Saat Anda memerlukan versi yang berbeda, pemeriksaan yang dilakukan dengan baik akan mengonfirmasi penguraian pengidentifikasi sebagai valid.