在与同事合作时，我发现了一个似乎与编码有关的奇怪问题。我们正在处理一些具有足够简单的文件名（例如city.gif或 ）的图像wine.gif，但正如人们所期望的那样，当使用特殊字符（例如é, ë, ）时事情会变得更加复杂à。我们还正在处理具有这些字符的荷兰语数据，例如café（酒吧）。 （我们无法控制文件的来源。）这就是问题开始出现的地方。以下文件名只是一个示例。其他带有变音符号的字符也会出现此问题。
café-2.png
cafetaria.png
café.png
第一个和最后一个项目应该有重音e在那里（重音aigu，é）。这就是 Linux (CentOS 6 & 7) 运行时在终端中的显示方式ls。但 Windows 来了！ （使用 Windows 10，64 位。）当在 Windows 上通过 SSL 连接到我们的服务器然后调用 时ls，上面的列表如下所示：
café-2.png
cafetaria.png
caf▒.png
正如您所希望看到的，第一行仍然带有重音符号e é，但第三个没有。相反，我看到▒这个字符 - 它是medium shadeunicode（十进制 9618）。这本身就很奇怪。但是，当我通过 SFTP 与 Filezilla（仍在 Windows 上）连接时，我会看到以下内容：
café-2.png
cafetaria.png
café.png
所以现在事情发生了逆转：在第一个中，é已经改变了顺序，而在第三个中，一切都很好。我发现这里如果我正确的话，这很可能是由于 Latin-1 <-> UTF-8 转换出错造成的。但这不可能是发生的全部，对吧？
Linux 显示了我们所期望的一切，Windows 显示了看似不一致的行为，具体取决于我们查看文件名的方式（SSH (putty) 或 SFTP (filezilla)）。有没有办法“标准化”这些文件名 - 即编辑它们 - 并确保它们在每个操作系统上都相同；或者至少是一致的，如果是的话，如何实现？UTF-8是我们选择的编码。
尽管这可能只是一个审美问题，但事实并非如此。当尝试从我们的 Linux 服务器在 Windows 中通过 SFTP 下载内容时，我无法下载存在上述问题的文件。 Filezilla 将抛出诸如 之类的错误Can't download file café-2.png: café-2.png does not exist on the server。在我看来，Filezilla 读取目录和文件名，以某种编码对其进行解释，将 GET 请求及其解释发送到服务器，但该解释与 Linux 文件名不同，因此找不到该文件。
最终，如果有一个可用的解决方案，那就太好了，即使我也感兴趣为什么有时候是这样的。发生这种情况是否是因为图像文件可能是在不同的操作系统上创建的？发生这种情况是因为 Linux 服务器解释错误，还是 Windows 搞砸了？希望有一个解决方案，我们可以联系我们的系统管理员并要求他们打开服务器配置中的开关，但恐怕没有那么容易。
答案1
但 Windows 来了！
Windows 与此无关。您可以使用（例如）GNOME 终端的本地实例重现同样的行为，并使用适当选择的终端编码和适当配置的区域设置ls，而图片中没有任何 Windows根本不。
Windows 所做的唯一一件事就是清楚地显示这里发生的情况。您的 Windows FTP 程序正在获取文件名中的字节，并将它们显示为代码页 1252 中的相关代码点。这是一种单字节编码，几乎包含 0x1F 以上所有内容（可打印字形），它准确地告诉我们文件名中的字节是什么。
您的第二个文件名基本上没有提供任何信息，但第一个和第三个文件名很能说明问题。
- 第一个文件名是字节序列
636166c3a92d322e706e67- 在代码页 1252 中，这是café-2.png.它也是 的 UTF-8 编码café-2.png。 - 第三个文件名是字节序列
636166e92e706e67- 在代码页 1252 中，这是café.png.但是，它不是有效的 UTF-8 编码。e9开始一个不完整的字符编码序列。
所以现在发生的事情是不是使用代码页 1252 但使用 UTF-8，即您的 SSH 会话和本地终端模拟器，正在处理有效的UTF-8 的方式彼此相同，但正在处理无效的UTF-8 有两种不同的方式：
- 显示块图形的人很可能只是简单地使用该块图形作为一般图形替换输出字符对于无效的 UTF-8 序列。
- 当显示该字母的代码
é遇到无效编码时，它会回退到代码页 1252。
您的根本问题是系统以某种方式生成一些编码为 UTF-8 的文件名和其他以代码页 1252 编码的文件名。