多くの場合、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 のステータス バーにあるデータ タイプ インジケーターを右クリックします。
制作バイナリ.css
Windows のデフォルト オプションでは、Windows 以外のシステムからダウンロードされたまたはその他のテキスト ファイルが、Windows 固有の CR+LF ではなく、単一の LF または CR で保存される状況が発生する可能性があります.php
。別のフラグメントで説明されているように、これは問題ではない可能性があります。
したがって、何を使用するかわからない場合は、常にバイナリ タイプを選択してください。現在、ほぼすべての(優れた)テキスト エディターは 3 つの行末を処理でき、Perl や PHP などのスクリプト言語のテキスト ファイルや XML ファイルも、(ほぼ)常に任意の行末で動作します。
転送タイプをいつでも変更できるため、このソリューションは多くの場合最適です。
代替ソリューション
質問のタイトルは、OPのFileZillaによって追加の行が作成されたことを示唆しています。これは真実ではありません。OP の FileZilla 設定に問題はありませんでした。この問題は、サーバー OS と一致しない行末を持つテキスト ファイルがあるサーバー側で発生します。上記の解決策は、サーバー側の問題に対するクライアント側の修正にすぎません。。
代替の解決策は、サーバー側でファイル(の行末)を修正することです。、ASCII 転送が本来のとおりに機能するようになります。これは明らかに正しいやり方であり、ある意味では最善の解決策と言えるかもしれません。問題の根本に対処するからです。サーバーを管理している場合、管理者に連絡できる場合、または不正な形式のファイルを上書きする権限がある場合は、この解決策を検討してください。これは他のユーザーにも利益をもたらします。
管理者に問い合わせる場合でも、サーバー側で変更が行われるのを待つよりも、転送タイプを変更して必要なファイルをダウンロードする方が常に速いと思います。
答え2
解決策は、転送タイプを自動からバイナリに変更することでした。
転送メニュー > 転送タイプ > バイナリ