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

Question

我正在试验我们在生产中看到的边缘案例。我们有一个业务模型，客户端生成文本文件，然后将它们通过 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)

所以我认为正在发生的事情是因为文件 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 的文件...

无论如何，解决方案似乎是添加一些逻辑来搜索文件名中是否存在此字符，如果找到，则将文件重命名为其他名称（例如可能执行字符串方式 @987654338 @ 或类似的东西）系统可以读取和处理。

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

我怎样才能让 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 是人类的协议 - 它不适合自动数据交换。摆脱 FTP。我不知道这将花费你多少，但它总是值得的。使用 SFTP、scp 或 FTAPI。

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

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

解决方案：

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

Answer 2

这是 old-skool java File api 中的一个错误，可能只是在 mac 上？无论如何，新的 java.nio api 工作得更好。我有几个文件包含无法使用 java.io... 类加载的 unicode 字符。将我的所有代码转换为使用java.nio.Path 之后，一切都开始工作了。我用java.nio.Files替换了apache FileUtils（有同样的问题）...

确保使用适当的字符集读取和写入文件的内容，例如：Files.readAllLines(myPath, StandardCharsets.UTF_8)