Linuxでファイル名が「正常」に見えるのに、Windowsではリモートではないのはなぜですか？

同僚と作業しているときに、エンコードに関連していると思われる奇妙な問題を発見しました。私たちは、このような単純な十分なファイル名持っている一部の画像で作業しているcity.gifかをwine.gif、しかし、1つは期待通りなどの特殊文字を使用するときに物事が複雑になりé、ë、à。また、これらの文字を含むオランダ語のデータcafé（たとえばpub）も処理しています。（ファイルの出所を制御することはできません。）ここで問題が発生し始めます。以下のファイル名は一例です。この問題は、発音区別符号を持つ他の文字でも発生します。

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が éありますが、3番目の行にはありません。代わりに、▒この文字が表示さmedium shadeれます-これはUnicode（10進数9618）です。これ自体は奇妙です。ただし、Filezillaを使用してSFTP経由で接続すると（Windowsでも）、次のようになります。

café-2.png
cafetaria.png
café.png

これで状況éは一変しました。最初の1つはシーケンスに変更され、3番目の1つはすべて順調です。私が見つけたのは、これが正しければ、Latin-1 <-> UTF-8変換が間違っていたことが原因である可能性が高いです。しかし、それだけでは不十分です。

Linuxは期待どおりにすべてを表示し、Windowsはファイル名の表示方法（SSH（putty）、またはSFTP（filezilla））に応じて一貫性のない動作を示します。これらのファイル名を「正規化」する（つまり、編集する）方法はありますか。また、すべてのOSで同じであることを確認してください。または少なくとも一貫しており、そうであればどのように？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が混乱していますか？うまくいけば、システム管理者に連絡してサーバー構成のスイッチをオンにするように依頼できるソリューションがありますが、それはそれほど簡単ではないようです。

しかし、ここでWindowsが登場します。

Windowsはこれとは何の関係もありません。あなたは、のために適切に選択された端末のエンコードおよび適切に構成されたロケールで、（例えば）GNOME端末のローカルインスタンスと同じ正確な動作を再現することができls、任意のWindowsは、画像にされることなく、すべてで。

Windowsが行う唯一のことは、ここで何が行われているのかを明確に示すことです。Windows FTPプログラムは、ファイル名のバイトを取り、それらをコードページ1252の関連するコードポイントとして表示します。これは、0x1Fより上のほとんどすべてが印刷可能なグリフのシングルバイトエンコーディングで、ファイル名のバイトが正確に何であるかを教えてくれます。 。

2番目のファイル名はほとんど情報がありませんが、1番目と3番目はわかります。

• 最初のファイル名はバイトシーケンス63 61 66 c3 a9 2d 32 2e 70 6e 67ですcafé-2.png。コードページ1252ではです。これはのUTF-8エンコーディングでもありcafé-2.pngます。
• 3番目のファイル名はバイトシーケンス63 61 66 e9 2e 70 6e 67ですcafé.png。コードページ1252では、これはです。ただし、有効なUTF-8エンコーディングではありません。 e9不完全な文字エンコーディングシーケンスを開始します。

つまり、何がコードページ1252を使用していないが、UTF-8を使用している、つまり、SSHセッションとローカルターミナルエミュレータが有効な UTF-8を互いに同じ方法で処理していますが、無効な UTF-8 2つの異なる方法で：

• ブロックグラフィックを表示しているものは、おそらくそのブロックグラフィックを無効なUTF-8シーケンスの一般的な置換出力文字として単に使用しているだけです。
• 文字を表示してéいるものは、無効なエンコーディングに遭遇すると、コードページ1252にフォールバックします。

根本的な問題は、UTF-8としてエンコードされたいくつかのファイル名と、コードページ1252でエンコードされた他のファイル名を何らかの方法で生成しているシステムです。