Alat pengembang · generator UUID
Apa yang Membuat String UUID Terbentuk dengan Baik, dan Apa yang Tidak Dapat Diketahui oleh Pemeriksa
· Cara kerjanya
uuid kriptografi browser-apis
Huruf besar, kurung kurawal, guci: awalan dan tanda hubung yang hilang semuanya muncul di masukan sebenarnya. Posting ini mendefinisikan bentuk kanonik, menunjukkan apa yang harus diterima oleh validator yang lunak, dan memisahkan bentukan yang baik dari keberadaan.
400 yang seharusnya menjadi 404 — betapa cerobohnya validasi UUID menghasilkan kesalahan API yang membingungkan
Titik akhir API menerima pengidentifikasi dari klien: {12345678-90AB-CDEF-1234-567890ABCDEF}. Kode validasi memeriksa apakah cocok dengan /[0-9a-f]{32}/ dan menolaknya sebagai tidak valid. Klien mendapat 400 Permintaan Buruk yang dimaksud dengan 404 Tidak Ditemukan. Pengidentifikasinya dibuat dengan baik—ini adalah UUID yang valid dalam format kurung kurawal—tetapi validatornya terlalu ketat. Sebaliknya, titik akhir yang menerima string hex berkarakter 32 (tanpa tanda hubung) akan menerima 123456789012345678901234567890123456, menguraikannya sebagai valid, dan salah ketik. RFC 9562 mendefinisikan representasi tekstual kanonik, namun masukan di dunia nyata hadir dalam lima format berbeda, dan validator yang hanya menerima bentuk kanonik akan menolak 1 hingga 5 persen masukan yang bermaksud baik.
Bentuk teks kanonik — 32 digit hex huruf kecil dalam 8-4-4-4-12, persis 36 karakter, sesuai standar yang ditetapkan untuk keluaran
Bentuk teks kanoniknya adalah 32 digit heksadesimal huruf kecil dalam lima kelompok yang dipisahkan oleh tanda hubung: 8-4-4-4-12. Diwakili sebagai 550e8400-e29b-41d4-a716-446655440000. Standar ini mengamanatkan huruf kecil untuk keluaran; pada masukan, pencocokan peka huruf besar-kecil direkomendasikan. Formulir ini tidak ambigu, diurai menjadi byte dengan cara yang sama di setiap platform, dan merupakan keluaran setiap perpustakaan UUID secara default. Jika Anda membuat UUID baru dari CSPRNG, bentuk kanonik adalah apa yang harus Anda hasilkan dan apa yang ToolAcre hasilkan. Masukan di dunia nyata menyimpang dengan cara yang dapat diprediksi. Pengidentifikasi huruf besar (550E8400-E29B-41D4-A716-446655440000) umum digunakan pada sistem yang menggunakan huruf besar secara default; mereka mewakili byte yang sama dan harus diterima setelah normalisasi menjadi huruf kecil.
Varian yang akan Anda temui di alam liar — hex huruf besar, {braces}, awalan urn:uuid: dan 32 karakter bentuk tanpa tanda hubung, dan yang menurut standar harus diterima
Formulir yang diberi tanda kurung ({550e8400-e29b-41d4-a716-446655440000}) adalah keluaran standar dari modul uuid Python dan sistem Microsoft; menghapus kurung kurawal memberikan bentuk kanonik yang valid. Awalan URN (urn:uuid:550e8400-e29b-41d4-a716-446655440000) ditentukan oleh RFC 8141 untuk nama sumber daya yang seragam; menghapus awalan skema dan pengenal stripping meninggalkan bentuk kanonik. Bentuk tanpa tanda hubung (550e8400e29b41d4a716446655440000) adalah 32 digit hex tanpa struktur; ini adalah byte yang valid tetapi kehilangan pengelompokan 8-4-4-4-12 yang membuat versi dan varian dapat dibaca. Semua varian ini dipetakan ke nilai 128-bit yang sama. RFC 9562 bagian 3 menyatakan bahwa pada masukan, varian huruf besar SHOULD diterima. Ia tidak melarang varian lain; dikatakan bahwa pada keluaran, bentuk huruf kecil kanonik MUST digunakan.
Kewarasan versi dan varian — apakah akan menolak UUID yang grup ketiganya dimulai dengan 0 atau yang grup keempatnya dimulai dengan f
Validator yang baik harus: menerima formulir 8-4-4-4-12 kanonik dalam huruf kecil atau besar; terima kurung kurawal dan guci: varian dengan menghapusnya dan memvalidasi formulir inti; menerima string hex 32 digit tanpa tanda hubung dan memformatnya sebagai kanonik untuk perbandingan; menolak string dengan jumlah digit heksadesimal atau karakter non-heksadesimal yang salah. Kesalahan paling umum adalah menolak input huruf besar atau kurung kurawal karena validator ditulis tangan untuk mencocokkan bentuk kanonik saja. Pemeriksaan kewarasan pada versi dan varian dapat menemukan kesalahan ketik. Jika grup ketiga dimulai dengan 0 atau 9, UUID tidak valid atau dicadangkan; jika kelompok keempat dimulai dengan e atau f, variannya bukan RFC 9562.
Contoh praktis - enam jaringan kandidat menjalani pemeriksaan yang ketat dan yang lunak, dengan alasan masing-masing lolos atau gagal
Validator yang lunak menerima nilai-nilai ini; validator yang ketat dapat menolaknya. Pemeriksaan ToolAcre yang dibuat dengan baik melakukan validasi yang ketat: pemeriksaan ini mengonfirmasi bentuk karakter 36 kanonik dengan tanda hubung di tempat yang tepat, memverifikasi digit hex di setiap posisi, dan memeriksa apakah bit versi dan varian berada dalam jangkauan. Itu tidak memeriksa apakah UUID ada di database Anda atau dihasilkan dari sumber yang aman secara kriptografis; itu adalah pemeriksaan terpisah yang dilakukan oleh logika aplikasi Anda. Yang terbentuk dengan baik tidak sama dengan yang asli. String UUID yang diurai dengan benar menurut bentuknya mungkin tidak mengidentifikasi baris apa pun di database Anda.
Bentuk yang baik tidaklah nyata — mengapa UUID yang sempurna secara sintaksis mungkin tidak ada dalam data Anda, dan mengapa pemeriksa tidak boleh menjadi lapisan otorisasi Anda
A UUID yang terbentuk sempurna mungkin saja salah menebak atau salah copy paste. Validasi format adalah gerbang pertama; pemeriksaan keberadaan dan pemeriksaan otorisasi adalah yang kedua dan ketiga. Menjalankan pencarian terhadap database untuk setiap input yang formatnya tidak valid adalah hal yang sia-sia; menolak input yang formatnya tidak valid sebelum kueri database menghemat waktu. Itu ToolAcre standar keluaran generator 36-UUID karakter; jika Anda membuat validator sendiri, terima varian braced dan urn: untuk mencocokkan input dunia nyata, dan tolak string yang gagal dalam aturan bentuk dasar sebelum menanyakan database Anda. Menerapkan validator yang ketat memerlukan ekspresi reguler dan penanganan kasus tepi. Bentuk kanoniknya sangat mudah: /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i (tidak peka huruf besar-kecil). Bentuk kurung kurawal menambahkan kurung kurawal: /^\{[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\}$/i. Varian urn: menambahkan skema: /^urn:uuid:[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i.
Apa yang tidak tercakup di sini — menormalisasi ID untuk penyimpanan dan memilih jenis kolom, yang merupakan keputusan terpisah
Sebuah regex tunggal yang menangani semua varian kurang mudah dibaca tetapi memungkinkan. Kebanyakan validator melakukan normalisasi terlebih dahulu: lepaskan kurung kurawal dan urn: awalan, ubah menjadi huruf kecil, lalu cocokkan dengan pola kanonik. Bit versi dan varian dapat diperiksa setelah pencocokan pola dengan memeriksa posisi 14 dan posisi 19 seperti yang dijelaskan dalam artikel 403. Menangani masukan yang tidak valid dengan baik adalah bagian dari desain validasi. Saat klien mengirimkan UUID dengan format yang salah, jangan tampilkan pola regex atau aturan validasi internal dalam pesan kesalahan. Menampilkan kesalahan yang jelas: "Format UUID tidak valid. Format 8-4-4-4-12 yang diharapkan, misalnya 550e8400-e29b-41d4-a716-446655440000." perbaiki masukannya; meminta klien untuk mengirimkan ulang.
Kesimpulan: validasi bentuk lebih awal, cari keberadaannya secara terpisah — tanda ToolAcre mengonfirmasi bentuk di browser sebelum Anda menyentuh database
Beberapa sistem mencatat masukan yang tidak valid untuk audit keamanan (mendeteksi upaya injeksi atau serangan kebingungan format). Validator ToolAcre menolak formulir non-kanonik dengan pesan kesalahan yang jelas dan tidak mencoba melakukan koreksi otomatis. Mengapa bentuk kanonik penting untuk interoperabilitas: jika satu sistem menyimpan UUID sebagai hex tanpa tanda hubung dan sistem lain menyimpannya sebagai 8-4-4-4-12 kanonik, membandingkannya untuk kesetaraan memerlukan normalisasi. Huruf besar vs huruf kecil memerlukan perbandingan yang tidak peka huruf besar-kecil. Diperkuat vs telanjang membutuhkan pengupasan. Variasi ini membuat operasi massal (impor, migrasi, perbandingan) menjadi lebih sulit. Alat standar yang menghasilkan bentuk kanonik mengurangi gesekan. Generator ToolAcre selalu menampilkan bentuk kanonik huruf kecil 36 karakter; saat Anda mengimpor UUID dari sistem lain, normalkan UUID tersebut ke formulir ini dalam proses ETL Anda untuk memastikan konsistensi.