J'ai besoin d'une méthode de validation de l'URI. Ainsi, des cordes comme: p>
" http://www.google.com ", "www.google.com", "google.com" p>
.. doit être validé comme Uri. Et aussi des chaînes normales comme "Google" ne doivent pas être validées comme Uri. Pour faire cette vérification, j'utilise deux méthodes: UriBuilder et UriR.trycreate (). P>
Le problème avec UriBuilder est que n'importe quelle chaîne que je lui donne, elle renvoie une urion de celle-ci. Lorsque je passe une chaîne normale dans son constructeur, il lui donne un schéma et retourne " http: // google / " qui est pas le comportement que je veux. p>
Le problème avec Uri.trycreate () est que, bien que cela fonctionne bien avec " http://www.google. com "et" www.google.com ", quand je lui donne" google.com ", il ne valident pas comme une URI. p>
J'ai pensé à faire des chèques sur la chaîne, si elle commence par http: // ou www, envoyez la chaîne à la classe d'Uribuilder, mais cela ne vous aide pas avec "google.com" qui doit également être une URI. < / p>
Comment puis-je valider des trucs comme "google.com" comme une URI, mais pas "Google"? Vérification de la fin de la chaîne pour .com, .net, .org ne semble pas flexible. P>
4 Réponses :
public static bool IsValidUri(string uriString) { Uri uri; if (!uriString.Contains("://")) uriString = "http://" + uriString; if (Uri.TryCreate(uriString, UriKind.RelativeOrAbsolute, out uri)) { if (Dns.GetHostAddresses(uri.DnsSafeHost).Length > 0) { return true; } } return false; }
Le protocole peut être Plusieurs autres choses autres que http.
@slugster: C'est pourquoi il vérifie s'il a déjà un protocole ... il ne la définit que sur http s'il ne le fait pas .. qui est de loin le plus courant et est assez sûr à défaut.
Merci pour votre code. Cependant, ce code construit une URI d'un mot unique - si je passe "google", je suis en retour " Google " qui n'est pas Ce dont j'ai besoin. De plus, je voudrais éviter de construire la logique de code sur Essayer / Catch Constructions.
@andrei: On dirait que vous avez besoin d'un validateur URI et d'un vérificateur DNS. J'ai mis à jour la fonction pour inclure les deux et supprimé l'essai / attraper.
Merci pour le code mis à jour. En passant, vous pouvez remplacer les chaînes ": //" et "http" avec leurs correspondants d'objet URI.SCHEMEDELIMITItre et Uri.urischemehttp. Le problème avec ce code est que lorsque la chaîne est normale comme "Google", elle jette une exception SocketException. Donc, j'ai fait une variation de votre code qui le gère:
Je pense que l'ajout de la chaîne de protocole devrait être hors de portée de cette fonction.
Ce que vous cherchez est Si vous définissez URIKIND à absolu, il renvoie FALSE: P> de Documentation MSDN : p> Les URI absolues sont caractérisées par une référence complète à la ressource (exemple: http: //www.contoso. com / index.html ), tandis qu'une URI relative dépend d'une uri de base définie précédemment (exemple: /index.html). P>
blockQuote> Aussi, voir ici pour Si vous regardez RFC 2396 , vous verrez que Google.com n'est pas une URI valide. En fait, www.google.com n'est pas ni ni. Mais sous La syntaxe d'URL a été conçue pour une référence sans ambiguïté au réseau
Ressources et extensibilité via le schéma d'URL. Cependant, comme l'URL
L'identification et l'utilisation sont devenues des médias traditionnels, des médias traditionnels
(télévision, radio, journaux, panneaux d'affichage, etc.) ont de plus en plus
Utilisé des références d'URL abrégées. C'est-à-dire une référence composée de
Seules les portions d'autorité et de chemin de la ressource identifiée, telle
comme
www.w3.org/addressing/
ou simplement le nom d'hôte DNS seul. Ces références sont principalement
destiné à l'interprétation humaine plutôt que à la machine, avec le
hypothèse que les heuristiques contextuelles sont suffisantes pour compléter
l'URL (par exemple, la plupart des noms d'hôte commençant par "www" sont susceptibles d'avoir
un préfixe d'URL de "http: //"). Bien qu'il n'y ait pas d'ensemble standard de
Heuristics pour désambiguement des références d'URL abrégées, beaucoup de clients
les implémentations leur permettent d'être entrées par l'utilisateur et
résolu heuristiquement. Il convient de noter que de telles heuristiques peuvent
Changement dans le temps, en particulier lorsque de nouveaux schémas d'URL sont introduits.
Puisque une URL abrégée a la même syntaxe qu'un chemin d'URL relative,
Les références d'URL abrégées ne peuvent pas être utilisées dans des contextes où le parent
Les URL sont attendues. Cela limite l'utilisation d'URL abrégées aux endroits
où il n'y a pas d'URL de base définie, telles que les boîtes de dialogue et hors ligne
publicités. p>
blockQuote> Ce que je comprends à partir de celui-ci est, aussi, en tant que note latérale, si vous voulez Utilisez une expression régulière pour analyser une URI, vous pouvez lire uri.iswellformedurining code>. Le code suivant renvoie true:
Uri.IsWellFormedUriString("google.com", UriKind.Absolute)
uri.iswellformedurining code>. Cette méthode fonctionne conformément à la RFC 2396 et à la RFC 2732. P>
uri.iswellformedurining code> accepte des chaînes sous forme de www.abc.com comme URIS valide. Mais Google.com n'est pas accepté comme une URI absolue, alors qu'elle est acceptée comme une URI relative car elle est conforme à la spécification relative du chemin (les chemins peuvent contenir.). P>
Merci pour votre réponse. Cette méthode est intéressante, elle valide "google.com" qui est géniale, mais elle valide un seul mot ("Google") comme une URI bien formée, ce que je n'ai pas besoin. Réponse utile néanmoins
@Andrei: J'ai mis à jour ma réponse. La réponse réside dans la RFC 2396.
Merci pour cela, j'ai encore lu sur Uri.iswellformedurining et je pense que je comprends pourquoi il valide "Google" comme URI valide. Donc, ce dont j'ai besoin, je suppose, c'est un moyen de vérifier si la fin de la chaîne a un .com, .NET, ..etc est attaché à celui-ci. Je suis réticent d'utiliser EXP régulier à ce sujet car ils peuvent avoir des défauts, ce que, si dans le futur, quelqu'un invente une extension populaire comme ".zedo", par exemple, mon regexp ne l'attrapera pas car il ne traitera que des terminaisons connues (.NET, .com, etc.).
@Andrei: Les expressions régulières peuvent vous mettre en difficulté à l'avenir comme vous l'avez mentionné. Ainsi, collant avec des méthodes standard fournies par le cadre est préférable. Je vous suggère d'insérer http: // au début de la chaîne, s'il ne commence pas avec IT.SO que Google.com < / a> devient une URI absolue.
Utilisez REGEXP pour cela.
échantillon de code d'url de validation p>
Pour utiliser cette expression régulière sur une ancienne expression régulière de Posix, j'ai dû déplacer le caractère de trait d'union-minus à la fin des groupes correspondants []. Par exemple, non échappé, "^ (([a-za-z] [0-9a-za-z + .-] * :)? / {0,2} [0-9a-za-z; /? : @ & = + $ ._! ~ * '()% -] +)? (# [0-9A-ZA-Z; /?: @ & = + $ ._! ~ *' ( )% -] +)? $ "
Ceci est une variante du code de Jojaba à qui je remercie pour le vérificateur DNS, c'était ce dont j'avais besoin. Le seul problème est qu'il utilise un essai attrayant dans sa logique que j'espérais éviter.
Pouvez-vous vérifier si vous souhaitez valider une URL ou une URI? Votre question est un peu déroutante.
@Slugster - Après avoir lu votre question, j'ai vérifié en ligne pour comprendre la différence de la différence afin que la réponse soit que je dois valider une URI, pas l'URL.