Un autre JQuery problème d'encodage, sur IE
Je code un site italien où j'ai besoin de valider certaines données d'entrée avec un xhr appel.
Mon code pour la requête ajax est comme ça (je suis en utilisant JQuery 1.3.2):
$.ajaxSetup({
type: "POST",
timeout: 10000,
contentType: "application/x-www-form-urlencoded; charset=iso-8859-1"
});
$.ajax({
url: "ajaxvalidate.do",
data: {field:controlInfo.field,value:controlInfo.fieldValue},
dataType: "json",
complete: function() {
//
},
success: function(msg) {
handleAsyncMsg(controlInfo, msg, closureOnError);
},
error: function(xhr, status, e) {
showException(controlInfo.id, status);
}
});
Sur le backend, j'ai un java struts action pour gérer le xhr. J'ai besoin d'utiliser l'encodage ISO-8859-1 dans la page pour s'assurer que les données (spécialement les caractères accentués) sont correctement envoyés dans le synchrone soumettre.
Tous les de travailler comme un charme dans Firefox, mais quand je dois gérer un async poste d'IE 7 avec les caractères accentués, j'ai un problème: je reçois toujours des caractères non valides (utf-8 peut-être?).
Par exemple de type I dans la forme àààààààà et je reçois dans ma demande de cette valeur: Ã Ã Ã Ã Ã Ã Ã Ã.
Depuis la demande charset est correctement mise en place de l'ISO-8859-1, je ne comprends pas pourquoi le serveur est toujours pas à l'analyse de la forme de la valeur correctement.
C'est un journal de l'échantillon avec tous les en-têtes de requête et de l'erreur (le serveur est un vieux Bea Weblogic 8.1):
Encoding: ISO-8859-1
Header: x-requested-with - Value: XMLHttpRequest
Header: Accept-Language - Value: it
Header: Referer - Value: https://10.172.14.36:7002/reg-docroot/conv/starttim.do
Header: Accept - Value: application/json, text/javascript
Header: Content-Type - Value: application/x-www-form-urlencoded; charset=iso-8859-1
Header: UA-CPU - Value: x86
Header: Accept-Encoding - Value: gzip, deflate
Header: User-Agent - Value: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Header: Host - Value: 10.172.14.36:7002
Header: Content-Length - Value: 65
Header: Connection - Value: Keep-Alive
Header: Cache-Control - Value: no-cache
Header: Cookie - Value: JSESSIONID=JQJlNpVC86yTZJbcpt54wzt82TnkYmWYC5VLL2snt5Z8GTsQ1pLQ!1967684811
Attribute: javax.net.ssl.cipher_suite - Value: SSL_RSA_WITH_RC4_128_MD5
Attribute: javax.servlet.request.key-size - Value: 128
Attribute: javax.servlet.request.cipher_suite - Value: TLS_RSA_WITH_RC4_128_MD5
Attribute: javax.servlet.request.key_size - Value: 128
Attribute: weblogic.servlet.network_channel.port - Value: 7001
Attribute: weblogic.servlet.network_channel.sslport - Value: 7002
Attribute: org.apache.struts.action.MESSAGE - Value: org.apache.struts.util.PropertyMessageResources@4a97dbd
Attribute: org.apache.struts.globals.ORIGINAL_URI_KEY - Value: /conv/ajaxvalidate.do
Attribute: errors - Value: org.apache.struts.util.PropertyMessageResources@4a97e4d
Attribute: org.apache.struts.action.MODULE - Value: org.apache.struts.config.impl.ModuleConfigImpl@4aa2ff8
Attribute: weblogic.servlet.request.sslsession - Value: javax.net.ssl.impl.SSLSessionImpl@42157c5
field: nome - value: ÃÃÃÃÃÃÃÃ - action: /endtim
OriginalL'auteur Marco Z | 2009-03-18
Vous devez vous connecter pour publier un commentaire.
Vous pouvez dire vous êtes l'envoi d'un formulaire de soumission de l'ISO-8859-1 dans l'en-tête, mais cela ne signifie pas que vous êtes réellement. jQuery utilise le standand JavaScript encodeURIComponent() méthode pour encoder des chaînes Unicode dans la chaîne de la requête octets, et que toujours utilise UTF-8.
Dans tous les cas, le paramètre charset pour le type MIME " application/x-www-form-urlencoded’ est fortement non-standard. Comme un ‘x-type n'est pas encore officielle MIME enregistrement pour ce type, mais HTML 4.01 ne spécifiez pas ce paramètre, et il serait très inhabituel pour une " application/*’ type. Weblogic prétend détecter cette construction, pour ce que ça vaut.
Donc ce que vous pouvez faire est soit:
1: création d'un POSTE de corps form-urlencoded content-vous, il le piratage en ISO-8859-1 format manuellement, en utilisant quelque chose comme
au lieu de encodeURIComponent().
2: perdre la ‘charset’, et laisser la soumission de l'UTF-8 comme d'habitude, et faire de votre servlet comprendre entrant UTF-8. Ceci est généralement mieux, mais signifie marinage avec le conteneur de servlet config pour le faire choisir le bon encodage. Pour Weblogic cela semble signifier à l'aide d'un <input-charset> élément dans weblogic.xml. Et puis vous êtes à la recherche de déménager l'ensemble de votre application à l'UTF-8. Ce qui n'est pas une mauvaise chose (non-compatibles Unicode sites web sont sooo 20-siècle!) mais peut-être beaucoup de travail.
OriginalL'auteur bobince
Fait juste résolu, j'avais besoin de faire:
jQuery.ajaxSetup({
contentType: "application/json;charset=utf-8"
});
Qui remplace le comportement de l'ajout de l'application/x-www-form-urlencoded pour le type de contenu dans IE.
OriginalL'auteur
J'ai eu des problèmes similaires, en travaillant dans un contenu, système de commentaires dans notre espagnol Portail.
Ce qui a finalement résolu mon problème, après de nombreuses heures de recherche, au lieu de vous embêter avec jQuery jeu de caractères, qui semble utiliser l'utf-8 n'importe quoi, c'était pour décoder de l'utf-8 en ISO-8859-1 dans le PHP de traitement de l'ajax POST. En PHP il y a un construit en fonction utf8_decode(), donc la première chose que je fais avec les commentaires de chaîne est ceci:
$comentario = utf8_decode($_POST['comentario']);
(et puis j'ai utilisé nl2br() et htmlentities() les fonctions de PHP afin de préparer le texte pour être stockés avec des entités html à la place des caractères spéciaux)
Bonne Chance & la Paix dans tous les coins!
Seba
OriginalL'auteur Sebastian Alberoni