Penjana UUID

• UUID v1 menggabungkan cap masa dengan alamat MAC mesin — dijamin unik tetapi mendedahkan masa penciptaan dan identiti perkakasan, menimbulkan kebimbangan privasi.
• UUID v3 dan v5 adalah cincangan deterministik: v3 menggunakan MD5, v5 menggunakan SHA-1. Diberikan ruang nama dan nama yang sama, ia sentiasa menghasilkan UUID yang sama — berguna untuk menjana pengecam konsisten daripada kunci asal (cth., menukar alamat e-mel kepada ID pengguna).
• UUID v4 menggunakan 122 bit data rawak, memberikan jaminan keunikan paling kukuh tanpa membocorkan sebarang maklumat.
• UUID v7 (RFC 9562, 2024) membenamkan cap masa Unix dalam 48 bit pertama sambil mengekalkan 74 bit rawak — boleh disusun mengikut masa penciptaan, menjadikannya ideal untuk kunci utama pangkalan data yang mementingkan prestasi indeks.

Bagi kebanyakan aplikasi, v4 adalah pilihan lalai; beralihlah kepada v7 untuk kunci utama pangkalan data yang mementingkan susunan kemasukan.

UUID v4 menggunakan 122 bit rawak, menghasilkan 5.3 × 10^36 nilai yang mungkin. Masalah hari jadi menentukan kebarangkalian pertembungan: selepas menjana 2.7 × 10^18 (2.7 kintilion) UUID, terdapat peluang 50% untuk satu pertembungan berlaku.

Dari segi praktikal, menjana 1 bilion UUID sesaat selama 85 tahun mencapai ambang ini. Pada skala yang lebih realistik — sistem yang menjana 1 juta UUID sehari — kebarangkalian sebarang pertembungan dalam tempoh 100 tahun adalah kira-kira 1 dalam 10^24.

Ini mengandaikan penjana nombor rawak yang betul (CSPRNG); menggunakan Math.random() dalam JavaScript (yang tidak selamat dari segi kriptografi) mengurangkan entropi dan meningkatkan risiko pertembungan. Sentiasa gunakan crypto.randomUUID(), pustaka uuid v4, atau fungsi UUID asli pangkalan data untuk sistem pengeluaran.

UUID sebagai kunci utama membolehkan penjanaan ID terdesentralisasi (aplikasi mencipta ID tanpa ulang-alik pangkalan data) dan mengelakkan serangan pencacahan (pengguna tidak boleh meneka ID rekod lain).

Walau bagaimanapun, nilai UUID v4 yang rawak menjejaskan prestasi indeks B-tree — kemasukan rawak menyebabkan perpecahan halaman dan pemecahan, meningkatkan pembesaran tulisan sebanyak 2-5 kali ganda berbanding kunci integer bersiri. UUID v7 menyelesaikan masalah ini dengan kerawanan berketetapan cap masa, menyediakan kedua-dua keunikan dan susunan bersiri.

Kos storan juga lebih tinggi: 16 bait berbanding 4-8 bait untuk integer, yang ketara dalam jadual dengan berbilion baris dan pelbagai indeks.

Corak biasa menggabungkan UUID sebagai pengenal pasti awam dengan kunci auto-tambah integer secara dalaman, menggabungkan jadual pada integer yang cekap sambil mendedahkan hanya UUID yang selamat kepada API dan URL.

UUID (Pengecam Unik Universal) ialah nilai 128-bit yang direka bentuk untuk menjadi unik merentas ruang dan masa tanpa pihak berkuasa pendaftaran pusat, seperti yang ditentukan oleh IETF RFC 9562 (yang memansuhkan RFC 4122 terdahulu).

128 bitnya ditulis sebagai 32 aksara heksadesimal yang dikumpulkan dalam corak 8-4-4-4-12, seperti 550e8400-e29b-41d4-a716-446655440000. Bit tertentu rizabkan: digit heks ke-13 mengekodkan versi, dan bit atas digit heks ke-17 mengekodkan varian.

Bit yang selebihnya membawa data rawak, cap masa, atau nama yang dicincang bergantung pada versi. Oleh kerana ruang alamat ialah 2^122, penjana bebas boleh mencetak pengecam dengan selamat tanpa pernah berkoordinasi.

Cara paling mudah untuk menjana UUID ialah fungsi terbina dalam bahasa yang memanggil sumber rawak yang selamat secara kriptografi.

• Dalam JavaScript, crypto.randomUUID() mengembalikan UUID v4 dan didokumentasikan pada MDN Web Docs sebagai sebahagian daripada Web Crypto API, yang tersedia pada pelayar moden dan Node.js 14.17+.
• Dalam Python, modul perpustakaan standard uuid menyediakan uuid.uuid4() untuk nilai rawak dan uuid.uuid1() untuk nilai berasaskan tanda masa.
• Dalam PostgreSQL, gen_random_uuid() menghasilkan UUID v4, manakala MySQL 8 menawarkan UUID() untuk nilai gaya v1.

Semua ini memancarkan rentetan yang mematuhi RFC 9562, jadi ID yang dijana dalam satu bahasa boleh beroperasi bersama dengan lancar dengan bahasa yang lain.

Ya, GUID dan UUID adalah pengecam 128-bit yang sama; GUID (Globally Unique Identifier) hanyalah terminologi Microsoft untuk UUID standard yang ditentukan oleh IETF RFC 9562. Ia serasi secara binari, jadi nilai yang dicipta oleh Windows atau .NET boleh digunakan oleh mana-mana sistem yang mematuhi RFC dan sebaliknya.

Satu-satunya perbezaan rutin ialah persembahan: alat Microsoft sering membungkus nilai dalam kurungan kerinting, contohnya {550e8400-e29b-41d4-a716-446655440000}, dan beberapa API COM secara sejarah meletakkan huruf besar pada heksadesimal.

Amaran halus ialah susunan bait — GUID binari Microsoft menyimpan tiga medan pertama dalam bentuk little-endian, yang penting hanya apabila menghuraikan bait mentah, bukan bentuk rentetan bertanda sempang kanonikal.

UUID bukanlah satu rahsia dan tidak seharusnya dianggap sedemikian, walaupun bit rawaknya datang daripada penjana yang selamat secara kriptografi. RFC 9562 secara jelas memberi amaran bahawa UUID tidak menawarkan keselamatan terbina dalam dan tidak boleh dianggap sukar diteka; OWASP turut mengingatkan agar tidak menggunakan pengecam sebagai token kebenaran.

Versi 4 mengambil 122 bit daripada CSPRNG, jadi ia tidak praktikal untuk diramalkan, tetapi versi 1 dan versi 7 menyematkan tanda masa yang membocorkan masa penciptaan, dan versi 3 serta versi 5 adalah cincangan deterministik bagi namespace dan nama yang diketahui.

Untuk token sesi, tetapan semula kata laluan, atau kunci API, jana rahsia entropi tinggi yang khusus daripada bergantung pada struktur UUID untuk perlindungan.

Medan versi dan varian ialah corak bit tetap yang disematkan dalam setiap UUID RFC 9562 yang memberitahu pengurai cara nilai itu dijana.

Versi menduduki empat bit paling bererti bagi bait ketujuh (digit heksadesimal ke-13), jadi UUID v4 sentiasa memaparkan 4 di situ dan v7 sentiasa memaparkan 7. Varian terletak pada dua atau tiga bit paling bererti bagi bait kesembilan (digit heksadesimal ke-17), yang bagi varian standard IETF menjadikan digit tersebut sama ada 8, 9, a, atau b.

Inilah sebabnya mengapa UUID v4 yang sah sepadan dengan corak xxxxxxxx-xxxx-4xxx-[89ab]xxx-xxxxxxxxxxxx. Memeriksa kedudukan tetap ini adalah cara yang betul untuk mengesahkan atau mengkelaskan UUID daripada pemeriksaan panjang yang longgar.

Penjanaan UUID secara pukal berguna untuk membenihkan pangkalan data, membina kelengkapan ujian, menguji beban, dan mengisi API olok-olok, dan alat ini boleh mengeluarkan banyak pengecam sah dalam satu klik. Memandangkan setiap UUID dicipta secara bebas daripada sumber rawak atau tanda masa setiap RFC 9562, menjana kelompok tidak membawa risiko pelanggaran yang bermakna walaupun pada jumlah yang besar.

Untuk data ujian yang boleh diulang, lebih utamakan UUID versi 5 deterministik yang diterbitkan daripada namespace dan nama tetap supaya input yang sama sentiasa menghasilkan pengecam yang sama merentas larian.

Semasa membenihkan jadual berskala pengeluaran, pertimbangkan versi 7 supaya baris yang dimasukkan secara pukal mendarat dalam susunan indeks yang hampir berurutan, yang memastikan halaman B-tree padat and mengurangkan amplifikasi penulisan semasa import.

Simpan UUID dalam jenis binari 16-bait asli apabila pangkalan data anda menyokongnya, kerana mengekalkannya sebagai teks 36 aksara membazirkan lebih daripada separuh ruang dan melambatkan perbandingan indeks. PostgreSQL menyediakan jenis kolum uuid khusus, manakala MySQL dan SQL Server lazimnya menggunakan BINARY(16) dengan fungsi penukaran kepada dan daripada rentetan bertanda sempang.

Seperti yang dinyatakan oleh RFC 9562, UUID tidak sensitif huruf besar-kecil dan harus dinormalkan — biasanya kepada huruf kecil — sebelum disimpan supaya carian kekal konsisten.

Jika anda menggunakan UUID sebagai kunci utama, lebih utamakan versi 7 untuk mengekalkan lokaliti penyisipan; jika anda mesti menggunakan versi 4, sesetengah enjin membolehkan anda menyusun semula bait tanda masa, walaupun versi 7 adalah penyelesaian berasaskan standard untuk masalah pemecahan yang sama.

Kesilapan UUID yang paling biasa ialah menggunakan sumber rawak bukan kriptografi seperti Math.random() JavaScript, yang bukan CSPRNG dan boleh menghasilkan nilai yang condong atau boleh diramalkan; MDN mengesyorkan crypto.randomUUID() atau Web Crypto API sebagai gantinya.

Kesilapan kerap yang lain termasuk:

• menganggap UUID nil (semua sifar) sebagai pengecam sebenar
• menganggap UUID cukup selamat untuk memberi kebenaran akses
• menyimpannya sebagai teks apabila kolum binari 16-bait jauh lebih cekap

Pembangun juga mencampurkan versi secara tidak konsisten, atau bergantung pada versi 1 dalam konteks sensitif privasi di mana tanda masa yang disematkan dan alamat MAC sejarah membocorkan maklumat. Akhir sekali, membandingkan UUID dengan sensitiviti huruf besar-kecil menyebabkan ketidakpadanan palsu, memandangkan RFC 9562 mentakrifkannya sebagai tidak sensitif huruf besar-kecil.