Filezilla がテキストファイルに空白行を挿入するのを止める

Filezilla がテキストファイルに空白行を挿入するのを止める

多くの場合、FileZilla は異なるリモート ホストから.cssまたは.phpファイルをダウンロードし、既存の行の間に空白行を挿入します。これにより、適切な書式が破壊されます。

PC = Windows 10 Pro 64 ビット。

これを防ぐにはどうしたらいいでしょうか?

答え1

私の回答とOPの回答

OP がすでに解決策を見つけているときに、私はこの回答を書いています。私の回答の目的は、問題が何であったかを説明し、同様の問題を抱える将来のユーザーを支援することです。既存の回答は解決策は示していますが、洞察力はありません。これが答えです:

解決策は、転送タイプを自動からバイナリに変更することでした。

転送メニュー > 転送タイプ > バイナリ


問題の背景: ASCII とバイナリ

私が(質問へのコメントで)疑ったように、問題は行末の翻訳の不一致でした。FileZilla ウィキ主題を網羅している。これらは関連する断片である(以下の引用はすべてそこからのものであり、いくつかのフレーズは追加されている)。強調した私による):

ファイルは、FTP クライアントとサーバーの間でさまざまな方法で転送できます。FTP 仕様 (RFC 959) では、それらを「データ タイプ」と呼びます (...)

さまざまなデータ型は次のとおりです。

  • アスキー
  • バイナリ
  • (...)

ASCII タイプはテキスト ファイルの転送に使用されます。テキスト ファイルの問題は、プラットフォームによって行末の種類が異なることです。たとえば、Microsoft Windows では CR+LF ペア (復帰と改行) が使用されますが、Linux や MacOS X などの Unix 系システムでは 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の解決策は、転送タイプをオートバイナリから始まる移行メニュー。この記事では、それを変更する他の方法も紹介しています。

FileZilla では、転送データの種類を次の 3 つの方法で変更できます。

  • FileZillaの設定で
  • メインメニューの移行->転送タイプ
  • FileZilla のステータス バーにあるデータ タイプ インジケーターを右クリックします。

制作バイナリ.cssWindows のデフォルト オプションでは、Windows 以外のシステムからダウンロードされたまたはその他のテキスト ファイルが、Windows 固有の CR+LF ではなく、単一の LF または CR で保存される状況が発生する可能性があります.php。別のフラグメントで説明されているように、これは問題ではない可能性があります。

したがって、何を使用するかわからない場合は、常にバイナリ タイプを選択してください。現在、ほぼすべての(優れた)テキスト エディターは 3 つの行末を処理でき、Perl や PHP などのスクリプト言語のテキスト ファイルや XML ファイルも、(ほぼ)常に任意の行末で動作します。

転送タイプをいつでも変更できるため、このソリューションは多くの場合最適です。


代替ソリューション

質問のタイトルは、OPのFileZillaによって追加の行が作成されたことを示唆しています。これは真実ではありません。OP の FileZilla 設定に問題はありませんでした。この問題は、サーバー OS と一致しない行末を持つテキスト ファイルがあるサーバー側で発生します。上記の解決策は、サーバー側の問題に対するクライアント側の修正にすぎません。

代替の解決策は、サーバー側でファイル(の行末)を修正することです。、ASCII 転送が本来のとおりに機能するようになります。これは明らかに正しいやり方であり、ある意味では最善の解決策と言えるかもしれません。問題の根本に対処するからです。サーバーを管理している場合、管理者に連絡できる場合、または不正な形式のファイルを上書きする権限がある場合は、この解決策を検討してください。これは他のユーザーにも利益をもたらします。

管理者に問い合わせる場合でも、サーバー側で変更が行われるのを待つよりも、転送タイプを変更して必要なファイルをダウンロードする方が常に速いと思います。

答え2

解決策は、転送タイプを自動からバイナリに変更することでした。

転送メニュー > 転送タイプ > バイナリ

関連情報