例外をスローせずに文字列が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をフォルダー名に追加することで指定できます。フォルダー名を解析して、最後のテキストの後にテキストがあるかどうかを確認している可能性があります。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を入力した場合、それらを特別に処理したい（そのオブジェクトを具体的に検索する、または応答テキストでその特定の検索語を強調表示してフォーマットするなど）。

Update 3-パフォーマンスベンチマーク

10,000の良いGUIDと10,000の悪いGUIDをテスト変換します。

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（Fastest）の回答：

/// <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相互運用機能を使用します。

文字列表現のGUIDを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;
}

SEHException、ThreadAbortException、またはその他の致命的または関連のないもので「無効なGUID」と言いたくない。

更新：.NET 4.0以降、Guidで使用できる一連の新しいメソッドがあります。

• Guid.TryParse
• Guid.TryParseExact

実際には、これらを使用する必要があります（事実のためにのみ、内部的にtry-catchを使用して「単純に」実装されていません）。

相互運用は、例外をキャッチするよりも遅くなります。

10,000 GUIDのハッピーパス：

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。2つの簡単なテスト（ユーザーパブリック、パスワードなし）を使用して、これを自分で証明できます。

どうぞ：

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がIntを解析するための類似の分析を行いました（TryParseがフレームワークに入る前）： 文字列をInt32に変換できるかどうかを確認しています

ただし、AnthonyWJonesが示したように、おそらくこれについて心配する必要はありません。

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

• リフレクターを入手する
• コピーアンドペーストのGuidの.ctor（String）
• 「throw new ...」が出現するたびに「return false」に置き換えます。

Guidのctorはほぼコンパイル済みの正規表現です。これにより、例外のオーバーヘッドなしでまったく同じ動作が得られます。

1. これはリバースエンジニアリングを構成しますか？そうだと思うし、違法かもしれない。
2. GUIDフォームが変更されると壊れます。

さらにクールな解決策は、「throw new」をオンザフライで置き換えることにより、メソッドを動的に計測することです。

上記のJonまたは同様のソリューション（IsProbablyGuid）によって投稿されたGuidTryParseリンクに投票します。私は自分の変換ライブラリーのようなものを書きます。

この質問が非常に複雑でなければならないのは完全に不自由だと思います。「is」または「as」キーワードは、Guidがnullになる可能性がある場合は問題ありません。しかし、何らかの理由で、SQL Serverはそれで問題ありませんが、.NETはそうではありません。どうして？Guid.Emptyの価値は何ですか？これは.NETの設計によって作成されたばかげた問題であり、言語の慣習がそれ自体を踏むときに本当に私を悩ませます。フレームワークがそれを適切に処理しないので、これまでのところ最高のパフォーマンスの答えはCOM Interopを使用していますか？「この文字列をGUIDにすることはできますか？」答えやすい質問でなければなりません。

アプリがインターネットに接続されるまで、スローされた例外に依存することは問題ありません。その時点で、サービス拒否攻撃を仕掛けるだけです。「攻撃」されない場合でも、一部のyahooがURLを悪用するか、またはマーケティング部門が不正なリンクを送信し、アプリケーションがかなりのパフォーマンスを発揮して、COULDがもたらす発生しない問題を処理するためのコードを記述しなかったため、サーバーをダウンさせました。

これは「例外」の線を少しぼやけさせます-しかし、問題がまれであっても、アプリケーションがクラッシュしてすべてのキャッチにサービスを提供する短い期間で十分な回数発生する可能性がある場合、例外をスローすると思います悪い形。

TheRage3K

TypeOf ctype（myvar、Object）が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);
}