FTP服务器中文环境引起润日下载不了附件问题解析

20160229日某农商行因为FTP下载功能有问题，导致当天所有涉及FTP文件下载的交易都不能正常使用，对于银行来说影响还是比较大。现将当天出问题的原因及处理过程解析如下，忘能给碰到类似问题的同行以供参考。

当天早上一上班就接到电话有人说信贷系统很多交易用不了，查看日志都是报的找不到文件，无法解析。

后经过多方人员的共同努力查找和排查，最终确认是ReceiveFileTransfer.java类中的transfer()方法调用Apache组件commons-net-1.4.1.jar的listFiles时返回空问题引起，结合网上结论推断原因是目标服务器的中文语言环境，导致文件的修改日期格式，不能被apache正确解析造成的。（2月29）

问题原因是定位到了，当务之急是如何快速让生产环境恢复正常运行，而不影响日常业务开展。

经过多方讨论共提供三种解决方案：

1、将目标服务器中当天使用频繁的交易所生成的文件临时改到20160228目录下；

2、根据网上处理经验替换commons-net-1.4.1.jar包中的两个文件（FTPTimestampParserImplExZH.class、UnixFTPEntryParser.class）

3、第2点的变向处理，不改jar包，使用时动态选择解析类；

以上三种方案，当时先用第1种解决燃眉之急，以保证重要交易能正常使用；第2种考虑还是会存在一定风险，因为该系统使用年数比较旧，jdk版本也比较底，直接修改jar中的内容，一时无法保证对其它功能没有影响；所以最后的永久处理方案还是选择了第3点。下面就针对这种解决方案做以下详述：

以下是代码跟踪步骤及解决方法：

1)        由以下代码可知，FTP下载前会检查listFiles()所得到的fileList.size()是否大于0，只有大家于0的时候才会调附件下载的方法。

2)        通过反编译commons-net-1.4.1.jar代码可知，listFiles()方法调用的是jar中FTPClient.class类的对应方法。（也可以去官网下载源码）

3)        再往下追踪可知，FTPListParseEngine.class这个解析引擎类会针对不同系统创建不同的解析工厂。

以上正则表达式串，正是为了匹配unix类系统的文件目录结构，但存在bug

4)        根据网上建议对该解析类的正则表达式进行优化，但直接反编译jar包中源代码不可取，会存在风险；所以采用了类似对该解析类重写的方式处理，首先在EOS的以下目录增加两个java文件。

将UnixFTPEntryParser中正表达式进行优化

5)        再在调用listFiles()方法之前先让该方法的解析类指向新加的解析类，代码如下：

6)        为了对该功能的影响降到最底，故对代码又做了特殊处理，只有2月29的情况才调用新加的解析类，其它日期还是延用之前的代码。

7)        为此完成所有改动点总共涉及5个java文件，打包到测试1和测试3初步验证无问（延用了他原来的工厂类模式）。