为什么我的文件名在Linux中看起来是“普通”的，而在Windows中却不是远程的？
与同事一起工作时，我发现了一个奇怪的问题，似乎与编码有关。我们正在与具有足够简单的文件名，如一些图像时city.gif或wine.gif，但正如人们所预料的事情开始使用特殊字符，例如当更多复杂的é，ë，à。我们还正在处理具有这些字符的荷兰数据，例如café（pub）。（我们无法控制文件的来源。）这是开始出现问题的地方。以下文件名仅是示例。带有变音符号的其他字符也会出现此问题。 café-2.png cafetaria.png café.png 第一项和最后一项应在其中带有重音符号e（重音aigu，é）。这样便可以在Linux（CentOS 6和7）的终端上运行它ls。但是Windows来了！（使用Windows 10，64位。）在Windows上通过SSL与我们的服务器通过SSL连接，然后调用时ls，上面的列表如下所示： café-2.png cafetaria.png caf▒.png 如您所愿，第一行仍带有重音符号e é，而第三行则没有。相反，我看到了▒这个字符-它是medium shadeunicode（十进制数为1818）。这本身很奇怪。但是，当我通过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混乱了？希望有一种解决方案，我们可以联系我们的系统管理员，要求他们打开服务器配置中的开关，但恐怕并非如此简单。