在与同事合作时，我发现了一个似乎与编码有关的奇怪问题。我们正在处理一些文件名足够简单的图像，例如city.gif或wine.gif，但正如人们所预料的那样é，当使用, ë,等特殊字符时，事情会变得更加复杂à。我们也在处理具有这些字符的荷兰数据，例如café( pub )。（我们无法控制文件的来源。）这就是问题开始出现的地方。以下文件名只是一个示例。其他带有变音符号的字符也会出现此问题。
café-2.png
cafetaria.png
café.png
第一个和最后一个项目应该有一个带重音的e（accent aigu, é）。这就是运行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是我们选择的编码。
尽管这可能只是一个美学问题，但事实并非如此。尝试通过 Windows …