Alat pengembang · generator UUID
Dari 128 Bits hingga 36 Karakter: Cara Kerja UUID Pengkodean Teks
· Cara kerjanya
uuid kriptografi browser-apis
UUID adalah 16 bytes, namun bentuk familiarnya adalah 36 karakter. Posting ini menjelaskan penggandaan hex, tanda hubung, aturan kasus, dan pengkodean pendek yang digunakan orang ketika bentuk standar terlalu panjang.
Mengapa kolom lebih lebar daripada nilainya — nilai 16-byte yang memerlukan 36 karakter dalam teks dan apa artinya bagi URL dan penyimpanan
Lebar kolom penyimpanan meledak ketika Anda memilih format UUID. Nilai 128-bit adalah 16 bytes, namun representasi teksnya bergantung pada pengkodean: heksadesimal (36 karakter dengan tanda hubung, 32 tanpa), base64url (22 karakter), base58 (22–23 karakter), Crockford base32 (26 karakter). Jika skema Anda menyimpan UUID sebagai VARCHAR(36), Anda menghabiskan 36 karakter di setiap baris. Dalam tabel dengan 1 miliar baris dan tidak ada kolom lain, itu berarti 36 gigabyte overhead teks dibandingkan dengan 16 biner. Pilihannya bukan hanya sekedar kosmetik; ini memengaruhi ukuran kueri, perjalanan bolak-balik jaringan, dan tekanan cache. Format kanoniknya adalah 36 karakter: delapan digit hex, tanda hubung, empat digit hex, tanda hubung, empat digit hex, tanda hubung, empat digit hex, tanda hubung, dua belas digit hex.
Hex menggandakan semuanya — setiap byte menjadi dua karakter, dan empat tanda hubung melengkapi 36
Setiap byte menjadi tepat dua karakter heksadesimal (0–9, a–f). Tanda hubung ada untuk alasan keterbacaan dan warisan sejak UUID pertama kali ditentukan. Pengkodean heksadesimal menggandakan jumlah byte: 16 bytes menjadi 32 digit hex ditambah 4 tanda hubung. Ini adalah pengkodean paling lambat dan terpanjang, tetapi dapat dibaca manusia dan didukung di mana saja. Aturan kasus: RFC 9562 mengamanatkan huruf kecil untuk keluaran kanonik, namun masukan tidak peka huruf besar-kecil. Menyimpan huruf besar menyia-nyiakan peluang untuk melakukan normalisasi, jadi simpan huruf kecil dan bandingkan input dengan tidak peka huruf besar-kecil. Pengkodean base64url mewakili tiga byte sebagai empat karakter menggunakan alfabet karakter 64 (A–Z, a–z, 0–9, minus, garis bawah). Enam belas byte menjadi 21 karakter ditambah satu karakter padding, totalnya 22 karakter. Base64url menghapus padding dan karakter standar (plus dan garis miring) yang dicadangkan di URL.
Aturan huruf besar-kecil — huruf kecil pada keluaran, tidak peka huruf besar-kecil pada masukan, dan mengapa perbandingan huruf besar-kecil menyebabkan ketidakcocokan diam-diam
UUID dalam format base64url menyimpan 14 karakter dibandingkan dengan hex dan valid di URL tanpa pengkodean persen. Keuntungannya: kurang terbaca (huruf kecil terlihat seperti angka; b, 8, B, dan 8 mudah membingungkan). Base58 digunakan oleh Bitcoin dan blockchain lainnya dan menghilangkan karakter ambigu (0, O, I, l), sehingga menghasilkan 22–23 karakter namun tetap dapat dibaca. Crockford base32 (dirancang untuk format mirip ISBN checksum) menggunakan 26 karakter dan memprioritaskan kebenaran daripada singkatnya. Perangkap urutan byte Microsoft GUID berlaku untuk penyimpanan UUID di beberapa database. RFC 9562 menentukan urutan byte jaringan (big-endian) untuk semua byte. Beberapa konfigurasi Server Microsoft SQL menyimpan GUID dengan urutan byte little-endian di tiga bidang pertama.
Pengkodean yang lebih pendek — base64url dengan 22 karakter, base58 dan Crockford base32, dengan keunggulan dalam keterbacaan dan keamanan salin-tempel
Nilai 128-bit yang sama yang disimpan dalam big-endian dan little-endian menghasilkan string hex yang berbeda. UUID 550e8400-e29b-41d4-a716-446655440000 yang disimpan sebagai GUID Microsoft mungkin diambil sebagai 00840e55-9be2-d441-a716-446655440000 (byte 0–3 dan 4–5 dan 6–7 terbalik). Jika sistem Anda menjembatani antara sistem yang mematuhi RFC dan sistem Microsoft, Anda harus menyadari hal ini dan melakukan normalisasi pada batas atau dokumen format mana yang Anda gunakan di setiap kolom. Contoh praktis: v4 UUID 9b2e4f1a-4f3e-4c1a-8a7d-1b2c3d4e5f60 dalam heksadesimal menempati 36 karakter. Sebagai 16 bytes adalah 9b 2e 4f 1a 4f 3e 4c 1a 8a 7d 1b 2c 3d 4e 5f 60. Di base64url: dipecah menjadi potongan tiga byte, konversi ke base64, strip padding: my5PGk8-TBqKfRssPTRPX2A. Dalam heksadesimal tanpa tanda hubung: 9b2e4f1a4f3e4c1a8a7d1b2c3d4e5f60 (32 karakter).
Perangkap urutan byte Microsoft - bagaimana tiga kolom pertama GUID disimpan little-endian, sehingga byte yang sama dapat dicetak sebagai dua string berbeda
Base64url menyimpan 14 karakter; base58 akan menghemat kurang lebih sama; heksadesimal adalah standarnya. Pilih berdasarkan kasus penggunaan Anda: jika pengidentifikasi muncul di URL dan setiap karakter penting, gunakan base64url; jika muncul di log dan UI tempat manusia membacanya, gunakan bentuk kanonik heksadesimal; jika Anda sedang membangun sistem blockchain atau sistem terdistribusi yang mengutamakan checksumming, gunakan base58 atau Crockford base32. Saat memilih jenis kolom, simpan nilai yang mengoptimalkan pola akses Anda yang sebenarnya. Jika Anda sering menanyakan UUID dan memerlukan pencocokan peka huruf besar-kecil, simpan biner (16) dan biarkan database menangani representasinya. Jika Anda melakukan kueri berdasarkan substring (mencari UUID yang dimulai dengan awalan), heksadesimal lebih mudah dibaca dalam keluaran debug.
Contoh praktis - satu pengidentifikasi ditulis sebagai byte, hex kanonik, dan bentuk yang dipersingkat, menunjukkan setiap langkah konversi
Jika Anda mengekspor ke CSV dan mengirim email ke pengguna non-teknis, heksadesimal lebih mudah dikenali. Jika ruang Anda terbatas (aplikasi seluler dengan cache lokal), base64url atau base58 menghemat bandwidth. Generator ToolAcre menghasilkan format heksadesimal karakter 36 kanonik; jika Anda memerlukan pengkodean yang berbeda, pemeriksaan yang dibuat dengan baik masih berfungsi karena menormalkan representasi yang valid sebelum memeriksa format. Pertimbangan kinerja penting saat menyandikan atau mendekode jutaan UUID. Pengkodean heksadesimal sederhana: ubah setiap byte menjadi dua karakter dalam waktu O(1) per byte. Penguraian kode juga sama sederhananya. Pengkodean dan penguraian kode Base64 menggunakan tabel pencarian dan sedikit lebih lambat (kira-kira 2–3x lebih lambat dibandingkan hex per byte, bergantung pada perangkat keras dan implementasi). Base58 jauh lebih lambat karena pada dasarnya adalah konversi dasar dan memerlukan aritmatika modular.
Apa yang tidak tercakup di sini — pilihan kolom basis data seperti tipe uuid asli versus biner (16), dibahas secara terpisah
Jika sistem Anda menyandikan atau mendekode UUID dalam hot loop (pembuatan pengenal frekuensi tinggi, ekspor massal), heksadesimal lebih cepat. Jika pengkodean jarang terjadi dan penghematan karakter 14 penting, base64url adalah pilihan yang masuk akal. Generator ToolAcre mengeluarkan hex, sehingga Anda mendapatkan keunggulan kinerja tanpa mengorbankan kompatibilitas. Semantik perbandingan string berbeda berdasarkan pengkodean. UUID heksadesimal dapat dibandingkan sebagai string: 550e8400-e29b-41d4-a716-446655440000 < 550e8400-e29b-41d4-a716-446655440001 (perbandingan leksikografis berfungsi). UUID biner dapat dibandingkan sebagai byte: perbandingan byte demi byte sama dengan perbandingan numerik. Namun, UUID yang dikodekan Base64url dan base58 tidak mempertahankan urutan numerik dalam perbandingan string leksikografis. Jika sistem Anda mengandalkan pengurutan leksikografis UUID (pola yang sangat umum untuk membuat indeks atau kunci basis data), Anda harus menggunakan varian heksadesimal, biner, atau varian UUID yang dapat diurutkan (v6 atau v7).
Kesimpulan: pertahankan bentuk kanonik pada batasnya — generator ToolAcre menghasilkan UUID karakter 36 standar dan pemeriksaannya menerima string dalam bentuk itu
Generator ToolAcre saat ini menghasilkan UUID v4, yang tidak dapat diurutkan berdasarkan urutan pengkodean. Interoperabilitas memerlukan standarisasi pada satu pengkodean. Sistem yang menerima UUID dalam hex, base64, dan base58 secara bersamaan harus menormalkan semua input ke bentuk kanonik sebelum diproses. Hal ini mungkin terjadi tetapi menambah kompleksitas. API atau database eksternal mungkin memerlukan pengkodean khusus: beberapa API mengharapkan urn:uuid: hex dengan awalan, yang lain mengharapkan hex tanpa tanda hubung, yang lain mengharapkan base64url. Dokumentasikan ekspektasi pengkodean UUID sistem Anda dengan jelas dalam kontrak API. Generator ToolAcre selalu mengeluarkan hex kanonik; jika Anda memerlukan pengkodean lain, lakukan konversi secara eksplisit dan dokumentasikan trade-off (ruang, kinerja, keterbacaan, keterurutan) kepada tim.