☰

Filezilla가 텍스트 파일에 빈 줄을 삽입하지 못하도록 중지

tag-icon • tag-icon ftp filezilla textfiles
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 유형에 비해 바이너리 유형이 더 쉽습니다. 파일은 있는 그대로 전송되며 줄 끝 변환은 수행되지 않습니다.

무슨 일이에요?

문제가 발생한 경우의 예 중 하나가 OP의 사례와 일치합니다. 나는 이것이 일어난 일이라고 생각합니다 :

Windows(CR+LF) 텍스트 파일이 Unix 기반 FTP 서버에 바이너리로 업로드되었습니다. 해당 파일이 ASCII로 다운로드되면 FTP 서버는 LF를 CR+LF로 변환하므로 CR+LF 줄 끝이 CR+CR+LF로 변환됩니다. Windows의 FileZilla에서는 파일이 이미 CR+LF 라인 인코딩(FTP 사양에 따라)을 사용할 것으로 예상하므로 더 이상 변환이 수행되지 않습니다.사용된 텍스트 편집기에 따라 이제 추가 빈 줄로 줄이 구분될 수 있습니다.

해결책

OP의 솔루션은 전송 유형을 다음에서 변경하는 것입니다.자동에게바이너리에서 시작옮기다메뉴.이 기사에서는 이를 변경하는 다른 방법도 제공합니다.

FileZilla를 사용하면 세 가지 방법으로 전송 데이터 유형을 변경할 수 있습니다.

  • FileZilla 환경설정에서
  • 아래 메인 메뉴에서옮기다->환승 유형
  • FileZilla의 상태 표시줄에 있는 데이터 유형 표시기를 마우스 오른쪽 버튼으로 클릭합니다.

만들기바이너리.cssWindows의 기본 옵션을 사용하면 Windows가 아닌 시스템에서 다운로드한 또는 .php기타 텍스트 파일이 Windows 전용 CR+LF 대신 단일 LF 또는 CR로 저장되는 상황이 발생할 수 있습니다 . 다른 부분에서 설명한 것처럼 문제가 되지 않을 수도 있습니다.

따라서 무엇을 사용해야 할지 확신이 없으면 항상 바이너리 유형을 선택하세요.요즘 거의 모든 (좋은) 텍스트 편집기는 세 가지 가능한 줄 끝을 처리할 수 있으며 Perl이나 PHP와 같은 스크립팅 언어와 같은 기타 텍스트 파일은 물론 XML 파일도 (거의) 항상 모든 줄 끝에서 작동합니다.

이 솔루션은 항상 전송 유형을 변경할 수 있기 때문에 많은 경우에 가장 적합할 수 있습니다.

대체 솔루션

질문 제목은 OP의 FileZilla에 의해 추가 줄이 생성되었음을 나타냅니다. 사실이 아니다, OP의 FileZilla 구성에는 아무런 문제가 없습니다. 이 문제는 서버 OS와 일치하지 않는 줄 끝이 있는 텍스트 파일이 있는 서버 측에서 발생합니다.위에 언급된 해결책은 서버 측 문제에 대한 클라이언트 측 수정일 뿐입니다..

대체 솔루션은 서버 측에서 파일(줄 끝)을 수정하는 것입니다., 따라서 ASCII 전송은 처음부터 정상적으로 작동합니다. 이는 분명히 옳은 일이며 어떤 의미에서는 문제의 근본 원인을 다루기 때문에 최선의 해결책이라고 할 수 있습니다. 서버를 관리하는 경우, 관리자에게 문의할 수 있는 경우 또는 형식이 잘못된 파일을 덮어쓸 수 있는 권한이 있는 경우 이 해결 방법을 고려하십시오.이는 다른 사용자에게도 도움이 됩니다.

관리자에게 문의하더라도 항상 서버 측에서 변경이 이루어질 때까지 기다리는 것보다 전송 유형을 변경하고 원하는 파일을 다운로드하는 것이 더 빠른 것 같아요.

답변2

해결 방법은 전송 유형을 자동에서 바이너리로 변경하는 것이었습니다.

전송 메뉴 > 전송 유형 > 바이너리

관련 정보