2009-11-06 4 views
48

UPDATEЕсть ли GUID.TryParse() в .NET 3.5?

Guid.TryParse доступен в .NET 4.0

END UPDATE

Очевидно, что нет общественного GUID.TryParse() в .NET CLR 2.0.

Итак, я изучал регулярные выражения [а также поиск в googling, чтобы найти их], и каждый раз, когда я его нашел, был горячий аргумент в разделе комментариев о RegEx A, который не работает, используйте RegEx B. Тогда кто-то будет напишите Regex C yadda yadda

Так или иначе, я решил сделать это, но мне плохо.

public static bool IsGuid (string possibleGuid) { 

    try { 
     Guid gid = new Guid(possibleGuid); 
     return true;  
    } catch (Exception ex) { 
     return false; 
    } 
} 

Очевидно, что я не очень люблю это, так как это было просверлено в меня с первого дня, чтобы избежать бросание исключения, если вы можете defensibly код вокруг него.

Кто-нибудь знает, почему нет открытого Guid.TryParse() в .NET Framework?

Есть ли у кого-нибудь реальное регулярное выражение, которое будет работать для всех GUID?

+3

Метод try catch может быть плохим, если этот метод называется лотом (в узком цикле), и существует высокая вероятность исключения. Я когда-то профилировал приложение ASP.NET 1.1, которое это сделало, и после его обновления до .NET 2.0 в int.TryParse производительность увеличилась примерно на 30% (в ней было много запросов int.Parse!). – RichardOD

+0

Да, это не будет цикл. В основном я получаю ошибки «неудачного преобразования в uniqueidentifier» и т. Д., Поэтому я хотел сделать что-то большее, чем просто проверить, была ли пустая строка пуста или нет. –

+0

строка Id = Guid.NewGuid(). ToString(); – 2012-02-13 12:59:51

ответ

55

В CLR 2.0 и ранее отсутствует Guid.TryParse. Он будет доступен начиная с CLR 4.0 и Visual Studio 2010.

Что до этого не было. Обычно такие вопросы обычно трудно ответить правильно. Скорее всего, это была проблема контроля или времени. Если вы откроете mscorlib в отражателе, вы увидите, что на самом деле есть метод TryParse на Guid, но он закрыт. В некоторых случаях это также исключает исключение, поэтому это не является хорошим эквивалентом, например Int32.TryParse.

+4

+1 просто потому, что это интересный ответ. TryParse, который я заметил, вызывается конструктором. – RichardOD

+1

Очень интересно. Глядя на реализацию конструктора Guid (string) в отражателе, моя голова закружилась. Интересно, как ребята в Редмонде поддерживают этот код :-) –

+0

Да, поэтому я упомянул «почему не было публичного TryParse()« Спасибо jared –

5

С точки зрения того, почему этого не происходит, это недосмотр. В .NET 4 будет Guid.TryParse (подробнее см. BCL blog post).

19

Guid.TryParse внедрение с использованием регулярных выражений.

+0

Ницца. Я бы, вероятно, добавил в него попытку ухватиться за ловушку, просто чтобы быть уверенным (по крайней мере, пока я не был уверен, что ничего не пропустил в Regex). – RichardOD

+0

Вы реализовали это? –

+1

Нет, до сих пор на моем носителе программирования я никогда не нуждался в такой функциональности. –

0

В настоящий момент в .NET Framework нет функциональности TryParse. Вам придётся использовать RegEx или опцию try-catch. RegEx - это не моя чашка чая, поэтому я уверен, что кто-то другой опубликует ответ.

Исключения являются дорогостоящими характеристиками, поэтому мой голос переходит к опции RegEx.

0

Это должно работать:

@"^\{?[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

Это говорит о том, что «{00000000-0000-0000-0000-000000000000» является юридическим GUID. Вы действительно хотите разрешить несогласованные фигурные скобки? И почему дефисы необязательны? –

+1

Это было предназначено для «быстрого и грязного» способа сопоставления строк GUID. Для выполнения соответствующего сочетания и дефиса использование будет очень запутанным в регулярном выражении (это будет действительно несколько выражений). Согласно документам для 'Guid (string)', дефисы являются необязательными. – jheddings

0

Вы можете написать свой собственный TryParse как метод расширения для Guid. Затем, когда появляется «реальный» из MS, вы уже хорошо себя чувствуете и не должны меняться.

+1

За исключением того, что метод расширения применим только к экземпляру 'Guid', а версия framework будет статичной. – LukeH

+0

Ах да, dag nabbit – ryber

10

IsGuid реализованы как метод расширения для строки ...

public static bool IsGuid(this string stringValue) 
{ 
    string guidPattern = @"[a-fA-F0-9]{8}(\-[a-fA-F0-9]{4}){3}\-[a-fA-F0-9]{12}"; 
    if(string.IsNullOrEmpty(stringValue)) 
    return false; 
    Regex guidRegEx = new Regex(guidPattern); 
    return guidRegEx.IsMatch(stringValue); 
} 
+4

Поведение преднамеренное, пустая строка не является допустимым директором и, следовательно, возвращает false. –

+1

Почему при вызове метода null всегда следует исключать Null Reference Exception? Я ненавижу ненужные ссылочные исключения. Мне нравятся методы расширения по этой точной причине. Сохраняет мой код без нулевых проверок. – jeromeyers

+0

Реализация неверна. Правильно: 'string guidPattern = @"^[a-fA-F0-9] {8} (\ - [a-fA-F0-9] {4}) {3} \ - [a-fA-F0- 9] {12} $ ";' –

7

Эта реализация TryParse для Guids использует Try-защелку, чтобы поймать missformed Guids.Он реализован как метод расширения унд должен быть помещен в статическом классе:

public static bool TryParseGuid(this string s, out Guid guid) 
{ 
    try { 
     guid = new Guid(s); 
     return true; 
    } catch { 
     guid = Guid.Empty; 
     return false; 
    } 
} 

Это можно назвать с

string s = "{CA761232-ED42-11CE-BACD-00AA0057B223}"; 
Guid id; 
if (s.TryParseGuid(out id) { 
    // TODO: use id 
} else { 
    // Sorry not a valid Guid. 
} 

Начиная с C# 7.0/Visual Studio 2017, вы можете назвать его с:

string s = "{CA761232-ED42-11CE-BACD-00AA0057B223}"; 
if (s.TryParseGuid(out Guid id) { 
    // TODO: use id 
} else { 
    // Sorry not a valid Guid. 
} 

UPDATE

С Visual Studio 2010/.NET Framework 4.0, System.Guid обеспечивает TryParse и метод TryPareExact.