FTP服务器中文环境引起润日下载不了附件问题解析
一、问题背景：
20240229日某农商行因为FTP下载功能有问题，导致当天所有涉及FTP文件下载的交易都不能正常使用，对于银行来说影响还是比较大。现将当天出问题的原因及处理过程解析如下，希望能给碰到类似问题的同行以供参考。
当天早上一上班就接到电话有人说信贷系统很多交易用不了，查看日志都是报的找不到文件，无法解析。后经过多方人员的共同努力查找和排查，最终确认是ReceiveFileTransfer.java类中的transfer()方法调用Apache组件commons-net-1.4.1.jar的listFiles时返回空问题引起，结合网上结论推断原因是目标服务器的中文语言环境，导致文件的修改日期格式，不能被apache正确解析造成的。（2月29）问题原因是定位到了，当务之急是如何快速让生产环境恢复正常运行，而不影响日常业务开展。经过多方讨论共提供三种解决方案：1、将目标服务器中当天使用频繁的交易所生成的文件临时改到20240228目录下；2、根据网上处理经验替换commons-net-1.4.1.jar包中的两个文件（FTPTimestampParserImplExZH.class、UnixFTPEntryParser.class）3、第2点的变向处理，不改jar包，使用时动态选择解析类；以上三种方案，当时先用第1种解决燃眉之急，以保证重要交易能正常使用；第2种考虑还是会存在一定风险，因为该系统使用年数比较旧，jdk版本也比较底，直接修改jar中的内容，一时无法保证对其它功能没有影响；所以最后的永久处理方案还是选择了第3点。下面就针对这种解决方案做以下详述：
二、代码跟踪步骤及解决方法：
- 由以下代码可知，FTP下载前会检查listFiles()所得到的fileList.size()是否大于0，只有大家于0的时候才会调附件下载的方法。
- 通过反编译commons-net-1.4.1.jar代码可知，listFiles()方法调用的是jar中FTPClient.class类的对应方法。（也可以去官网下载源码）
- 再往下追踪可知，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
4.根据网上建议对该解析类的正则表达式进行优化，但直接反编译jar包中源代码不可取，会存在风险；所以采用了类似对该解析类重写的方式处理，首先在EOS的以下目录增加两个java文件。
将UnixFTPEntryParser中正表达式进行优化
5.再在调用listFiles()方法之前先让该方法的解析类指向新加的解析类，代码如下：
6.为了对该功能的影响降到最底，故对代码又做了特殊处理，只有2月29的情况才调用新加的解析类，其它日期还是延用之前的代码。
7.为此完成所有改动点总共涉及5个java文件，打包到测试1和测试3初步验证无问（延用了他原来的工厂类模式）。
三、问题总结
针对FTP服务器中文环境引起的润日下载不了附件问题，引入的commons-net的jar包版本需要是3.7或更高版本才能解决问题。
关于FTP服务器在中文环境下引起无法下载附件的问题，这通常与服务器设置、编码问题以及客户端代码的处理方式有关。在早先的版本中，比如 commons-net-1.4.1.jar，存在处理文件日期格式的问题，这在中文环境下尤其明显。例如，如果文件生成于闰年的2月29日，旧版本的FTPClient可能会遇到获取文件失败的情况。此外，某些情况下，需要在调用listFiles方法前将FTPClient设置为被动模式来确保正确列出文件。
为了解决这些兼容性和中文环境导致的问题，建议升级到更新版本的commons-net。从3.7版本开始，commons-net加入了更多的改进和支持，包括对中文等问题的修复。同时，这个版本也增加了对新的FTP命令的支持，提高了库的稳定性和可用性。
至于JDK 1.7版本的兼容性，虽然commons-net 3.7及以上版本主要是针对Java 8及更高版本优化的，但它们通常也向后兼容旧版本的Java，包括JDK 1.7。不过，为了确保最佳性能和避免潜在的兼容性问题，建议在可能的情况下升级到更新的Java版本。
