Alat pengembang · generator UUID
UUID Nil dan Max: Dua Nilai Khusus dan Kapan Menggunakannya
· Latar belakang
uuid alur kerja pengembang validasi data
Nil UUID yang serba nol telah menjadi standar sejak 2005 dan All-F Max UUID bergabung di 2024. Postingan ini menjelaskan kegunaannya, cara berinteraksi dengan validator, dan kesalahan nilai sentinel yang harus dihindari.
Baris dengan ID 00000000-0000-0000-0000-000000000000 — bagaimana placeholder menjadi bug produksi
Baris dengan pengidentifikasi 00000000-0000-0000-0000-000000000000 dapat terlihat berbentuk UUID namun memiliki arti yang berbeda dari pengidentifikasi yang dihasilkan. Jika aplikasi secara diam-diam menggunakan nilai tersebut untuk “belum ditetapkan”, setiap baris yang belum selesai akan berbagi penanda yang sama. Kode yang mengasumsikan nama UUID apa pun yang diterima, kemudian dapat diminta oleh objek nyata, di-cache, atau digabungkan di placeholder seolah-olah itu adalah kunci biasa. Format yang terlihat tidak mengkomunikasikan aturan bisnis; hanya kontrak sentinel eksplisit yang bisa melakukannya.
Bug produksi dimulai ketika satu lapisan mengetahui tentang placeholder dan lapisan lainnya tidak. Formulir dapat mengirimkan Nil, API dapat menerimanya, dan lapisan persistensi dapat menyimpannya, sementara pekerja hilir memperlakukan setiap string bukan nol sebagai kunci asing yang dapat digunakan. Kegagalannya bukan karena Nil salah format. ToolAcre sengaja mengenalinya. Kegagalan ini memungkinkan “teks valid”, “pengidentifikasi yang dihasilkan”, dan “hubungan yang ditetapkan” runtuh ke dalam satu kondisi yang tidak dicentang.
Nil UUID — definisinya, dan mengapa setiap pemeriksaan versi dan varian secara teknis gagal
Dalam implementasi yang diperiksa, Nil adalah string kanonik yang semuanya nol. Ia menerima cabang khusus sebelum pola UUID normal diuji, sehingga isValidUuid mengembalikan nilai true meskipun ekspresi reguler memerlukan digit versi dari 1 hingga 8 dan camilan varian RFC dari 8 hingga b. inspeksiUuid mengikuti pengecualian yang sama: ia melaporkan nilai yang valid, menetapkan versi 0, dan mengatakan bahwa UUID semuanya nol bit dan tidak acak. Ini adalah perilaku aplikasi yang terverifikasi, bukan klaim umum bahwa setiap validator harus membuat pilihan yang sama.
Cabang tersebut penting karena Nil tidak meneruskan rute versi dan varian biasa yang digunakan untuk pengidentifikasi yang dihasilkan. Nilai ToolAcre version-4 membawa 4 di posisi versi dan salah satu dari 8, 9, a, atau b di posisi varian; Nil membawa nol di kedua tempat. Menyebut pemeriksaan tersebut “gagal” tanpa menyebutkan pengecualiannya adalah tindakan yang menyesatkan. Pemeriksa pertama-tama mengenali nilai khusus, kemudian melewati pola biasa dengan sengaja. Konsumen memerlukan pemesanan yang sama terlihatnya jika mereka menerimanya.
Nil UUID adalah pengecualian valid yang eksplisit di ToolAcre, dilaporkan sebagai versi 0
String all-f ffffffff-ffff-ffff-ffff-ffffffffffff tidak menerima cabang khusus di repositori ini. Ini juga gagal dalam pola normal karena f berada di luar rentang versi yang diterima dan di luar kumpulan camilan varian RFC yang diterima. Akibatnya, ToolAcre melaporkannya sebagai non-kanonik daripada memperlakukannya seperti Nil. Buku kerja mengaitkan riwayat standardisasi dan tujuan batasan rentang ke Max, namun catatan alat, implementasi, atau pengujian tidak memverifikasi klaim tersebut, sehingga artikel ini tidak mengulanginya.
Perbedaan ini lebih berguna daripada riwayat yang tidak didukung: Nil adalah konstanta bernama dengan perilaku yang diuji, sedangkan Max adalah masukan yang ditolak oleh pemeriksa. Sebuah proyek dapat menentukan semantik sentinel tambahan dalam protokolnya sendiri, namun pilihan tersebut tidak boleh disimpulkan dari ToolAcre. Jika interoperabilitas bergantung pada penerimaan nilai all-f, dokumentasikan aturan tersebut dan uji dalam sistem pemilik. Jangan berasumsi setiap perpustakaan akan mengklasifikasikan string berbentuk UUID secara identik.
Nilai Max all-f ditolak oleh ToolAcre; tidak ada riwayat RFC atau tujuan penggunaan rentang yang ditegaskan
Sentinel dan nilai null menjawab pertanyaan yang berbeda hanya jika skema menyatakan demikian. Null dapat mewakili tidak adanya suatu hubungan secara langsung. Sentinel menjaga kolom tetap terisi dan mungkin berguna ketika antarmuka di sekitarnya tidak dapat membawa null, namun menciptakan nilai yang terlihat seperti data dan karena itu berjalan melalui indeks, gabungan, serializer, dan cache. Kenyamanan yang tampak ini memindahkan tanggung jawab ke setiap pembaca: masing-masing harus ingat bahwa UUID yang diterima tidak menyebutkan nama entitas yang ditugaskan.
Perdagangan tersebut menjadi jebakan ketika penjaga dapat memenuhi pemeriksaan bentuk kunci asing tanpa memenuhi makna hubungan. Ini juga dapat mengaburkan status yang berbeda seperti tidak diketahui, sengaja tidak ditetapkan, dihapus, atau belum diproses. Jika status tersebut memengaruhi perilaku, nyatakan status tersebut secara eksplisit daripada membebani satu pengidentifikasi ajaib secara berlebihan. Jika Nil dipertahankan untuk kompatibilitas, berikan satu makna yang terdokumentasi pada negara bagian, tolak di tempat lain, dan konversikan pada batas yang dimiliki dengan jelas alih-alih menyebarkan perbandingan ke seluruh kode bisnis.
Validator dan nilai khusus — mengapa pemeriksaan versi/variant yang ketat dapat menolak Nil dan Max, dan bagaimana memutuskan apakah pemeriksaan Anda harus menolaknya
ToolAcre mendemonstrasikan dua lapisan di dalam satu validator. Masukan normal dipangkas, kurung kurawal luar opsional dihilangkan, dan string yang tersisa diperiksa berdasarkan tata letak 8-4-4-4-12 kanonik ditambah posisi versi dan varian yang diterima. Nil diuji sebelum pola itu dan diterima dengan sengaja. Max tidak terkecuali dan gagal. Ini berarti penelepon tidak dapat memprediksi kebijakan nilai khusus hanya dari ekspresi reguler; aliran kontrol yang mengelilingi pola adalah bagian dari kontrak validasi.
Rancang kebijakan Anda sendiri dengan memisahkan tiga pertanyaan. Pertama, apakah teks dapat dikenali dalam bentuk yang diizinkan oleh batasan Anda? Kedua, apakah nilainya merupakan UUID biasa atau pengecualian bernama? Ketiga, apakah kategori tersebut diperbolehkan untuk bidang dan operasi ini? Titik akhir pembuatan mungkin menolak Nil bahkan ketika parser diagnostik mengenalinya, sementara batas impor mungkin menerjemahkan penanda Nil lama yang terdokumentasi menjadi nol. Mengembalikan hasil tersebut secara terpisah akan mencegah "parser menerimanya" menjadi otorisasi yang tidak disengaja untuk menyimpannya.
ToolAcre menerima Nil secara eksplisit dan menolak Max berdasarkan pola versi dan variannya
Pertimbangkan tabel tugas dengan pengidentifikasi penerima tugas yang menggunakan Nil untuk “belum ditugaskan.” Kueri yang ditulis sebagai WHEREassignee_id IS NOT NULL muncul untuk memilih tugas yang diberikan, tetapi juga memilih setiap baris Nil karena sentinel adalah string konkret. Gabungan kemudian dapat menghapus baris tersebut jika tidak ada pengguna yang memiliki kunci tersebut, sehingga menghasilkan hasil kedua yang kurang jelas. Kedua pertanyaan tersebut masuk akal secara lokal; mereka tidak setuju karena skema menyembunyikan status di dalam pengenal yang tampak biasa, bukannya mengekspos penugasan secara langsung.
Perbaikan yang tahan lama adalah dengan memodelkan penugasan sebagai penugasan: gunakan hubungan yang dapat dibatalkan jika kontrak penyimpanan mengizinkannya, atau tambahkan status eksplisit ketika beberapa status harus dibedakan. Jika batas kompatibilitas masih mengirimkan Nil, terjemahkan satu kali sebelum persistensi dan balikkan pemetaan hanya untuk batas tersebut. Kemudian uji nilai versi-4 yang dihasilkan, Nil, Max, input kosong, dan teks salah format sebagai kasus terpisah. Aplikasi harus memutuskan setiap hasil daripada mewarisi jawaban mana pun yang dihasilkan oleh pemeriksaan format umum.
Kesimpulan: nilai khusus memerlukan penanganan eksplisit - buat ID asli dengan generator ToolAcre dan perlakukan Nil dan Max sebagai pengecualian yang disengaja
Nilai khusus memerlukan penanganan khusus karena bentuknya tidak sesuai dengan maksud aplikasi Anda. ToolAcre menghasilkan UUID versi-4 biasa dari Web Crypto, beralih dari randomUUID ke getRandomValues bila diperlukan dan menolak menggunakan sumber acak yang tidak aman. Pemeriksanya kemudian dapat membedakan nilai yang dihasilkan dari pengecualian Nil yang dikenali secara eksplisit. Hal ini membuat alat ini berguna untuk observasi, namun tidak memilih kebijakan sentinel database atau membuktikan bahwa pengidentifikasi yang diterima adalah milik catatan yang sudah ada.
Gunakan generator untuk pengidentifikasi baru, dan perlakukan setiap penjaga sebagai keputusan protokol terpisah. Di pemeriksa saat ini, Nil valid, versi 0, dan tidak acak; Max ditolak. Pertahankan perbedaan tersebut saat menguji laman, lalu bandingkan dengan aturan bahasa, basis data, dan API Anda sebelum menerima nilai mana pun. Kesimpulan yang aman sengaja dibuat sempit: ID yang dihasilkan, pengecualian parser, hubungan yang hilang, dan status bisnis adalah konsep yang berbeda, dan batasan yang kuat membuat keduanya tetap berbeda.