我正在试验我们在生产中看到的边缘案例。我们有一个业务模型,客户端生成文本文件,然后将它们通过 FTP 传输到我们的服务器。我们摄取这些文件并在我们的 Java 后端(在 CentOS 机器上运行)处理它们。我们的大多数 (95%+) 客户都知道以 UTF-8 格式生成这些文件,这正是我们想要的。然而,我们有一些顽固的客户端(但大帐户)在 Windows 机器上使用 CP1252 字符集生成这些文件。不过没问题,我们已经配置了我们的 3rd 方库(这是我们的大部分“处理”工作)以通过一些神奇的 voo doo 处理任何字符集的输入。
有时,我们会看到一个文件名中包含非法 UTF-8 字符 (CP1252)。当我们的软件尝试从 FTP 服务器读取这些文件时,正常的文件读取方法会阻塞并抛出FileNotFoundException
:
File f = getFileFromFTPServer();
FileReader fReader = new FileReader(f);
String line = fReader.readLine();
// ...etc.
例外情况如下所示:
java.io.FileNotFoundException: /path/to/file/some-text-blah?blah.xml (No such file or directory) at java.io.FileInputStream.open(Native Method) at
java.io.FileInputStream.(FileInputStream.java:120) at java.io.FileReader.(FileReader.java:55) at com.myorg.backend.app.InputFileProcessor.run(InputFileProcessor.java:60) at
java.lang.Thread.run(Thread.java:662)
所以我认为正在发生的事情是,因为文件名本身包含非法字符,我们甚至一开始就无法读取它。如果可以,那么无论文件的内容如何,我们的软件都应该能够正确处理它。因此,读取文件名中包含非法 UTF-8 字符的文件名确实是一个问题。
作为一个测试用例,我创建了一个非常简单的 Java“应用程序”来部署在我们的一个服务器上并测试一些东西(源代码在下面提供)。然后我登录到一台 Windows 机器并创建了一个测试文件并将其命名为test£.txt
. 注意文件名中“test”后面的字符。这是 Alt-0163。我将它通过 FTP 传送到我们的服务器,当我ls -ltr
在其父目录上运行时,我惊讶地看到它列为test?.txt
.
在我继续之前,这是我为测试/重现此问题而编写的 Java“应用程序”:
public Driver {
public static void main(String[] args) {
Driver d = new Driver();
d.run(args[0]); // I know this is bad, but its fine for our purposes here
}
private void run(String fileName) {
InputStreamReader isr = null;
BufferedReader buffReader = null;
FileInputStream fis = null;
String firstLineOfFile = "default";
System.out.println("Processing " + fileName);
try {
System.out.println("Attempting UTF-8...");
fis = new FileInputStream(fileName);
isr = new InputStreamReader(fis, Charset.forName("UTF-8"));
buffReader = new BufferedReader(isr);
firstLineOfFile = buffReader.readLine();
System.out.println("UTF-8 worked and first line of file is : " + firstLineOfFile);
}
catch(IOException io1) {
// UTF-8 failed; try CP1252.
try {
System.out.println("UTF-8 failed. Attempting Windows-1252...(" + io1.getMessage() + ")");
fis = new FileInputStream(fileName);
// I've also tried variations "WINDOWS-1252", "Windows-1252", "CP1252", "Cp1252", "cp1252"
isr = new InputStreamReader(fis, Charset.forName("windows-1252"));
buffReader = new BufferedReader(isr);
firstLineOfFile = buffReader.readLine();
System.out.println("Windows-1252 worked and first line of file is : " + firstLineOfFile);
}
catch(IOException io2) {
// Both UTF-8 and CP1252 failed...
System.out.println("Both UTF-8 and Windows-1252 failed. Could not read file. (" + io2.getMessage() + ")");
}
}
}
}
当我从终端 ( java -cp . com/Driver t*
) 运行它时,我得到以下输出:
Processing test�.txt
Attempting UTF-8...
UTF-8 failed. Attempting Windows-1252...(test�.txt (No such file or directory))
Both UTF-8 and Windows-1252 failed. Could not read file.(test�.txt (No such file or directory))
test�.txt
?!?!我做了一些研究,发现“�”是 Unicode 替换字符\uFFFD
。所以我猜发生的事情是 CentOS FTP 服务器不知道如何处理 Alt-0163 ( £
),所以它用\uFFFD
( �
) 替换它。但我不明白为什么ls -ltr
显示一个名为test?.txt
...的文件
无论如何,解决方案似乎是添加一些逻辑来搜索文件名中是否存在此字符,如果找到,则将文件重命名为其他名称(例如可能执行字符串replaceAll("\uFFFD", "_")
或类似的操作)系统可以读取和处理。
问题是Java 甚至在文件系统上都看不到这个文件。test?.txt
CentOS知道文件在test�.txt
那里No such file or directory
(
我怎样才能让 Java 看到这个文件,以便我可以File::renameTo(String)
对它执行?很抱歉这里的背景故事,但我觉得它是相关的,因为在这种情况下每个细节都很重要。提前致谢!