6

我正在试验我们在生产中看到的边缘案例。我们有一个业务模型，客户端生成文本文件，然后将它们通过 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?.txtCentOS知道文件在test�.txt那里No such file or directory（

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

4

2 回答 2

6

欢迎来到文本编码的美妙世界。您有几个级别的问题，您需要单独对每个问题进行分类。

首先，磁盘上的文件名是什么？它是否包含有效的 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 脚本和模式将其重命名为您可以阅读的内容。
于 2012-08-24T13:24:02.890 回答
4

这是 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)

于 2014-02-24T12:31:08.823 回答