วิธีสร้างแนวทางกำหนด

ในแอปพลิเคชันของเราเรากำลังสร้างไฟล์ Xml ด้วยแอตทริบิวต์ที่มีค่า Guid ค่านี้จำเป็นเพื่อให้สอดคล้องกันระหว่างการอัพเกรดไฟล์ ดังนั้นแม้ว่าทุกอย่างในไฟล์จะเปลี่ยนไป แต่ค่า guid สำหรับแอตทริบิวต์ก็ควรจะยังคงเหมือนเดิม

วิธีแก้ปัญหาที่ชัดเจนวิธีหนึ่งคือการสร้างพจนานุกรมแบบคงที่พร้อมชื่อไฟล์และคำแนะนำที่จะใช้สำหรับพวกเขา จากนั้นเมื่อใดก็ตามที่เราสร้างไฟล์เราจะค้นหาชื่อไฟล์ในพจนานุกรมและใช้คำแนะนำที่เกี่ยวข้อง แต่ไม่สามารถทำได้เนื่องจากเราอาจปรับขนาดเป็น 100 ไฟล์และไม่ต้องการรักษารายการคำแนะนำจำนวนมาก

ดังนั้นอีกวิธีหนึ่งคือทำให้ Guid เหมือนกันตามพา ธ ของไฟล์ เนื่องจากเส้นทางไฟล์และโครงสร้างไดเร็กทอรีแอ็พพลิเคชันของเราไม่ซ้ำกัน Guid จึงควรไม่ซ้ำกันสำหรับพา ธ นั้น ดังนั้นทุกครั้งที่เราทำการอัปเกรดไฟล์จะได้รับคำแนะนำเดียวกันตามเส้นทางของมัน ฉันพบวิธีที่ยอดเยี่ยมวิธีหนึ่งในการสร้าง 'แนวทางกำหนด ' (ขอบคุณ Elton Stoneman) โดยทั่วไปจะทำสิ่งนี้:

private Guid GetDeterministicGuid(string input) 

{ 

//use MD5 hash to get a 16-byte hash of the string: 

MD5CryptoServiceProvider provider = new MD5CryptoServiceProvider(); 

byte[] inputBytes = Encoding.Default.GetBytes(input); 

byte[] hashBytes = provider.ComputeHash(inputBytes); 

//generate a guid from the hash: 

Guid hashGuid = new Guid(hashBytes); 

return hashGuid; 

} 

ดังนั้นเมื่อกำหนดสตริง Guid จะเหมือนกันเสมอ

มีแนวทางอื่นหรือวิธีที่แนะนำในการดำเนินการนี้หรือไม่? ข้อดีหรือข้อเสียของวิธีนั้นคืออะไร?

ตามที่ @bacar กล่าวไว้RFC 4122 §4.3กำหนดวิธีสร้าง UUID ตามชื่อ ข้อดีของการทำเช่นนี้ (โดยใช้แฮช MD5) คือสิ่งเหล่านี้รับประกันว่าจะไม่ชนกับ UUID ที่ไม่ระบุชื่อและมีความเป็นไปได้น้อยมากที่จะชนกับ UUID ตามชื่ออื่น ๆ

NET Framework สำหรับการสร้างสิ่งเหล่านี้ แต่ฉันโพสต์โค้ดบน GitHubที่ใช้อัลกอริทึม สามารถใช้งานได้ดังนี้:

Guid guid = GuidUtility.Create(GuidUtility.UrlNamespace, filePath);

เพื่อลดความเสี่ยงในการชนกับ GUID อื่น ๆ ให้มากยิ่งขึ้นคุณสามารถสร้าง GUID ส่วนตัวเพื่อใช้เป็นรหัสเนมสเปซ (แทนที่จะใช้รหัสเนมสเปซ URL ที่กำหนดใน RFC)

สิ่งนี้จะแปลงสตริงใด ๆ เป็น Guid โดยไม่ต้องนำเข้าแอสเซมบลีภายนอก

public static Guid ToGuid(string src)
{
    byte[] stringbytes = Encoding.UTF8.GetBytes(src);
    byte[] hashedBytes = new System.Security.Cryptography
        .SHA1CryptoServiceProvider()
        .ComputeHash(stringbytes);
    Array.Resize(ref hashedBytes, 16);
    return new Guid(hashedBytes);
}

มีวิธีที่ดีกว่ามากในการสร้าง Guid ที่ไม่เหมือนใคร แต่นี่เป็นวิธีการอัปเกรดคีย์ข้อมูลสตริงเป็นคีย์ข้อมูล Guid อย่างสม่ำเสมอ

ตามที่ Rob กล่าวถึงวิธีการของคุณไม่ได้สร้าง UUID แต่จะสร้างแฮชที่ดูเหมือน UUID

RFC 4122ใน UUIDs โดยเฉพาะช่วยให้การกำหนด (ชื่อ-based) UUIDs - รุ่น 3 และ 5 ใช้ MD5 และ SHA1 (ตามลำดับ) คนส่วนใหญ่น่าจะคุ้นเคยกับเวอร์ชัน 4 ซึ่งเป็นแบบสุ่ม Wikipediaให้ภาพรวมที่ดีของเวอร์ชันต่างๆ (โปรดทราบว่าการใช้คำว่า 'เวอร์ชัน' ที่นี่ดูเหมือนจะอธิบายถึง 'ประเภท' ของ UUID - เวอร์ชัน 5 ไม่ได้ใช้แทนเวอร์ชัน 4)

ดูเหมือนจะเป็นห้องสมุดกี่ออกมีสำหรับรุ่นสร้าง 3/5 UUIDs รวมทั้งงูหลามโมดูล uuid , boost.uuid (C ++) และOSSP UUID (ฉันไม่ได้มองหา. net ใด ๆ )

คุณต้องสร้างความแตกต่างระหว่างอินสแตนซ์ของคลาสGuidและตัวระบุที่ไม่ซ้ำกันทั่วโลก "แนวทางกำหนดปัจจัย" คือแฮช (ตามหลักฐานจากการเรียกร้องของคุณprovider.ComputeHash) แฮชมีโอกาสที่จะเกิดการชนกันสูงกว่ามาก (สองสตริงที่แตกต่างกันเกิดขึ้นเพื่อสร้างแฮชเดียวกัน) มากกว่าที่ Guid สร้างผ่านGuid.NewGuid.

ดังนั้นปัญหาในแนวทางของคุณคือคุณจะต้องตกลงกับความเป็นไปได้ที่สองเส้นทางที่แตกต่างกันจะสร้าง GUID เดียวกัน หากคุณจำเป็นต้องระบุที่ไม่ซ้ำกันสำหรับสตริงเส้นทางใดก็ตามแล้วสิ่งที่ง่ายที่สุดที่จะทำคือเพียงแค่ใช้สตริง หากคุณต้องการให้สตริงถูกบดบังจากผู้ใช้ของคุณให้เข้ารหัส - คุณสามารถใช้ ROT13 หรือสิ่งที่มีประสิทธิภาพมากกว่า ...

การพยายามใส่รองเท้าที่ไม่ใช่ GUID บริสุทธิ์ลงในประเภทข้อมูล GUID อาจทำให้เกิดปัญหาการบำรุงรักษาในอนาคต ...

MD5 อ่อนแอฉันเชื่อว่าคุณสามารถทำสิ่งเดียวกันกับ SHA-1 และได้ผลลัพธ์ที่ดีกว่า

BTW เป็นเพียงความเห็นส่วนตัวการแต่งแฮช md5 เป็น GUID ไม่ได้ทำให้เป็น GUID ที่ดี GUID โดยธรรมชาติแล้วไม่ได้กำหนด รู้สึกเหมือนเป็นการโกง ทำไมไม่เรียกจอบจอบแล้วพูดว่ามันเป็นสตริงที่แสดงผลแฮชของอินพุต คุณสามารถทำได้โดยใช้บรรทัดนี้แทนที่จะเป็น guid line ใหม่:

string stringHash = BitConverter.ToString(hashBytes)