J'ai une application qui envoie une demande POST au logiciel de forum VB et connecte quelqu'un (sans paramétrer les cookies ou quoi que ce soit).
Une fois l'utilisateur connecté, je crée une variable qui crée un chemin sur sa machine locale.
c: \ dossier temporaire \ date \ nom d'utilisateur
Le problème est que certains noms d'utilisateur lèvent l'exception "caractères illégaux". Par exemple, si mon nom d'utilisateur était, mas|fenix
il déclencherait une exception.
Path.Combine( _
Environment.GetFolderPath(System.Environment.SpecialFolder.CommonApplicationData), _
DateTime.Now.ToString("ddMMyyhhmm") + "-" + form1.username)
Je ne veux pas le supprimer de la chaîne, mais un dossier avec leur nom d'utilisateur est créé via FTP sur un serveur. Et cela m'amène à ma deuxième question. Si je crée un dossier sur le serveur, puis-je laisser les "caractères illégaux" dans? Je ne pose cette question que parce que le serveur est basé sur Linux, et je ne sais pas si Linux l'accepte ou non.
EDIT: Il semble que le codage URL n'est PAS ce que je veux .. Voici ce que je veux faire:
old username = mas|fenix
new username = mas%xxfenix
Où% xx est la valeur ASCII ou toute autre valeur qui identifierait facilement le caractère.
Réponses:
Edit: Notez que cette réponse est désormais obsolète. Voir la réponse de Siarhei Kuchuk ci-dessous pour une meilleure solution
UrlEncoding fera ce que vous proposez ici. Avec C #, vous utilisez simplement
HttpUtility
, comme mentionné.Vous pouvez également Regex les caractères illégaux puis les remplacer, mais cela devient beaucoup plus complexe, car vous devrez avoir une certaine forme de machine d'état (commutateur ... cas, par exemple) pour remplacer par les bons caractères. Comme
UrlEncode
cela se fait d'avance, c'est plutôt facile.En ce qui concerne Linux par rapport à Windows, certains caractères acceptables sous Linux ne le sont pas, mais je ne m'inquiéterais pas à ce sujet, car le nom du dossier peut être renvoyé en décodant la chaîne Url, en utilisant
UrlDecode
, afin que vous puissiez aller-retour le changements.la source
A potentially dangerous Request.Path value was detected from the client
.J'ai expérimenté les différentes méthodes que .NET fournit pour le codage d'URL. Peut-être que le tableau suivant sera utile (en tant que sortie d'une application de test que j'ai écrite):
Les colonnes représentent les encodages comme suit:
UrlEncoded:
HttpUtility.UrlEncode
UrlEncodedUnicode:
HttpUtility.UrlEncodeUnicode
UrlPathEncoded:
HttpUtility.UrlPathEncode
EscapedDataString:
Uri.EscapeDataString
EscapedUriString:
Uri.EscapeUriString
HtmlEncoded:
HttpUtility.HtmlEncode
HtmlAttributeEncoded:
HttpUtility.HtmlAttributeEncode
HexEscaped:
Uri.HexEscape
REMARQUES:
HexEscape
ne peut gérer que les 255 premiers caractères. Par conséquent, il lève uneArgumentOutOfRange
exception pour les caractères latins A étendus (par exemple, Ā).Ce tableau a été généré dans .NET 4.0 (voir le commentaire de Levi Botelho ci-dessous qui dit que l'encodage dans .NET 4.5 est légèrement différent).
ÉDITER:
J'ai ajouté une deuxième table avec les encodages pour .NET 4.5. Voir cette réponse: https://stackoverflow.com/a/21771206/216440
EDIT 2:
Puisque les gens semblent apprécier ces tables, j'ai pensé que vous pourriez aimer le code source qui génère la table, afin que vous puissiez jouer autour de vous. Il s'agit d'une simple application console C #, qui peut cibler soit .NET 4.0 soit 4.5:
la source
Uri.EscapeUriString
, mais attention, il ne prend pas en charge unnull
argument.UrlPathEncode
. Remplacez doncUrlPathEncode
parUri.EscapeUriString
.Vous devez encoder uniquement le nom d'utilisateur ou une autre partie de l'URL qui pourrait être invalide. L'URL encodant une URL peut entraîner des problèmes car quelque chose comme ceci:
Rendra
Cela ne fonctionnera évidemment pas bien. Au lieu de cela, vous devez encoder UNIQUEMENT la valeur de la paire clé / valeur dans la chaîne de requête, comme ceci:
J'espère que cela aide. De plus, comme l' a mentionné teedyay , vous devrez toujours vous assurer que les caractères de nom de fichier illégaux sont supprimés, sinon le système de fichiers n'aimera pas le chemin.
la source
?
(car il suppose que la chaîne de requête est déjà encodée). Dans l'exemple de Dan Herbert, il semble qu'il prétend queExample
le texte nécessite un encodage, doncHttpUtility.UrlPathEncode("http://www.google.com/search?q=Example");
cela ne fonctionnera pas. Essayez-le avec?q=Ex&ple
(où le résultat souhaité est?q=Ex%26ple
). Cela ne fonctionnera pas car (1) UrlPathEncode ne touche plus à rien après?
, et (2) UrlPathEncode n'encode pas de&
toute façon.&
, car vous en avez besoin pour délimiter les paramètres de votre chaîne de requête. Mais il y a des moments où vous voulez aussi des esperluettes codées.La meilleure façon est d'utiliser
Uri.EscapeUriString
pour ne pas référencer le profil complet de .net 4.
la source
Uri.EscapeDataString
PASUri.EscapeUriString
Lisez ce commentaire, cela m'a aidé.Depuis .NET Framework 4.5 et .NET Standard 1.0, vous devez utiliser
WebUtility.UrlEncode
. Avantages par rapport aux alternatives:Il fait partie de .NET Framework 4.5+, .NET Core 1.0+, .NET Standard 1.0+, UWP 10.0+ et de toutes les plates-formes Xamarin.
HttpUtility
, tout en étant disponible dans .NET Framework plus tôt (.NET Framework 1.1+), devient disponible sur d'autres plateformes beaucoup plus tard (.NET Core 2.0+, .NET Standard 2.0+) et il n'est toujours pas disponible dans UWP (voir la question connexe ).Dans .NET Framework, il réside dans
System.dll
, il ne nécessite donc pas de références supplémentaires, contrairement àHttpUtility
.Il échappe correctement les caractères pour les URL , contrairement à
Uri.EscapeUriString
(voir les commentaires de la réponse de drweb86 ).Il n'a pas de limite sur la longueur de la chaîne , contrairement à
Uri.EscapeDataString
(voir question connexe ), il peut donc être utilisé pour les requêtes POST, par exemple.la source
Levi Botelho a indiqué que le tableau des encodages précédemment généré n'est plus précis pour .NET 4.5, car les encodages ont légèrement changé entre .NET 4.0 et 4.5. J'ai donc régénéré la table pour .NET 4.5:
Les colonnes représentent les encodages comme suit:
HttpUtility.UrlEncode
HttpUtility.UrlEncodeUnicode
HttpUtility.UrlPathEncode
WebUtility.UrlEncode
Uri.EscapeDataString
Uri.EscapeUriString
HttpUtility.HtmlEncode
HttpUtility.HtmlAttributeEncode
WebUtility.HtmlEncode
Uri.HexEscape
REMARQUES:
HexEscape ne peut gérer que les 255 premiers caractères. Par conséquent, il lève une exception ArgumentOutOfRange pour les caractères latins A étendus (par exemple, Ā).
Ce tableau a été généré dans .NET 4.5 (voir la réponse https://stackoverflow.com/a/11236038/216440 pour les encodages pertinents pour .NET 4.0 et ci-dessous).
ÉDITER:
la source
(Net4.0) ? %3f................................
(Net4.5) ? %3f ..................................
L'encodage d'URL est facile dans .NET. Utilisation:
Si cela va être décodé pour obtenir le nom du dossier, vous devrez toujours exclure les caractères qui ne peuvent pas être utilisés dans les noms de dossier (*,?, /, Etc.)
la source
Si vous ne voyez pas System.Web, modifiez les paramètres de votre projet. Le cadre cible doit être ".NET Framework 4" au lieu de ".NET Framework 4 Client Profile"
la source
L'implémentation .NET de
UrlEncode
n'est pas conforme à la RFC 3986.Certains caractères ne sont pas codés mais devraient l'être. Les
!()*
caractères sont répertoriés dans la section 2.2 du RFC en tant que caractères réservés qui doivent être codés mais .NET ne parvient pas à coder ces caractères.Certains caractères sont encodés mais ne devraient pas l'être. Les
.-_
caractères ne sont pas répertoriés dans la section 2.2 de la RFC en tant que caractère réservé qui ne doit pas encore être codé .NET code à tort ces caractères.Le RFC spécifie que pour être cohérent, les implémentations doivent utiliser HEXDIG en majuscules, où .NET produit HEXDIG en minuscules.
la source
Je pense que les gens ici ont été détournés par le message UrlEncode. L'URLEncoding n'est pas ce que vous voulez - vous voulez encoder des choses qui ne fonctionneront pas comme nom de fichier sur le système cible.
En supposant que vous vouliez une généralité - n'hésitez pas à trouver les caractères illégaux sur plusieurs systèmes (MacOS, Windows, Linux et Unix), réunissez-les pour former un ensemble de caractères à échapper.
Quant à l'évasion, un HexEscape devrait être bien (Remplacement des caractères par% XX). Convertissez chaque caractère en octets UTF-8 et encodez tout> 128 si vous souhaitez prendre en charge les systèmes qui ne font pas unicode. Mais il existe d'autres moyens, tels que l'utilisation de barres obliques inverses "\" ou d'encodage HTML "" ". Vous pouvez créer le vôtre. Tout système doit tout simplement" coder "le caractère incompatible. Les systèmes ci-dessus vous permettent de recréer le nom d'origine - mais quelque chose comme remplacer les mauvais caractères par des espaces fonctionne également.
Sur la même tangente que ci-dessus, la seule à utiliser est
- Il code tout ce qui est nécessaire pour OAuth, il ne code pas les choses que OAuth interdit de coder, et code l'espace en% 20 et non + (également dans la spécification OATH) Voir: RFC 3986. AFAIK, c'est le dernière spécification d'URI.
la source
J'ai écrit une méthode C # qui encode tous les symboles par URL:
la source
Idéalement, ceux-ci iraient dans une classe appelée "FileNaming" ou peut-être simplement renommer Encode en "FileNameEncode". Remarque: ceux-ci ne sont pas conçus pour gérer les chemins d'accès complets, uniquement les noms de dossier et / ou de fichier. Idéalement, vous diviseriez ("/") votre chemin complet en premier, puis vérifieriez les morceaux. Et évidemment, au lieu d'une union, vous pouvez simplement ajouter le caractère "%" à la liste des caractères non autorisés dans Windows, mais je pense que c'est plus utile / lisible / factuel de cette façon. Decode () est exactement le même mais commute le Replace (Uri.HexEscape (s [0]), s) "échappé" avec le caractère.
Merci @ simon-tewsi pour le tableau très utile ci-dessus!
la source
Path.GetInvalidFileNameChars()
En plus de la réponse de @Dan Herbert, vous nous devriez encoder uniquement les valeurs en général.
Split a le paramètre params Split ('&', '='); expression d'abord divisée par & puis '=' donc les éléments impairs sont toutes les valeurs à encoder indiquées ci-dessous.
la source