我现在有一个最美妙的任务，所有程序员的梦想。这里大约有15年的软件了，我只需要修复其中的“一些错误”。 32位java6，tomcat6，非unicode源代码，ant构建系统以及所有我只能“喜欢”的东西。
注意，我仅对.war文件具有控制权，因此服务器端设置不正确。
最佳答案
您的主要问题可能在于<bean:message>标记，尽管其他标记也可能有问题。
Java内核自utf8早期以来就支持utf8，但是不幸的是，.properties文件的处理中有一个例外。这些文件始终由JDK API调用解释为iso8859-1。
Struts1标记库使用由键寻址的i18n字符串，这些字符串存储在*.properties文件中。深入研究struts1源，我发现了以下这些内容：
它使用JDK调用读取.properties文件，因此始终在iso8859-1中读取。它与代码紧密相连，无法更改。
Struts 1中有一个locale或localeKey参数，可以通过各种system.properties或web.xml设置更改该参数，.properties仍将始终读为iso8859-1。此语言环境/区域设置密钥仅向实际解释的属性文件添加额外的扩展名。
没有分叉/复制struts1的相应部分，并在JDK Properties标头中强制执行一些非标准的事情，以使标准遵循其约定的方法，就无法更改它。在这种遗留代码的情况下，这不是一件很方便的事情。
尽管Struts和系统的其他部分（例如，JSP解析器/解释器）已经根据需要进行了一些转换，但是如果正确设置了JSP页面（元标头），则此iso8859-1文本将转换为utf8。等等）。
此外，属性读取器使用了类似的硬连线的禁用功能，以对utf8稍加支持。它接受\uC0DE格式的utf8字符。因此，在\u或\U（不区分大小写）之后，可以提供16位十六进制值，该值可以是和Unicode字符。
它必须始终为16位长，不允许其他长度，但是这些长度已经不区分大小写。
从而，
my.property.key=árvíztűrő tükörfúrógép
...编码为utf8，将无法使用，它将被解释为iso8859-1。
您可以输入此字符串作为iso8859-1。它不起作用，因为某些重音没有iso8859-1映射，即它们不存在于iso8859-1编码中。
但是，如果将其编码为上述格式：
my.property.key=\u00E1rv\u00EDzt\u0171r\u0151 t\u00FCk\u00F6rf\u00FAr\u00F3g\u00E9p
那是的，它将起作用！
为了进行此转换，Sun使用了
native2ascii工具，该工具今天无法使用。您必须从网络上的某个档案中挖掘该工具，或者找到其他工具。在Linux上，有一个名为
uni2ascii的工具（在基于debian的发行版中，您可以使用apt-get install uni2ascii进行安装），该工具可以进行正确的转换。正确的参数是：uni2ascii -a U myfile.properties
结果进入标准输出。
这取决于您，如何将其集成到构建系统（一些ant / maven exec模块，或者每次手动更改时都只使用它）。