CR LF, LF 및 CR 줄 바꿈 유형의 차이점은 무엇입니까?

CR LF, LF 및 CR 줄 바꿈 유형의 차이점은 무엇입니까?

---

CR LF (Windows), LF (Unix) 및 CR (Macintosh) 줄 바꿈 유형의 차이점 (가능한 경우 예제 포함)을 알고 싶습니다.

---

실제로 파일에 저장되는 바이트입니다. CR타자기 시대의 캐리지 리턴과 LF마찬가지로 줄 바꿈을위한 바이트 코드입니다 . 줄 끝 마커로 배치되는 바이트를 나타냅니다.

항상 그렇듯이 wikipedia 에서 더 많은 정보를 얻을 수 있습니다.

---

CR 및 LF는 각각 코딩 된 0x0D(십진수 13) 및 0x0A(10 진수) 제어 문자 입니다.

텍스트 파일에서 줄 바꿈을 표시하는 데 사용됩니다. 말씀하신대로 Windows는 CR LF 시퀀스의 두 문자를 사용합니다. Unix는 LF 만 사용하고 이전 MacOS (OSX 이전 MacIntosh)는 CR을 사용했습니다.

묵시적인 역사적 관점 :

Peter , CR = Carriage Return 및 LF = Line Feed 에서 알 수 있듯이 두 식은 이전 타자기 / TTY에 뿌리를두고 있습니다. LF는 용지를 위로 옮기고 (수평 위치는 동일하게 유지) CR은 "캐리지"를 다시 가져 와서 입력 한 다음 문자가 용지의 가장 왼쪽 위치 (동일한 줄)에 있도록했습니다. CR + LF는 두 가지를 모두 수행했습니다. 즉, 새 줄을 입력 할 준비를합니다. 시간이 지남에 따라 코드의 물리적 의미를 적용 할 수 없었고 메모리와 플로피 디스크 공간이 부족했기 때문에 일부 OS 설계자는 문자 중 하나만 사용하기로 결정했고 서로 잘 통신하지 못했습니다. -)

대부분의 최신 텍스트 편집기와 텍스트 지향 응용 프로그램은 파일의 줄 끝 규칙을 자동으로 감지하고 그에 따라 표시 할 수있는 옵션 / 설정 등을 제공합니다.

---

이것은 내가 찾은 좋은 요약입니다.

캐리지 리턴 (CR) 문자 ( 0x0D, \r)는 커서를 다음 행으로 이동하지 않고 행의 시작 부분으로 이동합니다. 이 문자는 Commodore 및 Early Macintosh 운영 체제 (OS-9 및 이전 버전)에서 줄 바꾸기 문자로 사용됩니다.

줄 바꿈 (LF) 문자 ( 0x0A, \n)는 줄의 시작으로 돌아 가지 않고 커서를 다음 줄로 이동합니다. 이 문자는 UNIX 기반 시스템 (Linux, Mac OSX 등)에서 줄 바꾸기 문자로 사용됩니다.

EOL (End of Line) 시퀀스 ( 0x0D 0x0A, \r\n)는 실제로 두 개의 ASCII 문자, 즉 CR 및 LF 문자의 조합입니다. 커서를 다음 줄과 해당 줄의 시작으로 모두 이동합니다. 이 문자는 Microsoft Windows, Symbian OS 등을 포함한 대부분의 다른 비 Unix 운영 체제에서 줄 바꾸기 문자로 사용됩니다.

출처

---

이에 대한 답이 없기 때문에 간결하게 요약하면 다음과 같습니다.

캐리지 리턴 (MAC pre-OSX)

• CR
• \아르 자형
• ASCII 코드 13

줄 바꿈 (Linux, MAC OSX)

• LF
• \엔
• ASCII 코드 10

캐리지 리턴 및 줄 바꿈 (Windows)

• CRLF
• \ r \ n
• ASCII 코드 13 및 ASCII 코드 10

이상한 형식의 ASCII 코드가 보이면 다른 기수 / 기수로 된 숫자 13과 10 일뿐입니다. 일반적으로 기수 8 (8 진) 또는 16 진 (16 진)입니다.

http://www.bluesock.org/~willg/dev/ascii.html

---

Jeff Atwood는 이에 대한 최근 블로그 게시물 : The Great Newline Schism

다음은 Wikipedia 의 본질입니다 .

CR + LF 시퀀스는 텔레타이프 머신 (일반적으로 ASR33)을 콘솔 장치로 채택한 많은 초기 컴퓨터 시스템에서 일반적으로 사용되었습니다.이 시퀀스는 새 라인의 시작 부분에 해당 프린터를 배치하는 데 필요했기 때문입니다. 이러한 시스템에서는 이러한 하드웨어 세부 정보를 응용 프로그램에서 숨기는 장치 드라이버의 개념이 아직 잘 개발되지 않았기 때문에 이러한 프린터와 호환되도록 텍스트가 일상적으로 구성되는 경우가 많습니다. 응용 프로그램은 텔레타이프 기계와 직접 대화하고 관례를 따라야했습니다.두 기능의 분리는 프린트 헤드가 한 문자 시간에 맨 오른쪽에서 다음 줄의 시작 부분으로 돌아갈 수 없다는 사실을 숨겼습니다. 이것이 시퀀스가 ​​항상 CR과 함께 먼저 전송 된 이유입니다. 사실, 프린트 헤드가 왼쪽 여백으로 이동할 시간을주기 위해 추가 문자 (무시되는 과도한 CR 또는 NUL)를 보내는 것이 종종 필요했습니다. 텔레타이프가 전송 속도가 더 높은 컴퓨터 터미널로 대체 된 후에도 많은 운영 체제는 디스플레이를 스크롤하는 데 여러 문자 시간이 필요한 저렴한 터미널과의 호환성을 위해 이러한 채우기 문자의 자동 전송을 지원했습니다.

---

CR-ASCII 코드 13

LF-ASCII 코드 10.

Theoretically CR returns cursor to the first position (on the left). LF feeds one line moving cursor one line down. This is how in old days you controled printers and text-mode monitors. These characters are usually used to mark end of lines in text files. Different operating systems used different conventions. As you pointed out Windows uses CR/LF combination while pre-OSX Macs use just CR and so on.

---

Systems based on ASCII or a compatible character set use either LF (Line feed, 0x0A, 10 in decimal) or CR (Carriage return, 0x0D, 13 in decimal) individually, or CR followed by LF (CR+LF, 0x0D 0x0A); These characters are based on printer commands: The line feed indicated that one line of paper should feed out of the printer, and a carriage return indicated that the printer carriage should return to the beginning of the current line.

Here is the details.

---

The sad state of "record separators" or "line terminators" is a legacy of the dark ages of computing.

Now, we take it for granted that anything we want to represent is in some way structured data and conforms to various abstractions that define lines, files, protocols, messages, markup, whatever.

But once upon a time this wasn't exactly true. Applications built-in control characters and device-specific processing. The brain-dead systems that required both CR and LF simply had no abstraction for record separators or line terminators. The CR was necessary in order to get the teletype or video display to return to column one and the LF (today, NL, same code) was necessary to get it to advance to the next line. I guess the idea of doing something other than dumping the raw data to the device was too complex.

Unix and Mac actually specified an abstraction for the line end, imagine that. Sadly, they specified different ones. (Unix, ahem, came first.) And naturally, they used a control code that was already "close" to S.O.P.

Since almost all of our operating software today is a descendent of Unix, Mac, or MS operating SW, we are stuck with the line ending confusion.

---

NL derived from EBCDIC NL = x'15' which would logically compare to CRLF x'odoa ascii... this becomes evident when physcally moving data from mainframes to midrange. Coloquially (as only arcane folks use ebcdic) NL has been equated with either CR or LF or CRLF

참고URL : https://stackoverflow.com/questions/1552749/difference-between-cr-lf-lf-and-cr-line-break-types