원래 FTP는 이기종간 데이터 변환을 고려해서 설계되었습니다. 그래서 DOS -> UNIX -> IBM 머신간에 텍스트 문서의 인코딩 변환이 되도록 한 것입니다. ASCII 전송의 경우 유닉스로 갈 때에는 \n 만 개행으로 쓰고, DOS에서 ASCII로 받으면 \r\n이 개행문자가 됩니다(비슷하게 EBCDIC같은 것도 됩니다). 이진 파일을 그대로 보낼 때에는 BINARY 모드로 보내게 되죠.
그래서 일반 파일을 text모드로 전송하면 내용이 엉망이 된다고 생각했거든요. 1bit가 전송이 안되서...
물론 일반 바이너리 파일을 text 모드로 전송하면 당연히 내용이 깨질 수도 있고, 안 깨질 수도 있습니다.
무슨 얘기냐면요, 개행모드가 똑같은 시스템끼리는 괜찮겠지만, 다른 시스템끼리는 ascii 전송시 개행 문자가 덧붙여지거나 삭제되기 때문이죠. 즉 윈도에서 유닉스로 바이너리를 ascii로 전송하면 0x0d 0x0a (\r\n)가 나타나는 모든 코드가 0x0a(\n)로 치환되어 버리죠.
유닉스에서 윈도로는 그 반대죠. 아마 리눅스용 텍스트 파일을 노트패드로 열었을 때 모든 문자가 한 줄에 다 보이면서 이상한 코드 같은 게 문장 끝마다 붙었던 게 기억나실 겁니다. 즉 윈도는 0x0d 0x0a가 아니면 한줄이 끝나지 않은 걸로 알고 또 0x0a 하나로는 콘트롤 문자로 표시하기 때문이죠.
텍스트 문서는 그냥 콘트롤 코드가 하나씩 붙거나 줄 뿐 내용은 상관이 없지만 데이타 파일에는 치명적이죠.
(이상은 이론이었고 실제로는 같은 리눅스 끼리도 ascii로는 binary 전송이 깨지는군요. 에구에구) 즉 결론은 텍스트 파일 전송에는 ascii 전송이 아주 적격이지만(개행 문자를 저절로 치환해주니까) 그 외에는 binary 전송을 쓸 수 밖에 없다는 겁니다.
7비트/8비트는 문제는 오리지날 ASCII 코드 표준(IBM PC용 말고)이 7비트만 사용하기 때문입니다. 즉 텍스트 전송에 있어서는 7비트만이 유효한 셈이죠. 모든 옛날 프로그램이 7비트를 기준으로 텍스트 전송을 했기 때문에 (즉 7비트는 전송을 보장하나 8비트는 전송을 보장 못함) 8비트를 전송할려면 여러 트릭(8비트 코드 스트림을 7비트 코드 스트림으로 변환, uuencode/uudecode)이 필요하곤 했죠. 하지만 개행문자와는 관련이 없습니다. 개행문자는 7비트 내에서 표현이 되기 때문이죠.
여담으로, 윈도(도스) 계열은 개행문자가 0x0d 0x0a (\r\n)이고, 유닉스 계열은 그냥 0x0a (\n)인 것은 다 아실테고, Mac 계열은 0x0d (\r)라고 하더군요.
C가 유닉스에서 탄생되었기에 망정이지 만약 윈도에서 나왔다면 printf 문에서 매번 printf("hello, world\r\n"); 처럼 썼을 겁니다.
여담으로, 윈도(도스) 계열은 개행문자가 0x0d 0x0a (\r\n)이고, 유닉스 계열은 그냥 0x0a (\n)인 것은 다 아실테고, Mac 계열은 0x0d (\r)라고 하더군요.
C가 유닉스에서 탄생되었기에 망정이지 만약 윈도에서 나왔다면 printf 문에서 매번 printf("hello, world\r\n"); 처럼 썼을 겁니다.
정말 천만다행이로군요 :D
근데 왜 개행문자가 저리도 제각각인지... 생각없이 살 때는 그러려니 하다가도 가끔씩 매우 짜증이 나더군요. 저렇게 서로 다르게 채택한 유래가 뭘까요?
각각의 시스템에서 개행문자가 천차 만별인 것은 물론 각자 시스템의 특성 때문이겠지요. 자세한건 각각의 시스템을 개발한 사람들에게 물어봐야 될 겁니다. 물어봐도, 의외로 '그냥'이라는 말이 나올지도 모릅니다. -_-; (...의외로 그런 경우가 꽤 됩니다. C언어에 ++연산자가 들어간 이유라던가 등등...)
참고로, C 표준에서는 모든 문자가 반드시 한 바이트 안에 저장될 수 있도록 요구하고 있습니다. 물론 개행문자도 마찬가지입니다. 실제로 특정 시스템에서 개행문자가 1바이트건 2바이트건 아예 존재하지 않던간에, C언어 상에서는 개행문자 '\n'을 가지고 편리하게 접근할 수 있습니다.
원래 FTP는 이기종간 데이터 변환을 고려해서 설계되었습니다. 그래서 D
원래 FTP는 이기종간 데이터 변환을 고려해서 설계되었습니다. 그래서 DOS -> UNIX -> IBM 머신간에 텍스트 문서의 인코딩 변환이 되도록 한 것입니다. ASCII 전송의 경우 유닉스로 갈 때에는 \n 만 개행으로 쓰고, DOS에서 ASCII로 받으면 \r\n이 개행문자가 됩니다(비슷하게 EBCDIC같은 것도 됩니다). 이진 파일을 그대로 보낼 때에는 BINARY 모드로 보내게 되죠.
--
익스펙토 페트로눔
호오 그런것이였나요?저는 text 모드에서는 7bit 만을 사용하
호오 그런것이였나요?
저는 text 모드에서는 7bit 만을 사용하고 binary 모드에서는 8bit를 사용하는 것으로 생각했는데 잘못 알고 있었나 보네요. :)
(그래서 일반 파일을 text모드로 전송하면 내용이 엉망이 된다고 생각했거든요. 1bit가 전송이 안되서... )
ps. 그럼 저 7bit, 8bit 구분은 어디에서 쓰던 걸까요? 옛날 메일 전송 때문에 uuencode/uudecode 하던 기억과 관련이 있어 보이는데... :D
My Passion for the Vision!
아아.. 그런것 이었군요!!전 예전에 무조건 택스트 파일은 tex
아아.. 그런것 이었군요!!
전 예전에 무조건 택스트 파일은 text 모드로 안하면 깨지는줄 알았는데 말이죠 :shock:
저는 무조건 binary로 하면 괜찮다고 생각하고 있었는데ascii를
저는 무조건 binary로 하면 괜찮다고 생각하고 있었는데
ascii를 binary로 보내도 괜찮은 이유는 뭔가요?
컴전공이 아니라서
모두 행복하세요
[quote]그래서 일반 파일을 text모드로 전송하면 내용이 엉망이 된
물론 일반 바이너리 파일을 text 모드로 전송하면 당연히 내용이 깨질 수도 있고, 안 깨질 수도 있습니다.
무슨 얘기냐면요, 개행모드가 똑같은 시스템끼리는 괜찮겠지만, 다른 시스템끼리는 ascii 전송시 개행 문자가 덧붙여지거나 삭제되기 때문이죠. 즉 윈도에서 유닉스로 바이너리를 ascii로 전송하면 0x0d 0x0a (\r\n)가 나타나는 모든 코드가 0x0a(\n)로 치환되어 버리죠.
유닉스에서 윈도로는 그 반대죠. 아마 리눅스용 텍스트 파일을 노트패드로 열었을 때 모든 문자가 한 줄에 다 보이면서 이상한 코드 같은 게 문장 끝마다 붙었던 게 기억나실 겁니다. 즉 윈도는 0x0d 0x0a가 아니면 한줄이 끝나지 않은 걸로 알고 또 0x0a 하나로는 콘트롤 문자로 표시하기 때문이죠.
텍스트 문서는 그냥 콘트롤 코드가 하나씩 붙거나 줄 뿐 내용은 상관이 없지만 데이타 파일에는 치명적이죠.
(이상은 이론이었고 실제로는 같은 리눅스 끼리도 ascii로는 binary 전송이 깨지는군요. 에구에구) 즉 결론은 텍스트 파일 전송에는 ascii 전송이 아주 적격이지만(개행 문자를 저절로 치환해주니까) 그 외에는 binary 전송을 쓸 수 밖에 없다는 겁니다.
7비트/8비트는 문제는 오리지날 ASCII 코드 표준(IBM PC용 말고)이 7비트만 사용하기 때문입니다. 즉 텍스트 전송에 있어서는 7비트만이 유효한 셈이죠. 모든 옛날 프로그램이 7비트를 기준으로 텍스트 전송을 했기 때문에 (즉 7비트는 전송을 보장하나 8비트는 전송을 보장 못함) 8비트를 전송할려면 여러 트릭(8비트 코드 스트림을 7비트 코드 스트림으로 변환, uuencode/uudecode)이 필요하곤 했죠. 하지만 개행문자와는 관련이 없습니다. 개행문자는 7비트 내에서 표현이 되기 때문이죠.
여담으로, 윈도(도스) 계열은 개행문자가 0x0d 0x0a (\r\n)이고, 유닉스 계열은 그냥 0x0a (\n)인 것은 다 아실테고, Mac 계열은 0x0d (\r)라고 하더군요.
C가 유닉스에서 탄생되었기에 망정이지 만약 윈도에서 나왔다면 printf 문에서 매번 printf("hello, world\r\n"); 처럼 썼을 겁니다.
[quote]저는 무조건 binary로 하면 괜찮다고 생각하고 있었는데
위에 쓴 글처럼, binary 모드는 ftp 전송에서 아무런 변환도 하지 않는 것 뿐입니다. 그래서 같은 계열에서는 ascii가 그대로 전송이 되지요.
다른 계열이라 하더라도 다만 개행문자가 더 붙거나 덜 붙을 뿐이라서 쉽게 원본을 복구할 수 있지요.
반대로 binary 파일을 ascii 모드로 전송하게 되면 파일내에 있는 실행 코드(데이터)가 단지 개행 문자와 코드가 같다는 이유로 변경이 되어버리지요. 그러면 결과는 아실 겁니다.
[quote="lasher"]여담으로, 윈도(도스) 계열은 개행문자가
정말 천만다행이로군요 :D
근데 왜 개행문자가 저리도 제각각인지... 생각없이 살 때는 그러려니 하다가도 가끔씩 매우 짜증이 나더군요. 저렇게 서로 다르게 채택한 유래가 뭘까요?
좋은 하루 되세요!
[quote="raymundo"][quote="lasher"]여담으로
각각의 시스템에서 개행문자가 천차 만별인 것은 물론 각자 시스템의 특성 때문이겠지요. 자세한건 각각의 시스템을 개발한 사람들에게 물어봐야 될 겁니다. 물어봐도, 의외로 '그냥'이라는 말이 나올지도 모릅니다. -_-; (...의외로 그런 경우가 꽤 됩니다. C언어에 ++연산자가 들어간 이유라던가 등등...)
참고로, C 표준에서는 모든 문자가 반드시 한 바이트 안에 저장될 수 있도록 요구하고 있습니다. 물론 개행문자도 마찬가지입니다. 실제로 특정 시스템에서 개행문자가 1바이트건 2바이트건 아예 존재하지 않던간에, C언어 상에서는 개행문자 '\n'을 가지고 편리하게 접근할 수 있습니다.
댓글 달기