9
votes

Encodage UTF-8 avec contrôleur de poste et ressort de forme

J'essaie de soumettre un formulaire, qui a des caractères UTF8 à l'intérieur. La forme ressemble à ceci: xxx pré>

mon serveur est basé sur le printemps. Mon web.xml a déjà le filtre de codage: P>

 <filter>
     <filter-name>EncodingFilter</filter-name>
     <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
     <init-param>
         <param-name>encoding</param-name>
         <param-value>UTF-8</param-value>
     </init-param>
     <init-param>
         <param-name>forceEncoding</param-name>
         <param-value>true</param-value>
     </init-param>
 </filter>

html spring spring-mvc utf-8 forms

0 commentaires

3 Réponses :

1
votes

Je vous suggère de supprimer le caractèreCodingfilter, qui peut être lui-même la cause du double codage.

Pour déboguer la SITUATION, vous devez d'abord vérifier si le navigateur affiche les données correctement. Utilisez Firebug (pour Firefox) ou des outils de développeurs sur Chrome (F12)

Très probablement, le problème est au niveau du serveur. Quel serveur utilisez-vous? Si vous utilisez Tomcat, vous devez définir le caractère CharseCoding sur UTF-8 sur l'élément de connecteur dans serveur.xml

Mise à jour 1:

Il semble très probable que le problème soit le forcentable que vous définissez. Selon le docs

Ce filtre peut soit appliquer son codage si la demande ne spécifier déjà un codage ou appliquer le codage de ce filtre dans n'importe quel cas («forcoding» = «vrai»)
Lorsque vous faites un get, il n'y a pas de codage spécifié, il est donc logique que cela fonctionne.
Toutefois, lorsque vous faites le message, le codage est déjà appliqué et puis (il semble) est appliqué à nouveau à cause du forcercoding = true

3 commentaires

J'ai vérifié Firebug tout va bien. Si je viens de faire une demande d'obtention au lieu de poster, tout fonctionne.

Non, ce filtre n'encore rien, il définit simplement le codage de la demande en tant que UTF8. Qui est en fait la bonne chose à faire.

J'ai posté la solution. Truc est de monter le filtre de codage en haut.

4
votes

Avez-vous une entrée de mappage de filtre dans votre web.xml pour encodingfilter?

<filter-mapping>
  <filter-name>EncodingFilter</filter-name>
  <url-pattern>*</url-pattern>
</filter-mapping>

0 commentaires

11
votes

On dirait que les navigateurs n'envoient pas le charert dans le cadre des en-têtes de demande de contenu (même lorsque l'acceptation-Charset sur le formulaire est défini) et Tomcat traite du corps de telles demandes que la latine-1 (Http://wiki.apache.org/tomcat/faq/characterencoding#q1 ).

Donc, à un point ultérieur, cela aurait peut-être été décodé comme latin-1 et codé comme UTF-8 entraînant des caractères grassé.

Caractéristençage en mouvementFilter en haut et forçant le codage à définir comme UTF-8 a résolu le problème.

1 commentaires

De nombreux problèmes liés, mais le problème réel était avec l'ordre des filtres dans web.xml