Java 看不到文件系统上包含非法字符的文件

Question

我正在试验我们在生产中看到的一个边缘案例。我们有一个业务模型，其中客户端生成文本文件，然后将它们通过 FTP 传输到我们的服务器。我们提取这些文件并在我们的 Java 后端(在 CentOS 机器上运行)上处理它们。我们的大多数 (95%+) 客户都知道以 UTF-8 格式生成这些文件，这正是我们想要的。然而，我们有一些顽固的客户(但大客户)在 Windows 机器上使用 CP1252 字符集生成这些文件。没问题，我们已经配置了我们的第 3 方库(这是为我们完成大部分“处理”工作的)通过一些神奇的 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)

所以我认为正在发生的事情是因为文件 name 本身包含非法字符，我们甚至一开始就无法读取它。如果可以，那么无论文件内容如何，​​我们的软件都应该能够正确处理它。因此，读取其中包含非法 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...

的文件

无论如何，解决方案似乎是添加一些逻辑来搜索文件名中是否存在该字符，如果找到，则将文件重命名为其他名称(比如可能做一个 String-wise replaceAll("\uFFFD", "_") 或类似的东西)系统可以读取和处理。

问题是 Java 在文件系统上什至看不到这个文件。 CentOS 知道文件在那里 (test?.txt)，但当该文件被传递到 Java 时，Java 将其解释为 test�.txt 并且出于某种原因 没有那个文件或目录...

如何让 Java 看到这个文件，以便我可以对其执行 File::renameTo(String)？抱歉这里的背景故事，但我觉得它是相关的，因为在这种情况下每个细节都很重要。提前致谢!

Answer 1

欢迎来到美妙的文本编码世界。您有多个级别的问题，您需要单独解决每个问题。

首先，磁盘上的文件名是什么？它包含有效的 UTF-8 转义序列还是其他内容？

这里的问题是您需要正确的文件名，否则 Windows 文件系统根本无法找到该文件。最重要的是，Windows 可能会尝试将文件名中的非法字符转换为 Unicode \uFFFD，因此无论您尝试什么，都无法加载文件(因为没有磁盘上包含 \uFFFD 的文件)。

怎么可能呢？发生这种情况是因为映射不是双向的。当 Windows 从磁盘加载文件名时，它会将 test�.txt 替换为 test\uFFFD.txt 并为您提供该名称。当您告诉 Windows 打开 test\uFFFD.txt 时，它将无法找到该文件，因为没有具有这样名称的文件(只有 test�.txt )。 您无法查明文件的真实名称。

解决方案？您可以打开 DOS 提示符并使用 ren test*.txt test.txt 模式重命名该文件。由于该模式只匹配一个文件，所以它会起作用。但是您将无法从 Windows 资源管理器等中执行相同的操作，因为它也找不到该文件。

下一步:FTP。 FTP 是人类协议(protocol) - 它不适合自动数据交换。摆脱 FTP。我不知道这会花费你多少钱，但它总是值得的。使用 SFTP、scp 或 FTAPI .

问题的一个来源可能是 FTP 以 ASCII 格式传输文件名。 FTP 协议(protocol)中不允许使用变音符号……或者更确切地说，FTP 不希望有任何变音符号。如果幸运的话，您的 FTP 客户端将拒绝传输该文件，但最简单的方法就是出错。但是当它们存在时，FTP 将只是做……某事。不管那是什么。这里通常的效果是名称中带有 Unicode 的文件被编码为 UTF-8 两次或 Unicode 被替换为 ? (\u003f)。

或者 Java FTP 客户端可以使用 new String( bytes ) 从 FTP 文件名创建一个字符串，这会使用系统的默认编码强奸不良字节 - 不漂亮。

解决方案:

1. 使用 FTP 服务器拒绝名称中包含非法字符的文件，或者将这些字符替换为不会混淆文件系统/操作系统的内容。
2. 使用能够正确处理具有奇怪名称的文件的文件系统。这通常意味着摆脱服务器上的 Windows。
3. 确保用户只能上传到一个目录，并且该目录只能包含一个文件。这样，您就可以使用一个小的 shell 脚本和模式将其重命名为您可以阅读的名称。