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

       20160229日某农商行由于FTP下载功能有问题，致使当天全部涉及FTP文件下载的交易都不能正常使用，对于银行来讲影响仍是比较大。现将当天出问题的缘由及处理过程解析以下，忘能给碰到相似问题的同行以供参考。

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

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

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

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

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

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

       三、第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这个解析引擎类会针对不一样系统建立不一样的解析工厂。

 

"([bcdlfmpSs-])(((r|-)(w|-)([xsStTL-]))((r|-)(w|-)([xsStTL-]))((r|-)(w|-)([xsStTL-])))\\+?\\s+(\\d+)\\s+(\\S+)\\s+(?:(\\S+)\\s+)?(\\d+)\\s+((?:\\d+[-/]\\d+[-/]\\d+)|(?:\\S+\\s+\\S+))\\s+(\\d+(?::\\d+)?)\\s+(\\S*)(\\s*.*)"

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

-rw-r--r--    1 root     system            0 Feb 29 16:19 ECDS_4017692698500000382783.txt

 

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

 

将UnixFTPEntryParser中正表达式进行优化

 

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

 

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

 

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