FTP에서 ASCII 모드의 요점은 무엇입니까?

오늘날 소프트웨어 및 FTP 구현에서 널리 사용되는 FTP에 ASCII 모드가있는 이유는 무엇입니까? 왜 데이터에 관계없이 항상 바이너리를 사용하지 않는가?

확실하지 않은 경우 RFC를 읽으십시오 .

STRUcture 명령을 사용하지 않았지만 모든 FTP 구현에서 "텍스트"파일 (예 : TYPE ASCII 또는 EBCDIC 파일)에 대해 파일 및 레코드 구조를 모두 승인해야하는 경우 파일 구조가 기본값으로 가정됩니다. 파일의 구조는 파일의 전송 모드 (전송 모드 섹션 참조)와 파일의 해석 및 저장에 영향을줍니다.

파일의 "자연적인"구조는 파일을 저장하는 호스트에 따라 다릅니다. 소스 코드 파일은 일반적으로 고정 길이 레코드로 IBM 메인 프레임에 저장되지만 DEC TOPS-20에는 행으로 분할 된 문자 스트림 (예 :로)으로 저장됩니다. 이러한 개별 사이트간에 파일을 전송하는 것이 유용하려면 한 사이트에서 다른 사이트의 파일에 대한 가정을 인식 할 수있는 방법이 있어야합니다.

etc 등 ... 간단히 말해서, 다른 인코딩을 사용하여 호스트로 전송할 때 한 인코딩의 텍스트 표현이 올바르게 변환되도록하는 것입니다.

다른 운영 체제 (Windows, UNIX, VAX)는 간단한 텍스트 파일에 다른 줄 끝 방법을 사용하기 때문입니다.

Windows (DOS)는 CR / LF 쌍을 사용하고 UNIX는 그 중 하나만 사용합니다. ASCII 모드는 CRLF 쌍을 변환하고 BIN 모드는 변환하지 않습니다.

론

때로는 편리하기 때문이라고 생각합니다. FTP 가 한 시스템에서 다음 시스템으로 파일을 가져 오는 방식으로 돌아 가던 시절 에는 시간이 많이 절약되었습니다. 읽을 수있는 텍스트 파일을 얻기 위해 다른 쪽 시스템이 무엇인지 알 필요가 없었습니다.

그러나 네, 오늘날은 대부분 성가신 일입니다. 처음에 타락한 오마 틱 머신!

ASCII 모드는 문자 및 EOL 인코딩이 실제로 문제가되었던 당시에 자리 잡았지만 ftp 클라이언트가 오늘이 옵션을 제거하거나 숨기고 싶습니다. 요즘은 시스템간에 엉망이되는 EOL 규칙 일뿐이지만 대부분의 텍스트 편집기는 더 이상 신경 쓰지 않습니다. 따라서 바이너리 파일 (또는 일부 텍스트 기반 파일)의 손상을 피하려면 모든 것에 바이너리 모드를 사용하는 것이 좋습니다.

ASCII 모드는 업로드 / 다운로드 여부에 따라 소프트웨어가 클라이언트 / 서버에 적절한 값으로 EOL 문자를 자동으로 변경할 수 있도록 사용됩니다. 사용중인 시스템과 동일한 유형의 시스템에 업로드하는 경우 이러한 모드에는 차이가 없습니다.

그러나이 모드의 이유는 모든 시스템의 모든 소프트웨어가 정확한 유형의 EOL이 아닌 EOL을 올바르게 처리하지는 않기 때문입니다 (예를 들어, 많은 Windows 소프트웨어는 "\ r \ n"만 제대로 처리하고 무언가를 방해합니다) "\ n"에 끔찍한).