Maven2上演狸猫换太子――字符编码造成的诡异故障

本文主要是介绍Maven2上演狸猫换太子――字符编码造成的诡异故障，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

字符编码界的混乱我们在此不想多提，我们只能祈祷所依赖的平台和环境能够尽可能完善的处理它们 …

但是，吃芝麻还有掉烧饼的时候，字符编码似乎像赶不走的幽灵，时不时的来恼你一下 … 这不， 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 直接运行时，提示如下异常：

根据提示，找到出此问题的 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>

这篇关于Maven2上演狸猫换太子――字符编码造成的诡异故障的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！