bonjour,
 
j'ai développé un webservice avec lequel il reçoit des messages en POST HTTP mais voila, par défaut, le content-type est reglé sur :
 
application/x-www-form-urlencoded
 
or notre client envoit des chaines au format XML et donc dès l'arrivée du message, certains caractères comme le "é", "à" sont supprimés!
 
la solution serait (peut-être) de régler le content-type du webservice sur : "text/xml"
 
mais je ne sais pas comment faire, please help!
 
merci d'avance

voila, j'ai fais quelques tests :
 
lorsque j'envois cette chaine : "Paratel test: /é/è/à/ç/ù/"
 
voici à quoi ressemble la chaine lors de l'envoi :
 
3EParatel+test%3A+%2F%E9%2F%E8%2F%E0%2F%E7%2F%F9%2F
 
j'ai essayé les URLDECODE et HTMLDECODE mais apparemment, ce n'est pas ca...
 
merci d'avance

Comprend pas bien...
- Tu créé ton web service avec VS.Net ?
- Tu utilises ASP.Net ?
Si oui, la partie concernant l'encodage des requêtes/réponse se trouve dans le web.Config, section 'globalization'.
Ca ressemble à ça par défaut :
   <globalization requestEncoding="utf-8" responseEncoding="utf-8" />
Mais je pense pas que ça résolve ton pb...
- A ma connaissance, le content-type ne dépend pas du web service mais du serveur web : tu utilises IIS ?
- Tu pourrais décrire un peu plus ton archi stp ? C'est quoi ton client, une appli ASP.Net ?
- La chaîne que tu nous montre, c'est à quel bout de ton système que tu l'as prise ? L'envoi de quoi vers quoi ?

tout d'abord merci pour ton implication.
 
en fait, j'ai crée un webservice en asp.net (VB.net en code behind pour être précis) avec visual .net 2003 et c'est un webservice on ne peut plus banal (1 méthode).
en pratique le webservice doit s'attendre à recevoir des messages en POST HTTP (peu importe la source, que ce soit en provenance du web ou d'une application stand alone, du moment que post http arrive, il traite)
techniquement, j'ai autorisé dans le web.config la communication en Post HTTP
 
donc pour utiliser le webservice, on peut soit l'utiliser manuellement (avec le bouton INVOKE) soit de manière automatique (c'est la le but)
et pour faire de l'automation, il faut faire du POST HTTP ou du GET HTTP.
 
or notre client ne sait faire que du POST HTTP donc ca ressemble a ca :  
 
POST /WSParatel/Service1.asmx/PostData HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: length
 
XML=string
 
réponse si tout OK :  
 
HTTP/1.1 200 OK
 
 
comme tu peux le constater il s'attend a un message de type "application/x-www-form-urlencoded"
mais avec ce format, les "é", "à" et bien d'autres caractères sont remplacés par des "?" ou supprimés carrément
 
et pour moi la solutio serait de dire au webservice qu'il doit s'attendre à non plus des messages dont le content-type est : "application/x-www-form-urlencoded" mais du "text/xml"
 
ou bien comme tu dis, ca se pourrait que ca provienne du serveur IIS... mais la je ne m'y connais pas trop.
 
et pour ce qui est du globalization, que me conseillerais tu de faire? car utf-8 n'est pas trop parlant, et puis je ne sais pas quoi faire avec...
 
une piste aussi, c'est que MSDN précise que lorsqu'on fait du POST HTTP, il y a un URLENCODE qui se passe... mais j'ai essayé dès la réception du message xml de faire un system.web.webutility.urldecode et un htmldecode mais rien n'y fait... toujours ce bug.
 
merci d'avance.

 Bon... j'ai développé du Web service, mais je suis toujours resté loin des questions de protocoles, très haut niveau, donc je suis pas sûr de pouvoir t'aider.
* Après renseignement, il est normal que ton content-type soit application/x-www-form-urlencoded, c'est parce que tu utilises du POST. Ca ne peut pas se changer, c'est comme ça.
* A ce que j'ai lu, la chaîne est effectivement UrlEncodée.
* Ta chaîne résultante ressemble furieusement à une chaîne UrlEncodée. J'ai essayer de la décoder et le résultat n'est pas terrible.
* J'ai aussi essayé d'UrlEncoder la chaîne de départ, et je tombe sur Paratel+test%3a+%2f%c3%a9%2f%c3%a8%2f%c3%a0%2f%c3%a7%2f%c3%b9%2f   Donc on n'est pas loin....
 
Ce qui pourrait expliquer la différence au niveau de l'encodage c'est le jeu de caractère utilisé.
- Regarde si ton client envoie des chaînes au format UTF-8.
- Quel jeu de caractère est utilisé par ton client dans ses requêtes ?  c'est bien charset=ISO-8859-1 ?
Si c'est pas ça, ça expliquerait pourquoi les caractère accentués ne passent pas : la norme ISO-8859-1 défini les caractères latins.

exact, j'ai "simulé" un envoi en post http avec un System.Web.HttpUtility.UrlEncode(chaine)
et ca arrive au webservice parfaitement!!! même le "&" n'a pas été traité comme un paramètre!
 
donc la solution serait que notre client "urlencode" son message... seulement il ne veut pas...
 
mais ta piste sur le charset=ISO-8859-1 m'interesse beaucoup car notre client en effet envoit sous cette norme...

Quand tu simules le client avec une chaîne UrlEncodée par toi, ça marche bien ?
Bon... bein visiblement le problème vient de l'appli cliente. Pour le prouver, il te suffirait de créer un site web très simple qui utilise ton web service.
 
Ton appli cliente c'est de l'ASP.Net ? Si oui : j'imagine que t'as essayé de faire un update de la web référence ?
Il fonctionne bien en UTF-8 ton client ?  L'appli cliente, elle doit avoir un Web.Config. Si tu peux regarder dedans...
 
Si ton appli cliente utilise le charset ISO-8859-1, c'est bon. C'est le jeu de caractère latins, ça veut dire qu'elle comprend les caractères accentués

voilaaaaaaaaaaaa
tu avais raison, c'était bien le format iso le probleme!!!
maintenant ca fonctionne super!!
grand merci!!!

Juste pour info, tu as modifié quoi sur quoi pour que ça fonctionne ?
côté client ou service ?

côté service dans globalization.
 
le client, je n'ai pas accès, tout ce que je sais, c'est qu'il m'envoit en iso

Bonjour  
 
j'ai un peu le même pb  
pouvez vous m'expliquer quel est la solution à ce problème  avec globalization
 
Merci