GN⁺: CRLF는 더 이상 사용되지 않으며 폐지되어야 합니다
(fossil-scm.org)캐리지 리턴과 라인 피드의 정의
- 캐리지 리턴 (CR): 커서를 같은 행의 왼쪽 여백으로 이동시킴
- 라인 피드 (LF): 커서를 한 행 아래로 이동시키고, 이전 행들을 위로 스크롤함
- 뉴라인 (NL): 커서를 한 행 아래로 이동시키고 왼쪽 여백으로 이동시킴
관찰
- CR과 NL은 유용한 제어 문자임. NL은 가장 일반적인 작업으로, 텍스트의 새로운 행을 왼쪽 여백에서 시작함
- LF는 실질적으로 쓸모없음. 아무도 행의 중간에서 다음 행으로 내려가서 같은 열에서 계속 쓰고 싶어하지 않음
- LF는 약 70년 전 기계식 전신 타자기 시대에 기원함
역사적 배경
- 전신 타자기는 5초당 약 5개의 문자를 인쇄함
- CRLF의 전통은 1950년대 전신 타자기의 기계적 한계에서 비롯됨
- Multix와 Unix 시대에 CRLF를 NL로 사용하는 것이 비효율적이라는 인식이 확산됨
현대의 상황
- 오늘날 CR은 U+000d로, LF와 NL은 U+000a로 표현됨
- 대부분의 현대 기계는 U+000a를 NL로만 사용함
- 일부 프로토콜은 여전히 CRLF를 요구하지만, 대부분의 소프트웨어는 단일 NL을 수용함
행동 촉구
- U+000a 코드 포인트의 이름을 "라인 피드" 대신 "뉴라인"으로 변경
- 불필요한 CR 전송 중단
- CRLF를 요구하는 프로토콜에 대해 NL만 전송
- CR 없이 NL을 받으면 오류를 발생시키는 소프트웨어 수정
요약 및 저자
- CRLF의 종말은 오래전부터 필요했음. 이 구시대적 유물을 없애기 위해 함께 노력해야 함
- 저자: D. Richard Hipp, SQLite의 창시자
# GN⁺의 정리
- 이 글은 CRLF의 역사적 배경과 현대적 비효율성을 설명하며, 이를 폐지할 것을 촉구함
- CRLF는 기계적 한계에서 비롯된 전통으로, 현대에는 불필요한 복잡성을 초래함
- 이 주제는 프로그래머와 소프트웨어 개발자에게 특히 유용할 수 있으며, 효율적인 데이터 전송을 위해 중요함
- 비슷한 기능을 가진 다른 프로토콜이나 시스템을 사용할 때도 CRLF의 필요성을 재고할 필요가 있음
CRLF가 잘못 정의된 사양도 아니고, 당대의 하드웨어 환경을 반영한 것인데...
하위 호환성은 잊어버리고, 오직 이 순간만 생각하는 것 같아요.
하드웨어 사양이 바뀔 때마다 프로토콜을 갈아엎어야 할까요?
10월 14일 수정에 따르면 변경 제안을 철회한다고 합니다.
단순히 한 시스템만 바꾸는 게 아니고 프로토콜과 영향있는 모든 시스템을 점진적으로 바꿔야 하는 일인데 제가 보기엔 필자가 신중하지 못했던 것 같네요
CR+LF has a long history...
오.. 이런 이유가..
Hacker News 의견
- 기존 프로토콜을 NL로 업데이트하는 것은 잠재적 버그를 초래할 수 있으며, HTTP/1.1은 이미 HTTP/2로 대체되었음
- 새로운 프로토콜에서는 CRLF를 요구하지 않는 것이 합리적이지만, 기존 프로토콜을 업데이트할 필요는 없다고 주장함
- CRLF를 준수하지 않는 것은 의도적으로 버그를 도입하는 것과 같음
- SQLite의 HTTP 서버가 \r\n 대신 \n을 사용하도록 업데이트되었으나, 이는 Zig의 HTTP 클라이언트와의 호환성을 깨뜨림
- CRLF를 후손들이 걱정할 필요가 없도록 하자는 의견
- .gitattribute 파일 사용법을 가르치고, 바이트 순서 표시(Byte Order Mark)를 싫어하도록 교육해야 한다고 주장함
- Unix의 비표준 줄 끝맺음 선택은 실수였으며, 이는 수십 년간의 호환성 문제를 초래했음
- CRLF는 터미널 API의 두 가지 다른 부분이며, 많은 프로그램이 CR과 LF의 올바른 작동에 의존함
- CRLF는 표준에서 가장 덜 중요한 요소 중 하나임
- 표준을 깨는 것은 새로운 시도이며, 개인적으로는 낯선 태도임
- SMTP는 메시지 종료 시퀀스가 CR LF . CR LF임을 명확히 하고 있으며, LF . LF를 인식하는 구현도 존재함
- 원래 SMTP 규칙이 더 이상 중요하지 않을 수도 있음
- CRLF는 많은 장치에 위험을 초래할 수 있으며, 예외를 줄여야 함
- 줄 끝맺음을 혼합했을 때 발생한 문제에 대한 언급이 없음
- NL이라는 문자는 존재하지 않으며, 모든 키보드의 "ENTER" 키는 CR을 전송함
- 현재 방식이 잘 작동하고 있음