Alat pengembang · generator UUID
RFC 4122 vs RFC 9562: Apa yang Berubah dalam Standar 2024 UUID
· Latar belakang
uuid kriptografi browser-apis
Dua RFC dikutip untuk UUID dan keduanya tidak menyatakan hal yang sama. Postingan ini membahas apa yang RFC 9562 ditambahkan, diklarifikasi, dan tidak digunakan lagi sehubungan dengan RFC 4122.
RFC mana yang saya kutip? — kebingungan ketika dokumentasi dan perpustakaan mengacu pada standar yang berbeda
Dua RFC secara rutin dikutip dalam dokumentasi UUID, dan keduanya tidak menyatakan hal yang sama. RFC 4122, diterbitkan di 2005, mendefinisikan UUID dan lima versinya (v1 hingga v5). RFC 9562, diterbitkan di 2024, menghapuskan seluruh RFC 4122, memperjelas ambiguitas yang telah diatasi oleh praktisi, menambahkan tiga versi baru (v6, v7, v8), dan memperbarui panduan penerapan keacakan. Ketika sebuah perpustakaan mengutip RFC 4122, hal tersebut tidak salah—perpustakaan tersebut mungkin telah dirilis sebelum RFC 9562 diterbitkan atau pengelola mungkin tidak memperbarui dokumentasinya. Memeriksa RFC kutipan memberi tahu Anda kapan perpustakaan terakhir kali diperbarui secara signifikan. Saat menulis spesifikasi baru atau mengevaluasi implementasi, RFC 9562 adalah referensi normatif.
Menghapus, tidak mengganti format — semua yang valid di bawah RFC 4122 tetap valid; tata letak dan bit varian tidak berubah
RFC 9562 secara resmi sudah usang RFC 4122 sebagai dokumen referensi saat ini dengan tetap mempertahankan representasi 128-bit yang sudah dikenal, grup heksadesimal, posisi versi, dan tata letak varian utama. String UUID yang sudah ada tidak perlu diterbitkan ulang hanya karena ada RFC yang lebih baru. Migrasi praktisnya ada dalam dokumentasi, generator, dan kebijakan validasi: mengutip standar saat ini, memahami versi yang ditambahkan, dan memeriksa apakah kode lama bergantung pada ambiguitas yang diklarifikasi oleh revisi. Kompatibilitas masih harus diuji pada batas-batas sistem, terutama ketika perpustakaan membuat serialisasi struktur Microsoft GUID atau menerapkan serangkaian versi yang lebih sempit daripada yang dijelaskan oleh standar.
Tiga versi baru — v6 (pengurutan ulang waktu), v7 (pengurutan waktu Unix-epoch) dan v8 (ditentukan implementasi)
RFC 9562 menambahkan tiga versi baru ke standar. Versi 6 menyusun ulang bit stempel waktu v1 untuk menghasilkan pengidentifikasi yang dapat diurutkan secara leksikografis untuk kinerja basis data yang lebih baik. Versi 7 menggunakan stempel waktu milidetik Unix 48-bit diikuti dengan bit acak, memberikan pembuatan urutan waktu tanpa masalah privasi v1. Versi 8 adalah jalan keluar untuk tata letak yang ditentukan implementasi. Tak satu pun dari versi ini mengubah cara kerja v1-v5 atau apa maksudnya. UUID v1 dari 2005 dan UUID v7 dari 2024 dapat hidup berdampingan dalam database yang sama, masing-masing dengan bit versinya yang mengidentifikasi metode pembuatannya. Tiga versi baru ini membahas pola-pola umum yang muncul dalam praktik.
Maks UUID bergabung dengan Nil — nilai semua-F yang ditentukan bersama dengan nilai semua-nol
RFC 4122 mendokumentasikan Nil UUID (semua bit nol) sebagai nilai referensi khusus dalam contoh dan dokumentasi. RFC 9562 menyertakan definisi Nil yang sama tetapi secara formal mendefinisikan Max UUID (semua bit disetel ke satu) untuk batas rentang. Baik Nil maupun Max bukanlah versi 4 acak UUID karena keduanya tidak memiliki versi dan bit varian yang benar. Maks UUID berguna sebagai batas rentang atas dalam kueri basis data: WHERE uuid_column <= MAX_UUID cocok dengan semua UUID yang mungkin. Nil berguna sebagai penjaga untuk yang belum ditugaskan di kolom UUID yang dapat dibatalkan. RFC 9562 mendokumentasikan keduanya tanpa mewajibkan penggunaannya dalam data aplikasi.
Panduan yang diperjelas — saran eksplisit untuk menggunakan CSPRNG untuk bidang acak, pada penghitung monotonik dalam satu milidetik, dan untuk memilih versi yang diurutkan waktu untuk lokalitas basis data
Panduan praktik terbaik RFC 9562 membedakan resistensi tabrakan dari kemampuan yang tidak dapat diperkirakan. Bidang acak harus menggunakan sumber yang sesuai dengan model ancaman aplikasi, dan opacity sensitif terhadap keamanan memerlukan CSPRNG. Generator berbasis waktu memiliki masalah monotonisitas yang terpisah ketika beberapa pengidentifikasi berbagi satu cap waktu; standar ini menjelaskan penghitung dan presisi stempel waktu tambahan sebagai metode yang memungkinkan, masing-masing dengan aturan status dan rollover. Versi berdasarkan nama tetap merupakan pengidentifikasi deterministik, bukan bukti keaslian. Klarifikasi ini penting karena satu parser UUID dapat menerima semua tata letak meskipun persyaratan pembuatan dan properti pengungkapan informasinya berbeda.
Tempat munculnya ide ULID — bagaimana format komunitas memengaruhi desain v7
RFC 9562 mengatakan penulisnya menganalisis beberapa skema pengenal yang dapat diurutkan, termasuk ULID, Snowflake, dan KSUID, sambil mengembangkan tata letak baru. Hal ini mendukung kesimpulan sederhana: permintaan operasional untuk pengidentifikasi terdistribusi dan terurut berdasarkan waktu menginformasikan revisi tersebut. Hal ini tidak membuktikan bahwa satu format komunitas menyumbangkan tata letak bidang yang tepat ke versi 7. Kesamaan praktisnya sudah cukup untuk pekerjaan arsitektur: keluarga-keluarga ini menempatkan informasi waktu di dekat bagian depan sehingga pengurutan biasa dapat mempertahankan tatanan penciptaan yang luas, kemudian berbeda dalam pengkodean, koordinasi, dan perilaku dalam-tik. Pilih di antara mereka berdasarkan kompatibilitas ekosistem dan jaminan yang terdokumentasi, bukan karena klaim keturunan langsung.
Apa yang tidak tercakup di sini - perbedaan baris demi baris; posting ini mengikuti konsekuensi praktis bagi pelaksana
Postingan komprehensif ini membahas konsekuensi praktis dan penerapan RFC 9562 bagi pelaksana dan pengguna, bukan perbedaan baris demi baris terhadap RFC 4122. Spesifikasi lengkap tersedia dari badan standar dan layak dibaca untuk menerapkan penanganan UUID dalam bahasa atau platform—teks ini memberikan detail resmi di luar apa yang dapat dicakup oleh ikhtisar. Posting ini tidak menjelaskan mekanisme tingkat bit tentang bagaimana v6 menyusun ulang byte v1 atau bagaimana v7 mengkodekan Unix milidetik. Standar dan panduan implementasi tetap menjadi referensi otoritatif utama untuk setiap pertanyaan implementasi mengenai tata letak bit, pengkodean, atau verifikasi kepatuhan.
Kesimpulan: perbarui kutipan dan default Anda — generator ToolAcre mengikuti panduan CSPRNG yang dibagikan oleh kedua RFC
Untuk setiap karya baru, perbarui dokumentasi dan spesifikasi dengan mengutip RFC 9562. Setiap UUID dari RFC 4122 tetap berlaku berdasarkan RFC 9562—migrasi murni bersifat proyeksi ke depan dan bersifat administratif. Panduan yang diperjelas tentang keacakan kriptografi memperkuat bahwa pengidentifikasi harus berasal dari sumber yang aman secara kriptografis dalam sistem produksi. ToolAcre mengikuti panduan keacakan kriptografi dari kedua RFC, menggunakan Web Crypto browser API secara eksklusif. Saat Anda menemukan UUID dari log, ekspor database, atau respons API, cek ToolAcre yang dibuat dengan baik melaporkan versi dan variannya terhadap RFC 9562. RFC 9562 adalah klarifikasi dan modernisasi dari standar yang sudah stabil.