ทดสอบว่าสายอักขระนั้นเป็น guid หรือไม่โดยไม่ทิ้งข้อยกเว้น?

ฉันต้องการลองแปลงสตริงเป็น Guid แต่ฉันไม่ต้องการพึ่งพาข้อยกเว้น (

• สำหรับเหตุผลด้านประสิทธิภาพ - ข้อยกเว้นมีราคาแพง
• สำหรับเหตุผลในการใช้งาน - โปรแกรมดีบั๊กจะปรากฏขึ้น
• สำหรับเหตุผลด้านการออกแบบ - ความคาดหวังนั้นไม่โดดเด่น

ในคำอื่น ๆ รหัส:

public static Boolean TryStrToGuid(String s, out Guid value)
{
    try
    {
        value = new Guid(s);
        return true;
    }
    catch (FormatException)
    {
        value = Guid.Empty;
        return false;
    }
}

ไม่เหมาะ

ฉันจะลองใช้ RegEx แต่เนื่องจาก guid สามารถเป็นวงเล็บปิดวงเล็บปีกกาห่อหุ้มห่อไม่ทำให้มันยาก

นอกจากนี้ฉันคิดว่าค่า Guid บางอย่างไม่ถูกต้อง (?)

อัปเดต 1

ChristianKมีความคิดที่ดีที่จะจับเท่านั้นFormatExceptionไม่ใช่ทั้งหมด เปลี่ยนตัวอย่างรหัสของคำถามเพื่อรวมข้อเสนอแนะ

อัปเดต 2

ทำไมต้องกังวลเกี่ยวกับข้อยกเว้นโยน? ฉันคาดหวังว่าจะมี GUID ที่ไม่ถูกต้องทั้งหมดหรือไม่

คำตอบคือใช่ นั่นคือเหตุผลที่ฉันใช้ TryStrToGuid - ฉันกำลังคาดหวังว่าข้อมูลที่ไม่ดี

ตัวอย่างที่ 1 ส่วนขยาย Namespace สามารถระบุได้โดยการผนวก GUID ที่จะชื่อโฟลเดอร์ ฉันอาจจะแยกโฟลเดอร์ชื่อการตรวจสอบเพื่อดูว่าข้อความหลังสุดท้าย คือ GUID

c:\Program Files
c:\Program Files.old
c:\Users
c:\Users.old
c:\UserManager.{CE7F5AA5-6832-43FE-BAE1-80D14CD8F666}
c:\Windows
c:\Windows.old

ตัวอย่างที่ 2ฉันอาจใช้เว็บเซิร์ฟเวอร์ที่ใช้งานหนักต้องการตรวจสอบความถูกต้องของข้อมูลที่โพสต์กลับ ฉันไม่ต้องการให้ข้อมูลที่ไม่ถูกต้องคาดหวังทรัพยากรที่มีขนาด 2-3 คำสั่งสูงกว่าที่ควรจะเป็น

ตัวอย่างที่ 3ฉันอาจแยกวิเคราะห์นิพจน์การค้นหาที่ผู้ใช้ป้อน

หากพวกเขาป้อน GUID ฉันต้องการประมวลผลเป็นพิเศษ (เช่นการค้นหาวัตถุนั้นโดยเฉพาะหรือเน้นและจัดรูปแบบข้อความค้นหาเฉพาะในข้อความตอบกลับ)

อัปเดต 3 - การวัดประสิทธิภาพ

ทดสอบการแปลง 10,000 Guids ที่ดีและ 10,000 Guids ที่ไม่ดี

Catch FormatException:
   10,000 good:     63,668 ticks
   10,000 bad:   6,435,609 ticks

Regex Pre-Screen with try-catch:
   10,000 good:    637,633 ticks
   10,000 bad:     717,894 ticks

COM Interop CLSIDFromString
   10,000 good:    126,120 ticks
   10,000 bad:      23,134 ticks

ป.ล. ฉันไม่ควรต้องพิสูจน์คำถาม

มาตรฐานประสิทธิภาพ

Catch exception:
   10,000 good:    63,668 ticks
   10,000 bad:  6,435,609 ticks

Regex Pre-Screen:
   10,000 good:   637,633 ticks
   10,000 bad:    717,894 ticks

COM Interop CLSIDFromString
   10,000 good:   126,120 ticks
   10,000 bad:     23,134 ticks

COM Intertop (เร็วที่สุด) คำตอบ:

/// <summary>
/// Attempts to convert a string to a guid.
/// </summary>
/// <param name="s">The string to try to convert</param>
/// <param name="value">Upon return will contain the Guid</param>
/// <returns>Returns true if successful, otherwise false</returns>
public static Boolean TryStrToGuid(String s, out Guid value)
{
   //ClsidFromString returns the empty guid for null strings   
   if ((s == null) || (s == ""))   
   {      
      value = Guid.Empty;      
      return false;   
   }

   int hresult = PInvoke.ObjBase.CLSIDFromString(s, out value);
   if (hresult >= 0)
   {
      return true;
   }
   else
   {
      value = Guid.Empty;
      return false;
   }
}


namespace PInvoke
{
    class ObjBase
    {
        /// <summary>
        /// This function converts a string generated by the StringFromCLSID function back into the original class identifier.
        /// </summary>
        /// <param name="sz">String that represents the class identifier</param>
        /// <param name="clsid">On return will contain the class identifier</param>
        /// <returns>
        /// Positive or zero if class identifier was obtained successfully
        /// Negative if the call failed
        /// </returns>
        [DllImport("ole32.dll", CharSet = CharSet.Unicode, ExactSpelling = true, PreserveSig = true)]
        public static extern int CLSIDFromString(string sz, out Guid clsid);
    }
}

Bottom line: หากคุณต้องการตรวจสอบว่าสตริงเป็น guid หรือไม่และคุณสนใจเรื่องประสิทธิภาพให้ใช้ COM Interop

หากคุณต้องการแปลง guid ใน String แสดงถึง Guid ให้ใช้

new Guid(someString);

เมื่อ .net 4.0 Guid.TryParse()พร้อมใช้งานคุณสามารถใช้

คุณจะไม่ทำแบบนี้ แต่สิ่งใดที่ทำให้คุณคิดว่าการจับข้อยกเว้นจะช้ากว่าเดิม?

คุณคาดว่าจะมีการพยายามแยกวิเคราะห์ GUID ที่ล้มเหลวกี่ครั้งเมื่อเปรียบเทียบกับความสำเร็จ

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

ใน. NET 4.0 คุณสามารถเขียนดังนี้:

public static bool IsValidGuid(string str)
{
    Guid guid;
    return Guid.TryParse(str, out guid);
}

อย่างน้อยฉันก็จะเขียนมันเป็น:

try
{
  value = new Guid(s);
  return true;
}
catch (FormatException)
{
  value = Guid.Empty;
  return false;
}

คุณไม่ต้องการพูดว่า "GUID ที่ไม่ถูกต้อง" ใน SEHException, ThreadAbortException หรือสิ่งที่ร้ายแรงหรือไม่เกี่ยวข้อง

อัปเดต : เริ่มต้นด้วย. NET 4.0 มีชุดวิธีการใหม่สำหรับ Guid:

• Guid.TryParse
• Guid.TryParseExact

จริง ๆ แล้วควรใช้สิ่งเหล่านั้น (หากเพียงเพราะความจริงที่ว่าพวกเขาจะไม่ "ไร้เดียงสา" ดำเนินการโดยใช้ลองจับภายใน)

การทำงานร่วมกันช้ากว่าการจับยกเว้น:

ในเส้นทางแห่งความสุขด้วย 10,000 Guids:

Exception:    26ms
Interop:   1,201ms

ในเส้นทางที่ไม่มีความสุข:

Exception: 1,150ms
  Interop: 1,201ms

มันสอดคล้องกันมากกว่า แต่ก็ช้ากว่าเสมอ ดูเหมือนว่าคุณจะดีกว่าการกำหนดค่าดีบักเกอร์ของคุณเพื่อทำลายข้อยกเว้นที่ไม่สามารถจัดการได้

นี่คือ regex ที่คุณต้องการ ...

^[A-Fa-f0-9]{32}$|^({|\\()?[A-Fa-f0-9]{8}-([A-Fa-f0-9]{4}-){3}[A-Fa-f0-9]{12}(}|\\))?$|^({)?[0xA-Fa-f0-9]{3,10}(, {0,1}[0xA-Fa-f0-9]{3,6}){2}, {0,1}({)([0xA-Fa-f0-9]{3,4}, {0,1}){7}[0xA-Fa-f0-9]{3,4}(}})$

แต่นั่นเป็นเพียงการเริ่ม คุณจะต้องยืนยันว่าส่วนต่าง ๆ เช่นวันที่ / เวลาอยู่ในช่วงที่ยอมรับได้ ฉันไม่สามารถจินตนาการได้ว่าวิธีนี้จะเร็วกว่าวิธีลอง / จับที่คุณได้อธิบายไว้แล้ว หวังว่าคุณจะไม่ได้รับ GUID ที่ไม่ถูกต้องจำนวนมากเพื่อรับประกันการตรวจสอบประเภทนี้!

สำหรับเหตุผลในการใช้งาน - โปรแกรมดีบั๊กจะปรากฏขึ้น

หากคุณใช้วิธีลอง / จับคุณสามารถเพิ่มแอททริบิวต์ [System.Diagnostics.DebuggerHidden] เพื่อให้แน่ใจว่าดีบักเกอร์จะไม่แตกแม้ว่าคุณจะตั้งค่าให้หยุดพัก

ในขณะที่มันเป็นความจริงที่ว่าใช้ข้อผิดพลาดที่มีราคาแพงกว่าคนส่วนใหญ่เชื่อว่าส่วนใหญ่ของ guid ของพวกเขากำลังจะเป็นเครื่องคอมพิวเตอร์ที่สร้างเพื่อเป็นที่ไม่แพงจนเกินไปเพราะมันเพียงสร้างค่าใช้จ่ายในTRY-CATCH CATCHคุณสามารถพิสูจน์ได้ด้วยตัวคุณเองด้วยการทดสอบสองอย่างง่าย ๆ(สาธารณะผู้ใช้ไม่มีรหัสผ่าน)

ไปเลย:

using System.Text.RegularExpressions;


 /// <summary>
  /// Validate that a string is a valid GUID
  /// </summary>
  /// <param name="GUIDCheck"></param>
  /// <returns></returns>
  private bool IsValidGUID(string GUIDCheck)
  {
   if (!string.IsNullOrEmpty(GUIDCheck))
   {
    return new Regex(@"^(\{{0,1}([0-9a-fA-F]){8}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){12}\}{0,1})$").IsMatch(GUIDCheck);
   }
   return false;
  }

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

public static Boolean TryStrToGuid(String s, out Guid value)
{

     // this is before the overhead of setting up the try/catch block.
     if(value == null || value.Length != 36)
     {  
        value = Guid.Empty;
        return false;
     }

    try
    {
        value = new Guid(s);
        return true;
    }
    catch (FormatException)
    {
        value = Guid.Empty;
        return false;
    }
}

เท่าที่ฉันรู้ไม่มีอะไรเหมือน Guid.TryParse ใน mscrolib ตามแหล่งอ้างอิงประเภท Guid มีตัวสร้าง mega-complex ที่ตรวจสอบรูปแบบ guid ทุกชนิดและพยายามแยกวิเคราะห์มัน ไม่มีวิธีช่วยเหลือที่คุณสามารถโทรได้แม้ผ่านการสะท้อนกลับ ฉันคิดว่าคุณต้องค้นหาตัวแยกวิเคราะห์ Guid บุคคลที่สามหรือเขียนของคุณเอง

เรียกใช้ GUID ที่เป็นไปได้แม้ว่า RegEx หรือรหัสที่กำหนดเองที่ตรวจสอบสติเพื่อให้แน่ใจว่า strig อย่างน้อยดูเหมือน GUID และประกอบด้วยอักขระที่ถูกต้องเท่านั้น (และอาจดูเหมือนว่าเหมาะสมกับรูปแบบโดยรวม) ถ้ามันไม่ผ่านการตรวจสอบสติปัญญากลับข้อผิดพลาด - ที่อาจกำจัดวัชพืชส่วนใหญ่ที่ไม่ถูกต้อง

จากนั้นแปลงสตริงตามที่คุณมีด้านบนยังคงตรวจสอบข้อยกเว้นสำหรับสตริงที่ไม่ถูกต้องสองสามตัวที่ผ่านการตรวจสอบสติ

Jon Skeet ทำการวิเคราะห์บางอย่างที่คล้ายกันเพื่อแยกวิเคราะห์ Ints (ก่อนที่ TryParse อยู่ใน Framework): ตรวจสอบว่าสตริงสามารถแปลงเป็น Int32 ได้หรือไม่

อย่างไรก็ตามอย่างที่AnthonyWJonesระบุว่าคุณไม่ควรกังวลเกี่ยวกับเรื่องนี้

 bool IsProbablyGuid(string s)
    {
        int hexchars = 0;
        foreach(character c in string s)
        {
           if(IsValidHexChar(c)) 
               hexchars++;          
        }
        return hexchars==32;
    }

• รับตัวสะท้อนแสง
• copy'n'paste Guid's .ctor (String)
• แทนที่ทุกครั้งที่ "โยนใหม่ ... " ด้วย "return false"

ctor ของ Guid นั้นเป็น regex ที่เรียบเรียงเป็นอย่างมากในแบบที่คุณจะได้รับพฤติกรรมเดียวกันโดยไม่มีข้อยกเว้น

1. นี่เป็นวิศวกรรมย้อนกลับหรือไม่? ฉันคิดว่ามันเป็นเช่นนั้นและอาจเป็นสิ่งผิดกฎหมาย
2. จะแตกถ้ารูปแบบ GUID มีการเปลี่ยนแปลง

แม้แต่วิธีแก้ปัญหาที่เย็นกว่าก็คือการใช้เครื่องมือวิธีการแบบไดนามิกโดยแทนที่ "โยนใหม่" ได้ทันที

ฉันลงคะแนนให้ลิงก์ GuidTryParse โพสต์ข้างต้นโดยJonหรือโซลูชันที่คล้ายกัน (IsProbablyGuid) ฉันจะเขียนหนึ่งในนั้นสำหรับห้องสมุดการแปลงของฉัน

ฉันคิดว่ามันค่อนข้างง่อยว่าคำถามนี้จะต้องซับซ้อนมาก คำหลัก "is" หรือ "as" น่าจะใช้ได้ถ้า Guid อาจเป็นโมฆะ แต่ด้วยเหตุผลบางอย่างแม้ว่า SQL Server จะตกลงกับที่. NET ไม่ ทำไม? ค่าของ Guid.Empty คืออะไร นี่เป็นเพียงปัญหาโง่ ๆ ที่เกิดขึ้นจากการออกแบบของ. NET และมันทำให้ฉันสับสนจริงๆเมื่อการประชุมของขั้นตอนภาษาในตัวเอง คำตอบที่มีประสิทธิภาพดีที่สุดได้ใช้ COM Interop มาแล้วเนื่องจาก Framework ไม่สามารถจัดการได้อย่างงดงาม? "สตริงนี้สามารถเป็น GUID ได้หรือไม่" ควรเป็นคำถามที่ตอบง่าย

การใช้ข้อยกเว้นที่เกิดขึ้นนั้นใช้งานได้ดีจนกระทั่งแอปพลิเคชันไปบนอินเทอร์เน็ต ณ จุดนี้ฉันเพิ่งตั้งค่าตัวเองสำหรับการปฏิเสธการโจมตีบริการ แม้ว่าฉันจะไม่ได้รับ "จู่โจม" ฉันรู้ว่า yahoo บางตัวกำลังลิงกับ URL หรืออาจฝ่ายการตลาดของฉันจะส่งลิงก์ที่มีรูปแบบไม่ถูกต้องและใบสมัครของฉันจะต้องได้รับประสิทธิภาพที่ค่อนข้างแรง ลงเซิร์ฟเวอร์เพราะฉันไม่ได้เขียนรหัสเพื่อจัดการกับปัญหาที่ SHOULDN จะไม่เกิดขึ้น แต่เราทุกคนรู้ว่าจะเกิดขึ้น

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

TheRage3K

ถ้า TypeOf ctype (myvar วัตถุ) เป็น Guid แล้ว .....

Private Function IsGuidWithOptionalBraces(ByRef strValue As String) As Boolean
    If String.IsNullOrEmpty(strValue) Then
        Return False
    End If

    Return System.Text.RegularExpressions.Regex.IsMatch(strValue, "^[\{]?[0-9a-fA-F]{8}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{12}[\}]?$", System.Text.RegularExpressions.RegexOptions.IgnoreCase)
End Function


Private Function IsGuidWithoutBraces(ByRef strValue As String) As Boolean
    If String.IsNullOrEmpty(strValue) Then
        Return False
    End If

    Return System.Text.RegularExpressions.Regex.IsMatch(strValue, "^[0-9a-fA-F]{8}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{12}$", System.Text.RegularExpressions.RegexOptions.IgnoreCase)
End Function


Private Function IsGuidWithBraces(ByRef strValue As String) As Boolean
    If String.IsNullOrEmpty(strValue) Then
        Return False
    End If

    Return System.Text.RegularExpressions.Regex.IsMatch(strValue, "^\{[0-9a-fA-F]{8}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{4}\-[0-9a-fA-F]{12}\}$", System.Text.RegularExpressions.RegexOptions.IgnoreCase)
End Function

ด้วยวิธีการขยายใน C #

public static bool IsGUID(this string text)
{
    return Guid.TryParse(text, out Guid guid);
}