多くの場合、異なるリモートホストから、FileZillaは.css
または.php
ファイルをダウンロードし、既存の行の間に空白行を挿入します。これにより、Niceフォーマットが破壊されます。
PC = Windows 10 Pro64ビット。
これを防ぐにはどうすればよいですか?
解決策は、転送タイプを自動からバイナリに変更することでした。
転送メニュー>転送タイプ>バイナリ
OPが解決策をすでに見つけているときに、この回答を書いています。私の答えの目的は、同様の問題を抱える将来のユーザーを支援するために問題が何であったかを説明することです。 既存の回答は解決策を提供しますが、洞察はありません。これが答えです:
解決策は、転送タイプを自動からバイナリに変更することでした。
転送メニュー>転送タイプ>バイナリ
私が疑ったように(質問への私のコメントで)、問題は行末の翻訳との不一致でした。 FileZilla Wiki は主題をカバーしています。これらは関連するフラグメントです(以下のすべての引用はそこからのものであり、いくつかのフレーズは私によってさらに強調されています):
ファイルは、FTPクライアントとサーバー間でさまざまな方法で転送できます。 FTP仕様(RFC 959)はそれらを「データ型」と呼んでいます(...)
さまざまなデータ型は次のとおりです。
- ASCII
- バイナリ
- (...)
ASCIIタイプはテキストファイルの転送に使用されます。テキストファイルの問題は、プラットフォームが異なれば行末の種類も異なることです。たとえば、MicrosoftWindowsはCR + LFペア(キャリッジリターンとラインフィード)を使用しますが、LinuxやMacOS XなどのUnix(-like)システムは、LFおよび従来のMacOSシステム(MacOS)のみを使用します。 9以前)はCRのみを使用します。ASCIIタイプの目的は、行末がプラットフォーム上で正しいものに適切に変更されるようにすることです。FTP仕様によれば、ASCIIファイルは、常にCR + LFペアを行末として使用して転送されます。
したがって、ファイルがクライアントからサーバーに転送される場合、クライアントはCR + LFが使用されていることを確認する必要があります。 (...)
ファイルがサーバーからクライアントにダウンロードされるときにも同じことが起こります。サーバーはファイルを送信するときに行末がCR + LFであることを確認し、クライアントはプラットフォームで行末として不要なものをすべて取り除きます。
(...)
ASCIIタイプと比較すると、バイナリタイプの方が簡単です。ファイルはそのまま転送され、行末の変換は行われません。
問題が発生した場合の例の1つは、OPの場合と一致します。私はこれが起こったことだと思います:
Windows(CR + LF)テキストファイルがUnixベースのFTPサーバーにバイナリでアップロードされました。そのファイルがASCIIでダウンロードされた場合、FTPサーバーはLFをCR + LFに変換するため、CR + LF行末はCR + CR + LFに変換されます。Windows上のFileZillaはファイルを予期します。すでにCR + LFラインエンコーディングを使用しているため(FTP仕様による)、これ以上の変換は行われません。使用するテキストエディタによっては、行が追加の空行で区切られる場合があります。
OPの解決策は、転送タイプをAutoからBinaryにTransfermenu。この記事では、それを変更する他の方法も示しています。
FileZillaを使用して、転送データ型を3つの方法で変更できます。
- FileZillaの設定で
- メインメニューの転送->転送タイプ
- FileZillaのステータスバーにあるデータ型インジケーターを右クリックします。
binaryをWindowsのデフォルトオプションにすると、.css
または.php
またはWindows以外のシステムからダウンロードされた他のテキストファイルは、単一のLFまたはWindows固有のCR + LFの代わりにCRで保存されます。別のフラグメントで説明されているように、問題ではない可能性があります:
したがって、何を使用するかわからない場合は、常にバイナリタイプを選択してください。現在、ほぼすべての(優れた)テキストエディタで、3つの可能な行末を処理できます。 、およびPerlやPHPなどのスクリプト言語のような他のテキストファイル、およびXMLファイル(ほぼ)は、常にどの行末でも機能します。
転送タイプはいつでも変更できるため、多くの場合、このソリューションが最適です。
質問のタイトルは、OPのFileZillaによって追加の行が作成されたことを示しています。それは真実ではありません、OPのFileZilla構成に問題はありませんでした。この問題は、行末がサーバーOSと一致しないテキストファイルがあるサーバー側で発生します。 上記の解決策は、サーバー側の問題に対するクライアント側の修正です。
別の解決策は、サーバー側でファイル(行末)を修正することです。したがって、ASCII転送は機能します)そもそもそうあるべきです。これは明らかに正しいことであり、最良の解決策と呼ばれることもあります。ある意味では、問題の根本を処理するためです。サーバーを管理している場合、または管理者に連絡するか、フォーマットが不適切なファイルを上書きする権限がある場合に連絡できます。これは他のユーザーにもメリットがあります。
管理者に連絡しても、サーバー側で変更が行われるのを待つよりも、転送の種類を変更して必要なファイルをダウンロードする方が常に速いと思います。