Проверить, является ли строка указателем без исключения?

Запустите потенциальный GUID с помощью RegEx или какого-либо настраиваемого кода, который выполняет проверку работоспособности, чтобы убедиться, что строка хотя бы выглядит как GUID и состоит только из допустимых символов (и, возможно, что она соответствует общему формату). Если он не проходит проверку работоспособности, возвращает ошибку - это, вероятно, отсеивает подавляющее большинство недопустимых строк.

Затем преобразуйте строку, как указано выше, по-прежнему обнаруживая исключение для нескольких недопустимых строк, прошедших проверку работоспособности.

Джон Скит провел анализ чего-то похожего для синтаксического анализа Ints (до того, как TryParse был в Framework): Проверка возможности преобразования строки в Int32

Однако, как указывает ЭнтониУДжонс, вам, вероятно, не стоит об этом беспокоиться.

Вам это не понравится, но почему вы думаете, что перехват исключения будет медленнее?

Сколько неудачных попыток разобрать GUID вы ожидаете по сравнению с успешными?

Мой совет - используйте только что созданную функцию и профилируйте свой код. Если вы обнаружите, что эта функция действительно является точкой доступа тогда, исправьте ее, но не раньше.

Что ж, вот регулярное выражение, которое вам понадобится ...

^[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, чтобы гарантировать этот тип проверки!

Насколько я знаю, в mscrolib нет чего-то вроде Guid.TryParse. Согласно справочному источнику, тип Guid имеет мега-сложный конструктор, который проверяет все виды форматов guid и пытается их проанализировать. Не существует вспомогательного метода, который можно было бы вызвать даже через отражение. Я думаю, вам нужно искать сторонние парсеры Guid или писать свои собственные.

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

Хотя является верно, что использование ошибок обходится дороже, большинство людей считает, что большинство их 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;
  }

Я бы хотя бы переписал это так:

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

На самом деле, их следует использовать (хотя бы потому, что они не «наивно» реализованы с использованием try-catch внутренне).

Тесты производительности

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.

Если вам нужно преобразовать guid в строковое представление в Guid, используйте

new Guid(someString);

Взаимодействие медленнее, чем просто перехват исключения:

На счастливом пути с 10000 гидами:

Exception:    26ms
Interop:   1,201ms

На несчастном пути:

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

Он более последовательный, но при этом постоянно медленнее. Мне кажется, вам лучше настроить отладчик так, чтобы он останавливался только на необработанных исключениях.

если TypeOf ctype (myvar, Object) является Guid, то .....

for usability reasons - the debugger pops up

Если вы выбираете подход try / catch, вы можете добавить атрибут [System.Diagnostics.DebuggerHidden], чтобы убедиться, что отладчик не сломается, даже если вы установили его прерывание при выбросе.

• Получить рефлектор
• copy'n'paste Guid's .ctor (строка)
• замените каждое появление «throw new ...» на «return false».

Ctor Guid - это в значительной степени скомпилированное регулярное выражение, поэтому вы получите точно такое же поведение без накладных расходов на исключение.

1. Это реверс-инжиниринг? Я думаю, что это так, и поэтому может быть незаконным.
2. Сломается, если форма GUID изменится.

Еще более крутым решением было бы динамическое инструментирование метода, заменяя «бросать новый» на лету.

У меня была аналогичная ситуация, и я заметил, что почти никогда не было недопустимой строки длиной 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;
    }
}

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

Я голосую за ссылку GuidTryParse, размещенную выше Джон или аналогичное решение (IsProbablyGuid). Я напишу такой же для моей библиотеки преобразования.

Я думаю, что это совершенно неуместно, что этот вопрос настолько сложен. Ключевое слово «is» или «as» будет подходящим, ЕСЛИ Guid может иметь значение null. Но по какой-то причине, даже если SQL Server это устраивает, .NET - нет. Почему? В чем ценность Guid.Empty? Это просто глупая проблема, созданная дизайном .NET, и меня действительно беспокоит, когда соглашения языка действуют сами по себе. На данный момент наиболее эффективным ответом было использование COM-взаимодействия, потому что Framework не справляется с этим изящно? "Может ли эта строка быть GUID?" должен быть вопрос, на который легко ответить.

Можно полагаться на выброшенное исключение, пока приложение не появится в Интернете. В этот момент я просто настроился на атаку отказа в обслуживании. Даже если меня не «атакуют», я знаю, что какой-то yahoo собирается обезьянничать с URL-адресом, или, возможно, мой отдел маркетинга отправит неверную ссылку, и тогда мое приложение должно сильно пострадать в производительности, что МОЖЕТ принести сервер, потому что я не писал свой код для решения проблемы, которая НЕ ДОЛЖНА случиться, но мы все знаем, что БУДЕТ.

Это немного размывает черту в «Исключении», но в итоге, даже если проблема нечасто, если это может случиться достаточно много раз за короткий промежуток времени, что ваше приложение выйдет из строя, обслуживая все уловы из всего этого, тогда я думаю, что выброс исключения - это плохой тон.

TheRage3K

Когда .net 4.0 станет доступным, вы можете использовать Guid.TryParse().

В .NET 4.0 вы можете написать следующее:

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

С помощью метода расширения в C#

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