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を介してサーバーに接続し、lsを呼び出すと、上記のリストは次のようになります。
_café-2.png
cafetaria.png
caf▒.png
_ご覧のとおり、最初の行にはe_é_のアクセント記号が付いていますが、3行目はアクセント記号が付いていません。代わりに、この文字は_▒_です。これは、Unicode（9618 10進数）では_medium shade_です。これ自体は奇妙です。しかし、Filezillaを使用してSFTP経由で接続すると（まだWindowsのままです）、次のようになります。
_café-2.png
cafetaria.png
café.png
_つまり、状況は一変しました。最初の例では、_é_がシーケンスに変更され、3番目の例ではすべて順調です。私は here を見つけました。これは、正しければ、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番目はわかります。
- 最初のファイル名はバイトシーケンス
636166c3a92d322e706e67—コードページ1252ではcafé-2.pngです。café-2.pngのUTF-8エンコーディングでもあります。 - 3番目のファイル名はバイトシーケンス
636166e92e706e67—コードページ1252ではcafé.pngです。ただし、有効なUTF-8エンコーディングではありません。e9は、不完全な文字エンコードシーケンスを開始します。
つまり、何がnotコードページ1252を使用しているが、UTF-8を使用している、つまりSSHセッションとローカルターミナルエミュレータがvalidを処理しているということです。 =相互に同じ方法でUTF-8を使用していますが、無効 UTF-8を2つの異なる方法で処理しています。
- ブロックグラフィックを表示しているものは、おそらくそのブロックグラフィックを一般的な置換出力文字として無効なUTF-8シーケンスとして使用しているだけです。
éの文字を表示しているコードは、無効なエンコーディングを検出すると、コードページ1252にフォールバックします。
根本的な問題は、UTF-8としてエンコードされたいくつかのファイル名とコードページ1252でエンコードされた他のファイル名を何らかの方法で生成しているシステムです。