私はこの問題を抱えていますが、問題がクライアントまたはサーバー、あるいはその両方のどこにあるのかよくわかりません。これを診断して解決するための助けをいただければ幸いです。
私はdebianを実行しているリモートLinuxボックスを持っており、Windows8ボックスにファイルやフォルダーを定期的にダウンロードしています。ほとんどの場合、それはうまく機能します。マルチスレッドダウンロードを可能にするダウンロードマネージャーを使用して、プロセスを高速化します。
ただし、Linuxのファイル名にASCII以外の文字が含まれている場合もあります。私のダウンロードマネージャー(GetRight、かなり古いもの)はそれらをマングルでダウンロードします。私はそれがGetRightの問題だと思っていました。なぜなら、PuTTYでサーバーにSSHで接続し、WinSCPでファイル名が正しく表示され、WinSCPがそれらを完璧にダウンロードするからです(ただし、残念ながら、マルチスレッド方式ではありません)。
しかし、その後、Windowsでftp.exeを使用してサーバーに接続しようとすると、ファイル名も壊れてしまいました。
ここで、サーバー上のファイルをtar-gzipで圧縮し、この方法でダウンロードすることにしました。しかし、これもうまくいきませんでした。たとえば、Linuxでは次のようになります。
[jade ~/tmp] ls
тестовый
[jade ~/tmp] tar -czf ../data.tar.gz .
[jade ~/tmp]
次に、Windowsにdata.tar.gzをダウンロードして、解凍しようとします。
E:\!2>7z x data.tar.gz
7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
Processing archive: data.tar.gz
Extracting data.tar
Everything is Ok
Size: 10240
Compressed: 168
E:\!2>7z l data.tar
7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
Listing archive: data.tar
--
Path = data.tar
Type = tar
Physical Size = 10240
Headers Size = 9728
Date Time Attr Size Compressed Name
------------------- ----- ------------ ------------ ------------------------
2013-01-21 17:00:10 D.... 0 0 .
2013-01-21 17:00:10 ..... 2 512 .\╤В╨╡╤Б╤В╨╛╨▓╤Л╨╣
------------------- ----- ------------ ------------ ------------------------
2 512 1 files, 1 folders
方程式から転送エージェント(ftpクライアント/サーバーなど)を除外してもわかるように、問題は解決しません。
サーバーでtar-gzipを実行し、クライアントで解凍する最後のシナリオに集中して、それを機能させたいと思います。
誰かが私が見ているものを見ている理由を私に説明できますか?責任があるのはサーバーですか、それともクライアントですか、それとも両方ですか?解決する方法は?
自分で作成した場合、ウィンドウ上に必要なファイル名を正確に含むファイルを作成できることを述べておきます。
E:\!2>echo a > тестовый
E:\!2>dir т*
Volume in drive E is Storage
Volume Serial Number is F41B-FF77
Directory of E:\!2
21-Jan-13 17:20 4 тестовый
1 File(s) 4 bytes
0 Dir(s) 63,511,015,424 bytes free
E:\!2>
何が起こっているかの説明については、 この回答 を参照してください。
7Zipはファイル名に使用されたエンコーディングを「記憶」しているようで、ファイル名を適切に解凍するため、tarの代わりに7Zipを使用することをお勧めします。私はこれをスウェーデン語の非ASCII文字でテストしましたが、うまくいけばあなたにもうまくいくでしょう。