测试字符串是否为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 可以通过将GUID附加到文件夹名称来指定名称空间扩展名。我可能正在解析文件夹名称，检查是否在final后面的文本。是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我可能正在运行一个使用率很高的Web服务器，想要检查某些回发数据的有效性。我不希望无效数据占用资源比需要的资源高2-3个数量级。

示例3我可能正在解析用户输入的搜索表达式。

如果他们输入GUID，我想对其进行特殊处理（例如，专门搜索该对象，或者在响应文本中突出显示并格式化该特定搜索词。）

更新3-性能基准

测试转换10,000个好向导和10,000个坏向导。

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

ps我不必证明一个问题。

绩效基准

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);
    }
}

底线：如果需要检查字符串是否为Guid，并且在意性能，请使用COM Interop。

如果需要将String表示形式的guid转换为Guid，请使用

new Guid(someString);

.net 4.0可用后，您可以使用Guid.TryParse()。

您不会喜欢这样，但是是什么让您认为捕获异常的速度会变慢？

与成功的GUID相比，您期望多少次失败的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;
}

您不想在SEHException，ThreadAbortException或其他致命或不相关的内容上说“无效的GUID”。

更新：从.NET 4.0开始，有一组适用于Guid的新方法：

• Guid.TryParse
• Guid.TryParseExact

实际上，应该使用它们（如果仅出于事实，它们不是在内部使用try-catch“天真”实现的）。

Interop比捕获异常要慢：

在幸福的道路上，有10,000吉德：

Exception:    26ms
Interop:   1,201ms

在不幸的道路上：

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

它更一致，但也始终较慢。在我看来，最好将调试器配置为仅在未处理的异常时中断。

好吧，这是您需要的正则表达式...

^[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}(}})$

但这只是初学者。您还必须验证各个部分（例如日期/时间）是否在可接受的范围内。我无法想象这比您已经概述的try / catch方法要快。希望您不会收到太多无效的GUID来担保这种检查！

出于可用性原因-调试器弹出

如果您尝试使用try / catch方法，则可以添加[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;
    }
}

据我所知，mscrolib中没有类似Guid.TryParse的东西。根据参考资料，Guid类型具有大型复合构造函数，该构造函数会检查各种Guid格式并尝试解析它们。您无法调用任何辅助方法，即使通过反射也是如此。我认为您必须搜索第三方Guid解析器，或者自己编写。

通过RegEx或一些进行完整性检查的自定义代码运行潜在的GUID，以确保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;
    }

• 获取反射器
• 复制'n'paste Guid的.ctor（String）
• 用“ return false”替换每次出现的“ throw new ...”。

Guid的ctor几乎是一个已编译的正则表达式，这样您将获得完全相同的行为，而不会产生异常开销。

1. 这构成逆向工程吗？我认为确实如此，因此可能是非法的。
2. 如果GUID格式更改，将中断。

甚至更酷的解决方案是通过动态替换“ throw new”来动态地检测一种方法。

我投票给Jon在上面发布的GuidTryParse链接或类似的解决方案（IsProbablyGuid）。我将为我的转换库编写类似的内容。

我认为这个问题如此复杂完全是la脚。如果Guid可以为null，则“ is”或“ as”关键字就很好。但是由于某些原因，即使SQL Server可以，.NET也不行。为什么？Guid.Empty的值是多少？这只是.NET设计所造成的一个愚蠢的问题，当一种语言惯例逐渐浮出水面时，这确实使我感到烦恼。到目前为止，性能最好的答案一直是使用COM Interop，因为Framework无法优雅地处理它吗？“此字符串可以是GUID吗？” 应该是一个容易回答的问题。

直到应用程序可以上网之前，依靠抛出的异常是可以的。那时，我只是为拒绝服务攻击做好了准备。即使我没有受到“攻击”，我也知道某些雅虎会使用URL，或者我的市场部门可能会发送格式错误的链接，然后我的应用程序可能会遭受相当大的性能损失关闭服务器，因为我没有编写代码来处理应该不会发生的问题，但是我们都知道会发生。

这使“ Exception”上的行模糊了一些，但最重要的是，即使问题很少发生，如果它可能在很短的时间内发生足够的时间，导致您的应用程序崩溃，无法为所有捕获的内容提供服务，那么我认为抛出异常是不良形式。

愤怒3K

如果TypeOf ctype（myvar，Object）被引导，则..

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);
}