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が混乱していますか？うまくいけば、システム管理者に連絡してサーバー構成のスイッチをオンにするように依頼できるソリューションがありますが、それはそれほど簡単ではないようです。