'\ n'과 '\ r \ n'의 차이점

예, '\n'유닉스에서 개행 을 작성하는 반면 Windows의 경우 두 문자 시퀀스가 있음을 알고 '\r\n'있습니다. 이 모든 것이 이론 상으로는 매우 좋지만 내 질문은 왜 그런가 ? Windows에서 캐리지 리턴 문자가 추가 인 이유는 무엇입니까? 만약 유닉스가 그렇게 할 수 있다면 \n왜 Windows를 위해 두 문자가 필요합니까?

나는 David Beazley의 Python 책을 읽고 있는데 그는 말합니다.

예를 들어, Windows에서 문자 '\ n'을 쓰면 실제로 두 문자 시퀀스 '\ r \ n'이 출력됩니다 (파일을 다시 읽을 때 '\ r \ n'은 단일 '\ n'으로 다시 변환됩니다. 캐릭터).

추가 노력이 필요한 이유

나는 정직 할 것이다. 나는 그 차이를 오랫동안 알고 있었지만 WHY에게 물어 보지 않았다. 오늘 답변이 되었기를 바랍니다.

시간 내 줘서 고마워.

하위 호환성.

Windows는 MS-DOS와 역 호환되며 (공격적으로도 동일) MS-DOS는 CR-LF 규칙을 사용한 CP / M-80 (실수로 우연히)과 호환되므로 MS-DOS는 CR-LF 규칙을 사용했습니다. 프린터는 원래 컴퓨터로 제어되는 타자기 였기 때문에 프린터를 운전하는 방식이었습니다.

프린터에는 용지를 한 줄 위로 새 줄로 옮기라는 별도의 명령과 캐리지 (용지가 장착 된 곳)를 다시 왼쪽 여백으로 되 돌리는 별도의 명령이 있습니다.

그 이유입니다. 그리고, 그것은 성가신 일이지만, MS-DOS가 CP / M을 이기고 Windows 95가 DOS의 다른 모든 GUI를 이기고 Windows XP가 이기게 한 것은 패키지 거래의 일부입니다. Windows 98에서.

(참고 : 최신 레이저 프린터는 이전 프린터와 역 호환되기 때문에 여전히 이러한 명령이 있습니다. HP는 특히이 작업을 잘 수행합니다.)

타자기에 익숙하지 않은 사용자를 위해 입력 방법을 보여주는 비디오가 있습니다 ( http://www.youtube.com/watch?v=LJvGiU_UyEQ) . 용지가 먼저 위로 올라간 다음 캐리지가 간단한 동작으로 되더라도 반환됩니다. 딩은 타이피스트에게 끝이 가까웠다는 사실을 알리고 준비를했다.

내가 아는 한 이것은 타자기 시절로 거슬러 올라갑니다.

\r 캐리지 리턴 (carriage return)은 페이지에서 입력하는 위치를 다시 왼쪽으로 이동합니다 (또는 문화권 인 경우 오른쪽).

\n 줄 바꿈으로 종이를 한 줄 위로 이동시킵니다.

타자기에서이 중 하나만 수행하면 새로운 텍스트 줄을 작성하기 시작하는 잘못된 위치에있게됩니다.

컴퓨터가 나왔을 때 어떤 사람들은 이전 모델을 유지 한 것 같지만 다른 사람들은 그것이 필요하지 않다는 것을 깨달았고 한 줄로 전체 줄 바꿈을 캡슐화했습니다.

이것이 일반적인 지식인지는 모르지만 CR은 여전히 ​​현대 터미널 에뮬레이터에 의해 이해됩니다.

$ printf "hey world\rsup\n"
sup world

진행률 표시기에 편리합니다. 예 :

for i in {1..100}
do
    printf "\rLoading... %d%%" $i
    sleep 0.01
done
echo

역사적으로 줄 바꿈은 입력 한 롤러 인 인자 판이 한 줄을 회전하여 텍스트가 다음 줄에 나타나지만 다음 열에는 나타남을 의미했습니다.

캐리지 리턴은 "행의 시작 부분에 입력 한 비트를 반환"을 의미했습니다.

Windows는 MS-DOS가했기 때문에 CR + LF를 사용합니다. CP / M은 직렬 회선에 적합하기 때문에 그렇습니다.

Multics는 유닉스의 \ n 규칙을 복사했습니다.

나는 당신이 충분히 멀리 파헤 쳤다면, 당신은 구현 자들 사이에 정치적 의견 불일치를 발견 할 것입니다!

(Mac 규칙이 CR을 사용하여 줄을 구분하는 데 사용되는 여분의 재미있는 비트는 제외했습니다. 이제 유니 코드에는 자체 줄 구분 기호 U + 2028이 있습니다!)

줄 바꿈 문자의 역사 (Wikipedia) :

ASCII는 ISO의 이전 조직인 ISO와 ASA에 의해 동시에 개발되었습니다. 1963-1968 년 동안 ISO 초안 표준은 CR + LF 또는 LF 만 줄 바꿈으로 사용하는 것을 지원했으며 ASA 초안은 CR + LF 만 지원했습니다.

CR + LF 시퀀스는 텔레타이프 머신 (일반적으로 ASR33)을 콘솔 장치로 채택한 많은 초기 컴퓨터 시스템에서 공통적으로 사용되었습니다.이 시퀀스는 프린터를 새 라인의 시작 부분에 배치하는 데 필요했기 때문입니다. 이러한 시스템에서 응용 프로그램에서 이러한 하드웨어 세부 정보를 숨기는 장치 드라이버의 개념이 아직 제대로 개발되지 않았기 때문에 텍스트는 종종 이러한 프린터와 호환되도록 일상적으로 구성되었습니다. 애플리케이션은 텔레타이프 머신과 직접 대화하고 그 규칙을 따라야했습니다.

두 기능의 분리는 프린트 헤드가 한 문자 시간에 맨 오른쪽에서 다음 줄의 시작 부분으로 돌아갈 수 없다는 사실을 숨겼습니다. 이것이 시퀀스가 ​​항상 CR과 함께 먼저 전송되는 이유입니다. 실제로 프린트 헤드가 왼쪽 여백으로 이동할 수 있도록 여분의 문자 (무시한 CR 또는 NUL은 무시)를 보내야하는 경우가 종종있었습니다.

텔레타이프가 보오율이 높은 컴퓨터 터미널로 교체 된 후에도 많은 운영 체제는 이러한 문자를 자동으로 전송하는 기능을 지원하므로 디스플레이를 스크롤하기 위해 여러 문자 시간이 필요한 저렴한 터미널과 호환됩니다.

MS-DOS (1981)는 CP / M의 CR + LF를 채택했다; CP / M의 CR + LF 사용은 직렬 회선을 통한 컴퓨터 터미널 사용에 적합합니다. 이 규칙은 Microsoft의 이후 Windows 운영 체제에서 상속되었습니다.

Multics 운영 체제는 1964 년에 개발을 시작했으며 LF 만 줄 바꿈으로 사용했습니다. Unix는 Multics 연습을 따르고 나중에 시스템은 Unix를 따릅니다.

사람들이 "유닉스가 왜 \nWindows를 할 수 있고 할 수 없는가?" 정말 이상한 질문입니다.

1. OS는 거의 관련이 없습니다. 앱, 라이브러리, 프로토콜 및 파일 형식이 처리하는 방식이 더 중요합니다. OS가 텍스트 기반 구성 또는 명령 줄 명령을 읽거나 쓰는 것 외에는 OS에 결함이있는 것은 의미가 없습니다.
2. 대부분의 Windows 응용 프로그램은 수 모두 읽기 \n와 \r\n잘합니다. 그들은 또한 \r\n모두가 행복하도록 출력 합니다. 프로그램은 간단하게 "할"중 하나를하지 않는 \n나 \r\n- 그것은 허용 하나, 다른, 또는 둘, 그리고 출력 하나, 다른, 또는 둘 모두를.
3. 프로그래머로서 이것은 거의 당신을 귀찮게 하지 않아야 합니다. 실제로 모든 언어 / 플랫폼에는 올바른 엔드 라인을 작성하고 가장 확실하게 읽을 수있는 기능이 있습니다. 내가이 문제를 처리해야 할 유일한 시간은 HTTP 서버를 작성할 때 뿐이었습니다. 특정 브라우저 (힌트 : IE 다음으로 가장 인기있는 브라우저)가 올바른\n 대신 수행하고 있었기 때문 입니다. \r\n
4. 훨씬 더 적절한 질문은, 왜 그렇게 많은 최신 Unix 앱이 \n마음에 들지 않는 프로토콜과 프로그램이 있다는 것을 완전히 알고있는 것입니까?

협약이 다양한 시스템에서 유지되는 이유는 (\ n 유닉스 시스템에서는 \ n, Windows에서는 \ r \ n 등) 협약을 선택한 후에는 많은 사람들의 파일을 손상시키지 않고 변경할 수 없기 때문입니다. 그리고 그것은 일반적으로 눈살을 찌푸리고 있습니다.

유닉스 타입 시스템은 다양한 텔레타이프 모델을 사용하여 (매일 초기에) 개발되었으며, 어느 시점에서 누군가 장비가 라인 피드를 수행 할 때 캐리지 리턴을 결정해야했습니다.

Windows는 DOS에서 나왔으므로 Windows의 경우 실제로 질문입니다. DOS는 왜이 cr / lf 시퀀스를 사용 했습니까? CP / M과 관련이 있다고 생각합니다. DOS에는 그 뿌리가 있습니다. 다시, 특정 유형의 텔레타이프가 역할을 수행했을 수 있습니다.

최고의 출처-Microsoft의 답변입니다. 줄 종결자가 CR + LF 인 이유는 무엇입니까?

이 프로토콜은 텔레 타이프라이터 시절로 거슬러 올라갑니다. CR은 "캐리지 리턴"을 나타냅니다. CR 제어 문자는 용지를 진행하지 않고 프린트 헤드 ( "캐리지")를 열 0으로 반환했습니다. LF는 "줄 바꿈"을 나타냅니다. LF 제어 문자는 프린트 헤드를 움직이지 않고 용지를 한 줄 전진 시켰습니다. 따라서 프린트 헤드를 열 0으로 되돌리고 (다음 줄을 인쇄 할 준비가 되었음) 용지를 진전 시키려면 (신규 용지에 인쇄) CR과 LF가 모두 필요합니다.

RFC 0821 (SMTP), RFC 1939 (POP), RFC 2060 (IMAP) 또는 RFC 2616 (HTTP)과 같은 다양한 인터넷 프로토콜 문서로 이동하면 모두 CR + LF를 다음과 같이 지정합니다. 라인 종료 시퀀스. 실제 질문은 "왜 CP / M, MS-DOS 및 Win32가 CR + LF를 회선 종결 자로 사용합니까?"가 아닙니다. 그러나 오히려 "다른 사람들이 왜이 표준 문서와 다른 것을 선택하고 다른 줄 종결자를 사용하기로 했습니까?"

유닉스는 라인 종료 시퀀스로 일반 LF를 채택했습니다. stty 옵션을 보면 onlcr 옵션이 LF를 CR + LF로 변경해야하는지 여부를 지정하는 것을 볼 수 있습니다. 이 설정이 잘못되면 계단 모양 텍스트가 나타납니다.

each
    line
        begins

이전 줄이 사라진 곳. 따라서 유닉스 모드도 raw 모드로 남겨두면 CR + LF를 사용하여 행을 종료해야합니다. LF 이전의 암시 적 CR은 줄당 1 바이트를 절약하기 때문에 아마도 경제적 인 유닉스 발명품입니다.

C 언어의 유닉스는이 규칙을 C 언어 표준으로 가져 왔으며,이 줄은 "\ n"(LF를 인코딩 함)만으로 줄을 종료하기 때문에 런타임 라이브러리에서 원시 파일 데이터를 논리 줄로 변환하는 부담을 가중시킵니다.

C 언어는 또한 "일반 줄 종결 자"라는 개념을 표현하기 위해 "줄 바꾸기"라는 용어를 도입했습니다. ASCII위원회가 1996 년경에 문자 0x0A의 이름을 "newline"으로 바꾸 었다고 들었 기 때문에 혼란 수준이 훨씬 높아졌습니다.