Comment puis-je appliquer utf8 dans le taglib struts1?

Question

J'ai maintenant la tâche la plus merveilleuse, le rêve de tous les programmeurs. Il y a un logiciel d'environ 15 ans ici, et je n'ai qu'à corriger quelques "bugs" dedans. 32 bits java6, tomcat6, code source non-unicode, système de construction de fourmi, et tout ce que je peux seulement "aimer".

Remarque, je n'ai l'alimentation que sur un fichier .war, donc les paramètres côté serveur ne sont pas corrects.

Answer 1

Votre principal problème réside probablement dans la balise <bean:message>, bien que d'autres balises puissent également poser problème.

Le noyau Java supporte utf8 depuis ses tout premiers jours alpha, mais il y a malheureusement une exception dans la gestion des fichiers .properties. Ces fichiers sont toujours interprétés iso8859-1 par les appels de l'API JDK. Les taglib Struts1 utilisent des chaînes i18n adressées par des clés, stockées dans des fichiers *.properties. Creuser un peu dans la source de struts1, j'ai trouvé ces:

• Il lit les fichiers .properties avec les appels JDK, donc toujours en iso8859-1. Il est profondément câblé dans le code, il n'y a aucun moyen de le changer.
• Il y a un paramètre de paramètres régionaux ou localeKey dans les entretoises 1, qui peuvent être modifiés par divers system.properties ou web.xml paramètres, le .properties sera toujours lu comme toujours iso8859-1. Cette locale/localekey ajoute seulement une extension supplémentaire au fichier de propriétés réellement interprété.
• Il n'y a aucun moyen de le modifier, sans forcer/dupliquer la partie correspondante des struts1, et en appliquant quelque chose de non standard dans les en-têtes de propriétés JDK pour appliquer les normes à leurs conventions. Ce n'est pas une chose très pratique dans le cas d'un tel code de relique.

Bien que les entretoises et les autres parties de votre système (par exemple, l'analyseur/interprète JSP) -t déjà une certaine conversion comme nécessaire, donc ce texte iso8859-1 sera être converti en UTF8, si vos pages JSP sont correctement configurées (méta en-têtes, etc.).

En outre, le lecteur de propriétés utilise une fonctionnalité - similairement câblée, indissociable - pour prendre en charge un peu utf8. Il accepte les caractères utf8 sous la forme \uC0DE. Ainsi, après un \u ou \U (insensible à la casse), vous pouvez donner une valeur hexa de 16 bits, pouvant être et unicode.

Il doit toujours avoir une longueur de 16 bits, les autres longueurs ne sont pas autorisées, mais elles sont déjà insensibles à la casse.

Ainsi,

my.property.key=árvíztűrő tükörfúrógép 

... codé en UTF8, ne fonctionnera pas, il sera interprété comme iso8859-1.

Vous pouvez entrer cette chaîne comme iso8859-1. Cela ne peut pas fonctionner, car certains des accents n'ont pas de mappage iso8859-1, c'est-à-dire qu'ils n'existent pas dans le codage iso8859-1.

Cependant, si vous encodez dans le format décrit ci-dessus:

my.property.key=\u00E1rv\u00EDzt\u0171r\u0151 t\u00FCk\u00F6rf\u00FAr\u00F3g\u00E9p 

alors oui, il fonctionnera! Pour faire cette conversion, le Sun avait un outil native2ascii, qui est inaccessible aujourd'hui.

Vous devez creuser cet outil à partir de certaines archives sur le net, ou en trouver un autre.

Sous Linux, il existe un outil nommé uni2ascii (sur les distributions basées sur Debian, vous pouvez l'installer avec apt-get install uni2ascii), qui effectue la conversion correcte. Les paramètres corrects sont:

uni2ascii -a U myfile.properties 

Le résultat est renvoyé à la sortie standard.

À vous de voir comment vous l'intégrez dans votre système de construction (un module d'exécution ant/maven, ou utilisez-le simplement pour changer à chaque fois, manuellement).