J'essaie d'envoyer une demande à une URL comme celle-ci "http://mysite.dk/tvÃ|rs?test=Ã|" à partir d'une application ASP.NET, et j'ai du mal à obtenir le querystring à encoder correctement. Ou peut-être que le requérant est codé correctement, le service que je connecte ne le comprend pas correctement.
J'ai essayé d'envoyer la demande avec des navigateurs différents et de vous connecter à la manière dont ils encodent la demande avec Wireshark, et je reçois ces résultats : P>
var uri = new Uri("http://mysite.dk/tværs?test=æ");
// now uri.AbsolutePath == "http://mysite.dk/tv%C3%A6rs?test=%C3%A6"
3 Réponses :
Avez-vous essayé l'urlencode?
UrlenCode retourne "http% 3a% 2f% 2fmysite.dk% 2ftv% C3% A6RS% 3FTEST% 3D% C3% A6" qui est totalement faux. Je peux diviser la corde sur '?' et coder le querystring avec httTputilité.urlencode (qstr, coding.gecoding.gecoding ("ISO-8859-1")) puis fixez-le et; Caractères, mais cela ressemble plus à un piratage qu'une solution ...
On dirait que vous appliquez UrlenCode sur toute l'URL - ce n'est pas correct, les trajectoires et les chaînes de requête sont codées différemment comme vous l'avez vu. Qu'est-ce qui fait le codage de l'URI, WebRequest?
Vous pouvez construire manuellement les différentes pièces en utilisant un uribuilder ou codez manuellement en utilisant urlpathencode pour le chemin et UrlenCode pour le Query String Noms et valeurs.
EDIT:
Si le problème réside dans le chemin, plutôt que la chaîne de requête que vous pourriez essayer d'allumer IRI Support , via web.config Cela devrait ensuite laisser des caractères internationaux seuls sur le chemin.
Le service retourne CHRSTE = UTF8 et l'objet HTTPWEBRESPONSONSE qui le reçoit correctement le détermine correctement. Je ne suis pas sûr de savoir comment lire (ou changer) le caractère défini sur l'objet de la demande. L'uribuilder peut être la voie à suivre - je suis juste mystifié qu'il n'y a pas une forme de norme pour cela.
Modifier ajouté - Essayez de configurer IRI (RFC3987) Support qui devrait quitter le chemin unique, mais je pense que UTF8 sera le seul codage de la chaîne de requête prise en charge, la spécification HTML4 l'avait comme une recommandation et il est en quelque sorte devenu de degré de facto.
J'ai fini par changer de service Web à distance pour vous attendre à ce que la requête soit codée UTF-8. Il résout mon problème immédiat, le service Web ne peut pas être correctement appelé à la fois par PHP et le .NET Framework.
Cependant, le comportement est maintenant étrange dans les navigateurs. Copier en coller une URL comme "http://mysite.dk/tv%c3%a6rs?test=%C3%A6" dans le navigateur, puis appuyez sur les travaux de retour, il corrige même les caractères codés et affiche l'emplacement comme "http:" http: //mysite.dk/tværs?test=æ ". Si puis rechargez la page (F5), cela fonctionne toujours. Mais si je clique sur la barre d'emplacement et appuyez à nouveau sur RETURN, le QUERYString sera codé avec latin-1 et échouer.
Pour toute personne intéressée ici est un ancien bugfox BugReport sur le problème: https: // bugzilla .mozilla.org / show_bug.cgi? Id = 284474 (merci à @DTB)
Alors, il semble qu'il n'y a pas de bonne solution.
Merci à tous ceux qui ont aidé cependant!
Quel est le code ASP.NET qui génère le présent
http://mysite.dk/tv%C3%A6RS?HEST=%C3%A6 ?Je suis à peu près sûr que UTF-8 est le codage correct à utiliser. Je ne peux pas sembler trouver une source faisant autorité pour cela. ( RFC3986 ne dit pas pour les chaînes de requête; Wikipedia dit" Pour un caractère non ASCII, il est typiquement converti en sa séquence d'octets dans UTF-8, puis chacun La valeur d'octet est représentée comme ci-dessus. ".)
@DTB Ouais, je lis cela aussi, mais il semble que les navigateurs (et curl) ont plus ou moins décidé à l'unanimité d'utiliser latin1 pour coder Querystrings. Je préférerais utiliser UTF-8 partout, mais je préférerais également soutenir les navigateurs dans mon service Web ...
Je semble que les navigateurs violent la spécification des raisons historiques (voir par exemple BugZilla.Mozilla.org ). Le comportement .NET est le bon. Solution simple: n'utilisez pas de chaînes de requête. (Les chemins semblent bien fonctionner.)