Maven2上演狸猫换太子――字符编码造成的诡异故障
字符编码界的混乱我们在此不想多提，我们只能祈祷所依赖的平台和环境能够尽可能完善的处理它们…
但是，吃芝麻还有掉烧饼的时候，字符编码似乎像赶不走的幽灵，时不时的来恼你一下…这不，Maven2也被它劫持，跟我来了个狸猫换太子…
莫名其妙的没有问题之前使用Maven2作为项目的构建工具，运行的一直很好，虽然每次启动的时候都有
但是就在昨天，我用eclipse打开了几个xml并关闭（并未做修改）之后，项目开始出现问题，war无法被正常部署到tomcat上，而使用mvn tomcat:run-war直接运行时，提示如下异常：
根据提示，找到出此问题的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即可，如下：
<plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-resources-plugin</artifactId><version>2.5</version> <configuration><coding>UTF-8</encoding></configuration></plugin>
