Alat pengembang · generator UUID
GUID vs UUID: Penjelasan Microsoft tentang Kawat Gigi, Urutan Byte, dan Varian
· Latar belakang
uuid kriptografi browser-apis
GUID adalah nama Microsoft untuk UUID, namun tanda kurung kurawal, huruf besar, dan urutan byte dapat membuat pengidentifikasi yang sama terlihat berbeda di seluruh platform. Posting ini menjelaskan setiap perbedaan dan cara membandingkan dengan aman.
ID yang sama yang gagal cocok di seluruh sistem — layanan .NET dan layanan Java tidak setuju pada satu catatan
Layanan .NET menghasilkan GUID dan mengirimkannya ke layanan Java, yang mencoba mencocokkan nilainya dengan UUID dari PostgreSQL. Perbandingan string gagal, dan sistem melaporkan bahwa pengidentifikasi tidak cocok, meskipun ketiga layanan bekerja dengan 16 bytes dasar yang sama. Perbedaannya tampaknya hanya bersifat kosmetik—kurung kurung, casing, urutan byte—tetapi menyebabkan perbandingan string gagal dan membingungkan titik integrasi yang tidak menjadi normal pada batasnya. GUID adalah terminologi Microsoft untuk apa yang RFC 9562 sebut sebagai UUID: pengidentifikasi 128-bit dengan tata letak bit yang sama. Kedua nama tersebut mengacu pada struktur dasar yang sama, namun representasinya berbeda sehingga membuat pengembang terkejut. Memahami asal mula kebingungan akan mencegah bug integrasi.
GUID adalah UUID — format 128-bit yang digunakan bersama dan dari mana perbedaan penamaan berasal
GUID adalah singkatan dari Globally Unique Identifier dan Globally Unique Identifier dan merupakan nama yang digunakan Microsoft untuk standar RFC yang disebut sebagai UUID. Tata letak 128-bit dan sistem versi/variant identik. RFC 4122 dan RFC 9562 menentukan format dan arti UUID; Microsoft mengimplementasikannya dan menggunakan istilah GUID. Perbedaan penamaannya bersifat historis: Microsoft menggunakan GUID sebelum UUID distandarisasi oleh IETF, dan terminologi Microsoft masih melekat dalam ekosistem .NET. Pada tingkat bit, GUID dan UUID sepenuhnya dapat dipertukarkan. Pada tingkat pemformatan, penyajiannya berbeda: kode .NET sering kali menulis GUID dengan kurung kurawal dan huruf besar, sedangkan UUID kanonik RFC menggunakan huruf kecil dan tanpa kurung kurawal.
Tanda kurung kurawal dan huruf besar — formulir {XXXXXXXX-...} bergaya registri dan cara menormalkannya
UUID dalam bentuk RFC kanonik ditulis dalam delapan, empat, empat, empat, dan dua belas karakter heksadesimal huruf kecil yang dipisahkan dengan tanda hubung: 550e8400-e29b-41d4-a716-446655440000. A .NET GUID biasanya ditampilkan dengan kurung kurawal dan huruf besar: {550E8400-E29B-41D4-A716-446655440000}. Kawat gigi berasal dari format Windows Registry; huruf besar adalah konvensi tampilan. Kedua bentuk mewakili 128 bits yang identik. Untuk mencocokkan GUID dari .NET dengan UUID dari PostgreSQL, lepaskan kurung kurawal dan normalkan casing, lalu bandingkan stringnya. ToolAcre cek yang dibuat dengan baik menerima bentuk kanonik dan secara otomatis menghilangkan tanda kurung kurawal. Normalisasi adalah transformasi teks kecil yang mempertahankan semua makna.
Urutan byte campuran-endian — bagaimana tiga bidang pertama disimpan little-endian dalam struktur GUID, dan mengapa Guid.ToByteArray berbeda dari urutan byte RFC
Perbedaan berbahaya antara GUID dan UUID adalah urutan byte. RFC 9562 menetapkan bahwa tiga bidang pertama (8, 4, dan 4 grup heksadesimal) disimpan dalam urutan byte big-endian (jaringan). .NET Struktur panduan menyimpan tiga bidang pertama di little-endian: byte dibalik sebelum ditulis ke penyimpanan. 16 bytes yang sama, ketika ditulis dengan .NET Guid.ToByteArray() dan diinterpretasikan dengan kode yang sesuai dengan RFC, menghasilkan representasi teks yang sangat berbeda. A UUID 550e8400-e29b-41d4-a716-446655440000 dalam urutan RFC byte disimpan sebagai byte 55 0e 84 00 e2 9b 41 d4 a7 16 44 66 55 44 00 00.
Varian warisan Microsoft — arti c atau d pada karakter pertama grup keempat
Selain urutan byte, pengidentifikasi Microsoft lama terkadang menggunakan bidang varian non-standar. Jika RFC 9562 menentukan bahwa karakter pertama dari grup keempat harus 8, 9, a, atau b, GUID Microsoft lama mungkin menggunakan c, d, e, atau f. UUID ini masih valid, namun sesuai dengan varian lama yang ada sebelum standardisasi RFC. Jika Anda menemukan GUID dengan c atau d pada karakter pertama grup keempat, Anda memiliki nilai 128-bit yang valid dan tidak sesuai dengan bit varian RFC. .NET modern menghasilkan GUID yang sesuai dengan RFC, sehingga pengidentifikasi baru tidak akan menunjukkan masalah ini. Bit varian lama jarang terjadi tetapi penting untuk dikenali.
Contoh praktis — 16 bytes yang sama dirender dalam urutan RFC dan dalam urutan struktur GUID, menunjukkan dengan tepat karakter mana yang ditukar
Ambil UUID 550e8400-e29b-41d4-a716-446655440000 dan ubah menjadi .NET GUID bentuk array byte menggunakan konvensi little-endian. Dalam urutan RFC, bytenya adalah: kolom pertama (550e8400) sama dengan 55 0e 84 00, kolom kedua (e29b) sama dengan e2 9b, kolom ketiga (41d4) sama dengan 41 d4, kolom keempat dan kelima sama dengan a7 16 44 66 55 44 00 00. Di .NET little-endian: kolom pertama menjadi 00 84 0e 55, kolom kedua menjadi 9b e2, kolom ketiga menjadi d4 41, dan sisanya tetap dalam big-endian. Array byte penuh adalah 00 84 0e 55 9b e2 d4 41 a7 16 44 66 55 44 00 00. Jika sistem Java membaca byte ini dengan mengharapkan urutan RFC, sistem akan menafsirkannya sebagai 00840e55-9be2-d441-a716-446655440000.
Apa yang tidak tercakup di sini — SQL Server NEWSEQUENTIALID dan pemesanannya, yang merupakan topik penyimpanannya sendiri
SQL Perilaku fungsi server NEWSEQUENTIALID dan properti pengurutan pengidentifikasi spesifiknya adalah topik khusus lapisan penyimpanan dan basis data. Posting ini berfokus pada perbedaan format dan urutan byte pada tingkat aplikasi dan serialisasi. Penanganan UUID khusus database mendalam dan masalah urutan byte paling baik ditangani dalam dokumentasi khusus untuk platform database tersebut. Sistem database yang berbeda memiliki pendekatan dan pendekatan yang berbeda terhadap penyimpanan UUID, pengindeksan, pengurutan, dan dukungan asli. Beberapa database mendeteksi versi dan bit varian secara otomatis, sementara database lainnya memerlukan deklarasi tipe eksplisit dan penanganan urutan byte pada batas antara sistem dan penyimpanan.
Kesimpulan: normalkan pada batas — cek ToolAcre menerima bentuk kanonik, yang merupakan bentuk standarisasi saat bertukar ID
Normalisasikan pada batas ketika pengidentifikasi melewati batas sistem .NET/non-.NET. Hapus kurung kurawal, normalkan casing secara konsisten, dan tukar byte pada tiga kolom pertama jika byte berasal dari .NET Guid.ToByteArray(). Bentuk RFC kanonik adalah standar referensi: delapan, empat, empat, empat, dan dua belas karakter heksadesimal huruf kecil dengan tanda hubung, tanpa kurung kurawal, urutan byte big-endian. Saat bertukar dengan sistem .NET, setujui bentuk yang dinormalisasi dan terapkan konversi secara eksplisit dalam kode integrasi. Dokumentasikan penanganan urutan byte dan uji konversi secara menyeluruh. Kesamaan mendasar inti antara GUID dan UUID berarti sebagian besar 128 bits identik.