Penjana UUID v4

Struktur dan Prinsip Asas UUID v4

UUID v4 (Universally Unique Identifier versi 4) adalah pengecam 128-bit yang dibina dengan 122 bit rawak tulen dan 6 bit tetap yang menandakan versi dan varian. Bit-bit tetap ini terletak pada kedudukan tertentu dalam rentetan 36 aksara (atau 32 aksara jika tanda sempang digugurkan). Empat bit pertama daripada bit tetap menunjukkan versi (iaitu 0100 bagi versi 4), manakala dua bit seterusnya menunjukkan varian (biasanya 10 bagi varian RFC 4122). Oleh itu, daripada 128 bit yang ada, hanya 122 bit yang benar-benar rawak – satu jumlah entropi yang sangat besar.

Format kanonik UUID v4 adalah 8-4-4-4-12, di mana setiap bahagian diwakili oleh aksara heksadesimal. Contohnya: 550e8400-e29b-41d4-a716-446655440000. Setiap bahagian dipisahkan oleh tanda sempang, tetapi pengguna boleh memilih untuk menggugurkan tanda sempang melalui togol pada halaman, menghasilkan rentetan 32 aksara heksadesimal tanpa pemisah. Sama ada tanda sempang dikekalkan atau tidak, nilai inti 122 bit rawak tetap sama – cuma perwakilan visual yang berbeza.

Halaman penjana UUID v4 ini membenarkan pengguna mengawal dua aspek format: huruf besar (togol yang menjadikan aksara a–f dipaparkan sebagai A–F) dan tanda sempang (togol untuk menyembunyikan atau memaparkan tanda sempang). Kedua-dua togol ini hanya relevan untuk UUID v4 dan v7; format lain seperti ULID dan NanoID menggunakan kawalan berbeza. Apabila mana-mana togol diubah, semua ID yang dipaparkan akan dijanakan semula serta-merta.

Kebarangkalian Perlanggaran dan Kepentingan 122 Bit Entropi

Dengan 122 bit rawak, kebarangkalian perlanggaran (collision) antara dua UUID v4 yang dijana secara bebas adalah sangat kecil. Formula asas kebarangkalian perlanggaran untuk nilai rawak dengan ruang sampel N = 2¹²² dan k sampel adalah lebih kurang k² / 2N. Untuk k = 1 bilion UUID, kebarangkalian perlanggaran adalah sekitar 10¹⁸ / (2 · 5.3 × 10³⁶) ≈ 9.4 × 10⁻²⁰ – satu angka yang boleh diabaikan dalam amalan. Inilah sebabnya UUID v4 sering digunakan dalam sistem yang memerlukan pengecam unik tanpa koordinasi pusat, seperti pangkalan data teragih, sistem mesej, dan log peristiwa.

Namun, perlu difahami bahawa perlanggaran bukan sifar mutlak – ia hanya sangat tidak mungkin. Dalam sistem yang menjana berbilion UUID setiap saat, kebarangkalian perlanggaran masih sangat rendah tetapi perlu diambil kira dalam reka bentuk yang kritikal. Halaman ini menggunakan sumber rawak kuat pelayar (crypto.randomUUID atau setara) untuk memastikan bit-bit rawak dijana dengan kualiti tinggi, bebas daripada bias yang boleh meningkatkan risiko perlanggaran.

Keadaan ini berbeza dengan pengecam berasaskan masa seperti UUID v7 atau ULID, di mana bit masa mendominasi dan ruang rawak lebih kecil (contohnya, ULID menggunakan 80 bit rawak). Walaupun perlanggaran masih sukar, UUID v4 menawarkan jaminan entropi yang lebih tinggi untuk kes penggunaan yang memerlukan ketidaktekaan (unguessability) – misalnya dalam token API atau ID sesi.

Kesan pada Pengindeksan Pangkalan Data

Salah satu perbezaan utama UUID v4 berbanding pengecam berurutan (seperti integer auto-increment atau UUID v7) ialah sifat rawak sepenuhnya menyebabkan fragmentasi indeks B-tree yang ketara. Apabila UUID v4 digunakan sebagai kunci primer dalam pangkalan data relasional, rekod-rekod baru akan disisipkan pada kedudukan rawak dalam pokok B-tree. Ini menyebabkan:

• Peningkatan halaman indeks – indeks perlu sering dipecah (split) untuk menampung nilai rawak, mengakibatkan lebih banyak blok cakera digunakan.
• Kemerosotan prestasi tulis – setiap penyisipan memerlukan kemas kini indeks pada halaman yang tidak berturutan, meningkatkan masa cari dan tulis.
• Penggunaan ruang yang lebih besar – fragmentasi dalaman dan luaran menghasilkan indeks yang lebih besar daripada saiz optimum.

Sebagai perbandingan, UUID v7 menggabungkan cap waktu (timestamp) dengan bit rawak, menjadikan nilai-nilai lebih teratur mengikut masa. Ini mengurangkan fragmentasi indeks kerana rekod baru cenderung disisipkan pada penghujung indeks. ULID juga menggunakan pendekatan serupa dengan 48 bit cap waktu dan 80 bit rawak. Walau bagaimanapun, untuk sistem yang beroperasi di luar talian atau dalam persekitaran teragih tanpa jam yang diselaraskan, UUID v4 masih menjadi pilihan utama kerana ia tidak bergantung pada masa.

Bagi pengguna yang memilih UUID v4 sebagai kunci primer, amalan terbaik termasuk menggunakan indeks kelompok (clustered index) pada lajur bukan UUID (contohnya, integer auto-increment) dan meletakkan UUID dalam indeks sekunder. Atau, jika prestasi tulis tinggi adalah keutamaan, pertimbangkan untuk menggunakan UUID v7 atau ULID. Halaman ini menyediakan pilihan format lain (v7, ULID, NanoID) dalam menu lungsur supaya pengguna boleh membandingkan dan memilih format yang sesuai.

Penyesuaian Format: Huruf Besar dan Tanda Sempang

Togol huruf besar hanya mempengaruhi aksara heksadesimal a–f, bukan digit 0–9. Apabila diaktifkan, UUID dipaparkan dengan huruf besar (contoh: 550E8400-E29B-41D4-A716-446655440000). Ini berguna apabila sistem sasaran hanya menerima huruf besar (misalnya, dalam sesetengah protokol atau antara muka pengguna yang ketat). Walau bagaimanapun, kebanyakan implementasi UUID tidak peka huruf besar-kecil (case-insensitive), jadi perubahan ini hanya mempengaruhi paparan dan bukan nilai unik.

Togol tanda sempang membuang semua tanda sempang, menghasilkan rentetan 32 aksara heksadesimal berterusan. Format ini lebih padat dan sesuai untuk digunakan dalam URL, nama fail, atau medan yang mempunyai had aksara. Contoh: 550e8400e29b41d4a716446655440000. Walaupun tanpa tanda sempang, nilai UUID masih boleh diurai semula menjadi format kanonik jika perlu kerana panjang dan kedudukan bit tetap diketahui.

Perlu diingat bahawa kedua-dua togol ini hanya berfungsi untuk UUID v4 dan v7. Untuk ULID dan NanoID, halaman menggunakan kawalan berbeza (contohnya, ULID mungkin tidak mempunyai togol huruf besar kerana ia hanya menggunakan huruf besar). Pengguna boleh menukar format pada bila-bila masa, dan semua ID yang dipaparkan akan dijana semula secara automatik.

Penggunaan dalam Sistem Teragih dan Keselamatan

UUID v4 amat berguna dalam senario di mana koordinasi pusat tidak boleh dilakukan – misalnya, sistem yang beroperasi dalam persekitaran luar talian, atau berbilang nod yang menghasilkan ID tanpa berkomunikasi antara satu sama lain. Oleh kerana kebarangkalian perlanggaran diabaikan, setiap nod boleh menjana ID setempat tanpa perlu merujuk kepada pelayan pusat. Ini mengurangkan kependaman dan menghilangkan titik kegagalan tunggal.

Dalam konteks keselamatan, UUID v4 sering digunakan sebagai token API atau ID permintaan kerana sifat rawaknya menyukarkan serangan enumerasi. Berbeza dengan ID berurutan (seperti integer), penyerang tidak boleh meneka ID seterusnya dengan mudah. Walau bagaimanapun, perlu diingat bahawa UUID v4 tidak direka untuk menjadi rahsia kriptografi – ia hanya tidak boleh diteka secara praktikal untuk amaun usaha yang munasabah. Untuk kes penggunaan yang memerlukan kerahsiaan tinggi, gunakan token yang dijana oleh fungsi derivasi kunci (KDF) atau protokol khusus.

Selain itu, UUID v4 sesuai untuk penyembunyian bilangan rekod – kerana nilainya rawak, sukar untuk menganggarkan jumlah rekod dalam pangkalan data berdasarkan nilai ID. Ini penting dalam sistem yang mendedahkan ID kepada pengguna (contohnya, dalam URL).

Penjanaan Setempat dalam Pelayar

Semua penjanaan UUID v4 dalam halaman ini berlaku sepenuhnya dalam pelayar menggunakan API crypto.randomUUID() atau setara. Tiada data dihantar ke pelayan – ini memberikan dua kelebihan utama:

1. Privasi – pengguna tidak perlu risau tentang ID yang dijana dihantar atau disimpan di tempat lain. Ini penting untuk organisasi yang mempunyai dasar keselamatan data yang ketat.
2. Kependaman rendah – penjanaan berlaku serta-merta tanpa menunggu respons pelayan. Pengguna boleh menjana sehingga 100 UUID dalam satu masa dan menyalinnya dengan satu klik.

Apabila pengguna menekan butang Salin Semua, status berubah kepada "Copied all!" dan semua ID disalin ke papan klip. Jika pengguna mengklik pada mana-mana ID individu, ID tersebut disalin seorang diri. Ini membolehkan fleksibiliti: sama ada salin semua untuk dimasukkan ke dalam fail, atau salin satu untuk digunakan dalam ujian titik demi titik.

Kesemua ciri ini menjadikan halaman ini alat yang praktikal untuk pembangun, jurutera keselamatan, dan penguji yang memerlukan UUID v4 dengan cepat tanpa perlu menulis skrip sendiri.

Soalan Lazim (FAQ)

1. Apakah perbezaan antara UUID v4 dan UUID v7? UUID v4 menggunakan 122 bit rawak, manakala UUID v7 menggunakan 48 bit cap waktu diikuti dengan 74 bit rawak. Akibatnya, UUID v7 boleh diisih mengikut masa, mengurangkan fragmentasi indeks B-tree, tetapi UUID v4 menawarkan entropi yang lebih tinggi untuk keselamatan dan ketidaktekaan.

2. Adakah UUID v4 selamat untuk dijadikan token API? Ya, ia selamat untuk kebanyakan kes penggunaan biasa kerana 122 bit rawak menjadikannya sangat sukar diteka. Walau bagaimanapun, untuk sistem yang memerlukan kerahsiaan kriptografi yang ketat, gunakan token yang dijana oleh fungsi kriptografi yang lebih khusus.

3. Bolehkah saya menggunakan UUID v4 tanpa sempang sebagai kunci primer? Ya, anda boleh menggunakan rentetan 32 aksara tanpa sempang. Ini lebih padat dan mudah digunakan dalam URL. Walau bagaimanapun, perlu diingat bahawa tanpa sempang, UUID masih mempunyai format yang boleh diurai semula jika perlu.

4. Mengapa UUID v4 menyebabkan fragmentasi indeks? Oleh kerana UUID v4 adalah rawak sepenuhnya, rekod baru akan disisipkan di lokasi rawak dalam pokok B-tree. Ini menyebabkan indeks perlu sering dipecah dan menghasilkan halaman yang tidak padat, mengurangkan prestasi tulis dan meningkatkan penggunaan ruang.

5. Apakah yang berlaku jika saya menukar kiraan atau togol selepas menjana? Setiap kali anda menukar mana-mana pilihan (format, kiraan, huruf besar, sempang), semua ID yang dipaparkan akan dijanakan semula serta-merta. Status akan kembali kepada "Ready." atau "Generated." bergantung pada keadaan.

6. Adakah halaman ini menyimpan UUID yang dijana? Tidak. Semua penjanaan berlaku di dalam pelayar menggunakan API crypto.randomUUID(). Tiada data dihantar ke pelayan atau disimpan di mana-mana. Halaman ini hanya memaparkan ID di skrin dan membenarkan penyalinan ke papan klip.