Alat pembangun · UUID penjana
Perkara yang Membuatkan UUID Rentetan Terbentuk dengan Baik, dan Perkara Yang Tidak Dapat Diketahui Pemeriksa
· Bagaimana ia berfungsi
uuid kriptografi pelayar-apis
Huruf besar, pendakap, urn: awalan dan tanda sempang yang tiada semuanya muncul dalam input sebenar. Catatan ini mentakrifkan bentuk kanonik, menunjukkan perkara yang harus diterima oleh pengesah yang berlembut, dan memisahkan bentuk yang baik daripada kewujudan.
400 yang sepatutnya menjadi 404 — betapa cerobohnya pengesahan UUID menghasilkan ralat API yang mengelirukan
Titik akhir API menerima pengecam daripada klien: {12345678-90AB-CDEF-1234-567890ABCDEF}. Kod pengesahan menyemak sama ada ia sepadan dengan /[0-9a-f]{32}/ dan menolaknya sebagai tidak sah. Pelanggan mendapat 400 Permintaan Buruk di mana 404 Not Found dimaksudkan. Pengecam telah dibentuk dengan baik—ia adalah UUID yang sah dalam format pendakap—tetapi pengesah terlalu ketat. Sebaliknya, titik akhir yang menerima sebarang rentetan hex aksara 32 (tanpa sempang) akan menerima 123456789012345678901234567890123456, menghuraikannya sebagai sah dan terlepas kesilapan menaip. RFC 9562 mentakrifkan perwakilan teks berkanun, tetapi input dunia sebenar tiba dalam lima format berbeza dan pengesah yang sahaja menerima borang berkanun akan menolak 1 kepada 5 peratus input yang bertujuan baik.
Bentuk teks kanonik — 32 digit hex huruf kecil dalam 8-4-4-4-12, betul-betul 36 ciri-ciri standard.
Bentuk teks kanonik ialah 32 digit heksadesimal huruf kecil dalam lima kumpulan yang dipisahkan oleh tanda sempang: 8-4-4-4-12. Diwakili sebagai 550e8400-e29b-41d4-a716-446655440000. Standard mewajibkan huruf kecil untuk output; pada input, padanan tidak sensitif huruf besar dan kecil adalah disyorkan. Borang ini tidak jelas, menghuraikan ke dalam bait dengan cara yang sama pada setiap platform dan adalah apa yang dikeluarkan oleh setiap UUID perpustakaan secara lalai. Jika anda menjana UUID baharu daripada CSPRNG, bentuk kanonik ialah perkara yang perlu anda hasilkan dan apa yang dihasilkan ToolAcre. Input dunia sebenar menyimpang dalam cara yang boleh diramal. Pengecam huruf besar (550E8400-E29B-41D4-A716-446655440000) adalah perkara biasa daripada sistem yang lalai kepada huruf besar; ia mewakili bait yang sama dan harus diterima selepas penormalan kepada huruf kecil.
Varian yang akan anda temui di alam liar — hex huruf besar, {braces}, urn:uuid: awalan dan 32-bentuk tanpa sempang aksara, dan yang dikatakan diterima oleh standard
Borang pendakap ({550e8400-e29b-41d4-a716-446655440000}) ialah output standard daripada modul uuid Python dan sistem Microsoft; menanggalkan pendakap memberikan bentuk kanonik yang sah. Awalan URN (urn:uuid:550e8400-e29b-41d4-a716-446655440000) ditakrifkan oleh RFC 8141 untuk nama sumber seragam; mengalih keluar skema dan awalan pengecam pelucutan meninggalkan bentuk kanonik. Bentuk tanpa sempang (550e8400e29b41d4a716446655440000) ialah 32 digit heks tanpa struktur; ia adalah bait yang sah tetapi kehilangan 8-4-4-4-12 yang menjadikan versi dan varian boleh dibaca. Semua varian ini dipetakan kepada nilai 128-bit yang sama. RFC 9562 bahagian 3 menyatakan bahawa pada input, varian huruf besar SHOULD diterima. Ia tidak melarang varian lain; ia mengatakan bahawa pada output, bentuk huruf kecil kanonik MUST digunakan.
Versi dan varian kewarasan — sama ada untuk menolak UUID yang kumpulan ketiganya bermula dengan 0 atau kumpulan keempatnya bermula dengan f
Pengesah yang dibentuk dengan baik hendaklah: menerima borang 8-4-4-4-12 berkanun dalam huruf kecil atau besar; terima braced dan urn: varian dengan menanggalkannya dan mengesahkan bentuk teras; terima rentetan heks 32-digit tanpa sempang dan formatkannya sebagai kanonik untuk perbandingan; menolak rentetan dengan bilangan digit heks atau aksara bukan heksadesimal yang salah. Kesilapan yang paling biasa ialah menolak input huruf besar atau pendakap kerana pengesah telah ditulis tangan untuk memadankan bentuk kanonik sahaja. Semakan kewarasan pada versi dan varian boleh menangkap kesilapan. Jika kumpulan ketiga bermula dengan 0 atau 9, UUID adalah tidak sah atau terpelihara; jika kumpulan keempat bermula dengan e atau f, varian itu bukan RFC 9562.
Contoh yang berkesan — enam rentetan calon dijalankan melalui pemeriksaan yang ketat dan yang ringan, dengan sebab masing-masing lulus atau gagal
Pengesah yang berlembut menerima nilai ini; pengesah yang ketat boleh menolaknya. Semakan ToolAcre yang dibentuk dengan baik melakukan pengesahan yang ketat: ia mengesahkan bentuk aksara 36 berkanun dengan tanda sempang di tempat yang betul, mengesahkan digit heks dalam setiap kedudukan dan menyemak sama ada versi dan bit varian berada dalam julat. Ia tidak menyemak sama ada UUID wujud dalam pangkalan data anda atau ia dijana daripada sumber selamat secara kriptografi; itu adalah semakan berasingan yang dilakukan oleh logik aplikasi anda. Berbentuk elok tidak sama dengan sebenar. Rentetan UUID yang menghuraikan dengan betul mengikut bentuknya mungkin tidak mengenal pasti sebarang baris dalam pangkalan data anda.
Pembentukan yang baik adalah tidak nyata — sebab UUID yang sempurna dari segi sintaksis mungkin tidak wujud dalam data anda dan sebab penyemak tidak boleh menjadi lapisan kebenaran anda
A UUID yang terbentuk dengan sempurna mungkin telah diteka atau disalin dengan salah. Pengesahan format ialah pintu pertama; semakan kewujudan dan semakan kebenaran adalah yang kedua dan ketiga. Menjalankan carian terhadap pangkalan data untuk setiap input tidak sah format adalah membazir; menolak input format-tidak sah sebelum pertanyaan pangkalan data menjimatkan masa. ToolAcre standard output penjana 36-watak UUID; jika anda sedang membina pengesah anda sendiri, terima varian braced dan urn: untuk memadankan input dunia sebenar dan tolak rentetan yang gagal dalam peraturan bentuk asas sebelum bertanya kepada pangkalan data anda. Melaksanakan pengesah yang ketat memerlukan ungkapan biasa dan pengendalian huruf tepi. Bentuk kanonik adalah 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-besaran). Bentuk pendakap menambah pendakap kerinting: /^\{[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\}$/i. Varian urn: menambah skema: /^urn:uuid:[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i.
Perkara ini tidak meliputi — menormalkan ID untuk storan dan memilih jenis lajur, yang merupakan keputusan berasingan
Regex tunggal yang mengendalikan semua varian kurang boleh dibaca tetapi mungkin. Kebanyakan pengesah menormalkan dahulu: pendakap jalur dan urn: awalan, tukar kepada huruf kecil, kemudian padankan dengan corak kanonik. Versi dan bit varian boleh disemak selepas padanan corak dengan memeriksa kedudukan 14 dan kedudukan 19 seperti yang diterangkan dalam artikel 403. Mengendalikan input tidak sah dengan anggun adalah sebahagian daripada reka bentuk pengesahan. Apabila pelanggan menyerahkan UUID yang cacat, jangan dedahkan corak regex atau peraturan pengesahan dalaman dalam mesej ralat. Kembalikan ralat yang jelas: "Format UUID tidak sah. Format 8-4-4-4-12 yang dijangkakan, seperti 550e8400-e29b-41d4-a716-446655440000 " Jangan cuba membetulkan input; minta klien untuk menyerahkan semula.
Bawa pulang: sahkan bentuk awal, cari kewujudan secara berasingan — semakan ToolAcre mengesahkan bentuk dalam pelayar sebelum anda menyentuh pangkalan data
Sesetengah sistem log masuk input tidak sah untuk pengauditan keselamatan (mengesan percubaan suntikan atau serangan kekeliruan format). Pengesah ToolAcre menolak borang bukan kanonik dengan mesej ralat yang jelas dan tidak cuba membetulkan secara automatik. Mengapa borang kanonik penting untuk kebolehoperasian: jika satu sistem menyimpan UUID sebagai heks tanpa sempang dan satu lagi menyimpannya sebagai kanonik 8-4-4-4-12 memerlukan penormalan untuk equality. Huruf besar vs huruf kecil memerlukan perbandingan tidak sensitif huruf besar. Braced vs bare memerlukan pelucutan. Variasi ini menjadikan operasi pukal (import, migrasi, perbandingan) lebih sukar. Alat piawai yang mengeluarkan bentuk kanonik mengurangkan geseran. Penjana ToolAcre sentiasa mengeluarkan bentuk kanonik huruf kecil 36; apabila anda mengimport UUID daripada sistem lain, normalkannya kepada borang ini dalam proses ETL anda untuk memastikan konsistensi.