字符编码界的混乱我们在此不想多提，我们只能祈祷所依赖的平台和环境能够尽可能完善的处理它们
…
但是，吃芝麻还有掉烧饼的时候，字符编码似乎像赶不走的幽灵，时不时的来恼你一下
…
这不，
Maven2
也被它劫持，跟我来了个狸猫换太子
…
莫名其妙的没有问题
之前使用
Maven2
作为项目的构建工具，运行的一直很好，虽然每次启动的时候都有
[WARNING] Using platform encoding (GBK
actually) to copy filtered resources, i.e. build is platform dependent!
的警告，但开发机和服务器分别属于
windows
和
linux
系统，均没有出问题，所以也没有太过在意它。
莫名其妙的出了问题
但是就在昨天，我用
eclipse
打开了几个
xml
并关闭（并未做修改）之后，项目开始出现问题，
war
无法被正常部署到
tomcat
上，而使用
mvn tomcat:run-war
直接运行时，提示如下异常：
|
com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException: at at … |
根据提示，找到出此问题的
xml
文件，其中存在中文，但并没有发现什么异常，从
svn
中
revert
，也无法解决问题。而在服务器（
linux
环境）上，没有任何异常出现。
莫名其妙的找不到原因
由于之前被字符编码折磨过多次，而在此之前这些文件中包含中文并没有问题，因此首先意识到是不是
BOM header
的问题，于是找来
UltraEdit
，打开分析出问题的
xml
文件，发现确实前三个字节被
UTF-8
的
BOM header
占据了，于是将其去掉，运行
…
故障依旧。
此路不通，另辟他径，试着将文件中的中文全部删除，异常没有了
…
虽然变相的解决了这个问题，但是，没有
BOM header
和不支持中文始终让人感到不爽，而且既然是
UTF-8
的编码，就没有理由让我用回英文。真相还是没有出来。
莫名其妙的被调包了
正向分析找不到原因，看来只能逆向跟踪每个步骤来找线索了（极度怀疑自己是不是破案片看多了）。找到被打包的
war
文件，解压，查看，果然发现
xml
文件被损坏（中文全部变成了乱码）！
看来是中间过程中文件被损坏了。仔细检查了一下整个自动化过程，发现构建、打包的时候有被修改的可能，于是又打开
target
目录下的
class
目录（即打包之前的文件目录），发现这里的
xml
也被破坏了，那么可以初步断定，资源文件在被复制出来的时候，被调了包。
真相大白
经过逐步检查，发现原来是
Maven2
在复制资源文件时，使用系统编码（也就是上面那个警告所提到的）对资源进行解码，从而造成了
UTF-8
文件被当做
GBK
（
windows
下默认编码是
GBK
）来解码，损坏了
xml
文件。而出现这一情况都是昨天在
pom.xml
中加入
resource
标签之后，那么到此问题真相大白了。
既然找到原因所在，那么解决它也很容易，在
maven-resources-plugin
插件中配置
encoding
为
UTF-8
即可，如下：
