使用qqwry.dat进行IP地理位置查询时，遇到一个问题即在本地测试时查询纯真库时正常，没有任何问题，但是打包传到服务器上便出现了乱码问题。
1.首先排除服务器的字符集编码的影响
使用如下命令验证了本地和服务器的编码是一致的
[root@master ~]# echo $LANG en_US.UTF-8
2.查看qqwry.dat发现该文件是二进制文件，文件自身不存在编码的问题
[root@master ~]# file -i qqwry.dat qqwry.dat: application/octet-stream; charset=binary
3.从IP库中读取并encoding的时的时候会不会有问题？发现同样在本地都是显示正常，但是传到服务器上全都是乱码。
logger.info("utf-8"+new String(b, offset, len, "utf-8"));
logger.info("gbk"+new String(b, offset, len, "gbk"));
logger.info("gb2312"+new String(b, offset, len, "gb2312"));
4.公司前辈，指点迷津 让我把未编码前的信息打出来，我把byte[]数组里面的二进制数据打印出来
public static String getString(byte[] b, int offset, int len, String encoding) {
try {
String bts="";
for(int i=0;i<b.length;i++){
bts = bts+String.valueOf(b[i]);
}
logger.info("bytes [] "+bts);
return new String(b, offset, len, encoding);
} catch (UnsupportedEncodingException e) {
return new String(b, offset, len);
}
}
5. 问题出来了，同一个IP从IP库中获取的byte数组是不一样的！！！
6. 为什么读取出来的信息是不一样的？使用md5sum查看一下文件的md5是否一致，发现本地的qqwry.dat的md5居然和服务器上的不一致！
[root@master target]# md5sum qqwry.dat 8ad56a81343333406a78cfc81ad44cb7 qqwry.dat [root@master target]# md5sum qqwry.dat 3c1db0363910a08a4cc2bbd81e1b0e14 qqwry.dat
7.将本地qqwry.dat scp传到服务器上,是可以的。
8.打包之后的文件不行？直接scp传上去的是正确的？难道是打包的时候出错了吗？
再一次打包上传，发现不仅md5不一样而且文件大小差距也很大，
[root@master target]# du -h qqwry.dat 8.9M qqwry.dat [root@master target]# du -h qqwry.dat 16M qqwry.dat
9.我擦，仔细检查了一下自己maven项目qqwry.dat放到了resources目录下，看不出来什么问题。
查阅资料得知，是因为在maven打包时，对于二进制类型的文件，需要filter过滤掉不然文件会错乱掉！
修改pom.xml的配置内容，重新打包之后发现文件正常了，和源文件的大小是一样的了，上传之后重新测试也是ok了。
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-resources-plugin</artifactId> <version>2.4.3</version> <configuration> <encoding>UTF-8</encoding> <nonFilteredFileExtensions> <nonFilteredFileExtension>dat</nonFilteredFileExtension> </nonFilteredFileExtensions> </configuration> </plugin>
10.查阅官网的解释http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html，非常明了！
总结：
maven打包时如果有用到二进制类型的资源文件，记得在pom.xml中将其过滤掉，不然编译打包完成之后产生的文件会和打包前的不一样。
qqwry.dat输出乱码问题及maven打包后资源文件大小不一致的问题
原文：https://www.cnblogs.com/lingyejun/p/8762874.html