§

Penjana UUID — Penjana UUID v4 Dalam Talian Percuma

v4 ialah lalai. v7 mengisih secara leksikografi mengikut masa penjanaan dan merupakan pilihan terbaik untuk kunci pangkalan data.
Format output
§

Keluaran

    UUID menjadi semakin popular dalam pembangunan perisian Malaysia: setiap jadual PostgreSQL baharu dalam Supabase atau pangkalan data awan menggunakan `uuid` sebagai lajur `id` lalai, setiap objek API Stripe membawa kunci berbentuk UUID, dan jadual dimensi dalam platform analitik seperti BigQuery menggunakan UUID sebagai kunci pengganti yang stabil. Penjana ini memancarkan UUID v4 rawak kriptografi dan UUID v7 teratur masa sepenuhnya melalui API Web Crypto pelayar, supaya nilai pengecam yang anda tempah untuk pengeluaran tidak pernah bocor melalui titik hujung jauh.

    Apakah UUID?

    UUID (Universally Unique Identifier) ialah nilai 128-bit yang dipaparkan sebagai rentetan 36-aksara seperti 550e8400-e29b-41d4-a716-446655440000. Format dan semantik versi ditakrifkan oleh RFC 4122 untuk v1 hingga v5, dan oleh RFC 9562 untuk versi v6, v7, dan v8 yang lebih baharu. Alat ini menjana v4 (sepenuhnya rawak), v1 (cap masa ditambah ID nod rawak), dan v7 (awalan cap masa milisaat-Unix ditambah akhiran rawak, boleh diisih mengikut masa penjanaan) — semuanya dalam pelayar anda, menggunakan API Web Crypto platform. Tiada data dihantar ke pelayan.

    Bagaimana penjanaan UUID berfungsi?

    Setiap versi bertukar antara determinisme, kebolehan pengisihan, dan entropi secara berbeza. Alat memilih algoritma yang betul berdasarkan pilihan anda:

    1. v4 (rawak) memanggil crypto.randomUUID() pelayar, yang mengembalikan 122 bit kerawakan kriptografi dengan 6 bit tetap (versi 0100 dan varian 10) ditetapkan pada kedudukan yang betul. Perlanggaran tidak mungkin secara astronomi — anda perlu menjana kira-kira 2.71 kuintilion UUID v4 untuk mendapat satu pendua dengan kebarangkalian 50%.
    2. v1 (cap masa + nod) mengepak cap masa Gregorian 60-bit (tanda 100-nanosaat sejak 1582-10-15) ke dalam time_low / time_mid / time_hi_and_version, menetapkan nibble versi kepada 0001, memilih jujukan jam 14-bit dengan bit varian ditetapkan, dan menggunakan ID nod rawak 48-bit dengan bit multicast dipaksa hidup (RFC 4122 §4.5 secara eksplisit membenarkan ID nod rawak apabila tiada MAC perkakasan tersedia — bit multicast menandakannya sebagai bukan-MAC).
    3. v7 (cap masa boleh-isih), mengikut RFC 9562 §5.7, meletakkan cap masa milisaat-Unix big-endian 48-bit, kemudian versi 4-bit 0111, kemudian 12 bit rawak, kemudian varian 2-bit 10, kemudian 62 bit rawak lagi. Kerana cap masa berada dalam bit paling penting, UUID v7 mengisih secara leksikografi mengikut susunan penjanaan — ciri yang tidak ditawarkan oleh versi UUID lain tanpa pengekodan tambahan.
    4. Semua kerawakan datang dari crypto.getRandomValues(), RNG selamat kriptografi pelayar. Kedua-dua v1 dan v7 memasukkan penjaga monoton intra-tanda supaya dua panggilan berturut-turut dalam tanda jam yang sama masih mengisih yang kedua di atas yang pertama — penting untuk jalan penjanaan pukal yang berlumba dengan jam milisaat.
    5. Saluran paip format berjalan selepas penjanaan. Anda boleh membuang sempang, beralih kepada huruf besar, membungkus nilai dalam pendakap ({…} — konvensyen Microsoft GUID), atau memaparkan 16 bait mentah sebagai base64 (output 22-aksara, tanpa padding). Mod base64 mengatasi pilihan format lain kerana base64 adalah representasinya sendiri.

    Mengapa menggunakan penjana UUID ini?

    • Tiada apa yang meninggalkan pelayar anda. API Web Crypto berjalan secara setempat; halaman tidak membuat permintaan rangkaian selepas muatan dokumen awal. Buka DevTools, klik Jana, dan panel Rangkaian kekal senyap.
    • Output betul-RFC. v4 mengikut RFC 4122 §4.4, v1 mengikut §4.2 dan §4.5, dan v7 mengikut RFC 9562 §5.7. Nibble versi dan bit varian diletakkan di mana piawai mengatakan ia harus — setiap UUID mengesahkan terhadap regex versi kanonik.
    • v7 boleh-isih untuk kunci pangkalan data. UUID v7 yang digunakan sebagai kunci utama berkelompok dalam Postgres, MySQL, atau SQL Server mengekalkan sisipan tambah-sahaja pada indeks — tiada pemisahan halaman, tiada I/O rawak — sambil masih unik secara global. v4 tidak boleh melakukan ini kerana bitnya rawak.
    • Penjanaan pukal tanpa had kadar. Jana 1, 10, 100, atau 1,000 UUID sekaligus. Tiada kuota dan tiada pendaftaran — alat berjalan dalam tab anda, jadi hadnya adalah CPU anda, bukan peringkat API vendor.

    Apakah aplikasi biasa UUID?

    UUID muncul di mana sahaja sistem memerlukan pengecam unik global tanpa berkoordinasi dengan pihak berkuasa pusat:

    • Kunci utama pangkalan data. Integer auto-meningkat membocorkan kiraan baris dan memecahkan sharding. UUID stabil merentasi shard, selamat untuk digabungkan merentasi rantau, dan (dengan v7) mengekalkan sisipan B-tree panas tanpa pemisahan halaman. Aplikasi biasa menjana UUID sisi klien, menghantarnya dalam sisipan, dan tidak perlu perjalanan pergi balik pelayan untuk kunci.
    • ID korelasi permintaan. Perisian tengah HTTP melampirkan UUID v4 pada setiap permintaan masuk, mencatatnya pada setiap rentang, dan menyebarkannya ke hilir (sering sebagai pengepala X-Request-Id). Apabila pelanggan melaporkan pepijat, jurutera sokongan menampal ID dan keseluruhan jejak permintaan muncul — merentasi perkhidmatan dan zon waktu — tanpa kekaburan.
    • Kunci idempoten. API pembayaran (Stripe, Adyen, Square) menerima pengepala Idempotency-Key supaya permintaan yang dicuba semula tidak pernah mengenakan caj pelanggan dua kali. UUID yang dijana klien menjamin kunci adalah unik per operasi logik, yang merupakan kontrak yang dikehendaki oleh API tersebut.

    Bagaimana rupa contoh UUID?

    Dalam Node.js atau pelayar moden, satu baris crypto.randomUUID() mengembalikan UUID v4 baharu — contohnya 3f50b5a8-2c54-4b9c-9c1f-3e5c7e2b8d12. Gunakan itu untuk ID permintaan atau kunci idempoten. Apabila UUID akan masuk ke dalam lajur pangkalan data yang akan menjadi kunci utama berkelompok, jana v7 sebaliknya: dua nilai v7 yang dihasilkan satu milisaat terpisah, seperti 0190a3b0-7d4f-7c9e-8b21-a4d6f0bd9c11 dan 0190a3b0-7d50-7f15-9c4e-72b3e0c1d8a4, mengisih secara leksikografi mengikut susunan penjanaan. Jenis uuid Postgres menyimpan kedua-dua versi secara sama — perbezaan muncul pada masa tulis indeks, di mana sisipan v7 ditambah di sebelah kanan B-tree manakala sisipan v4 berselerak dan memaksa I/O rawak.

    Penjana UUID ini melakukan satu tugas: tukar satu klik kepada satu atau banyak pengecam yang memenuhi RFC, diformat mengikut keperluan anda, tanpa menghantar permintaan anda ke pelayan. Pilih versi, pilih bilangan, pilih format — jana, salin, teruskan.