CRLF는 더 이상 사용되지 않으며 폐지되어야 합니다

 (fossil-scm.org)
9P by GN⁺ | ★ favorite | 댓글 8개

캐리지 리턴과 라인 피드의 정의

  • 캐리지 리턴 (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의 필요성을 재고할 필요가 있음
GeekNews Weekly에 포함된 글입니다. 에디터 코멘트 보기

함께 보면 좋은 글 β

cosine20   [-]

라인피드 가끔 쓰는뎅....

답변달기
doolayer   [-]

참 과격하네요 ㅎㄷㄷ

답변달기
savvykang   [-]

10월 14일 수정에 따르면 변경 제안을 철회한다고 합니다.

단순히 한 시스템만 바꾸는 게 아니고 프로토콜과 영향있는 모든 시스템을 점진적으로 바꿔야 하는 일인데 제가 보기엔 필자가 신중하지 못했던 것 같네요

답변달기
constexprif   [-]

없애는 비용보다 없애서 얻는 이익이 크다고 생각한걸까요?

답변달기
bakyeono   [-]

CRLF가 잘못 정의된 사양도 아니고, 당대의 하드웨어 환경을 반영한 것인데...
하위 호환성은 잊어버리고, 오직 이 순간만 생각하는 것 같아요.
하드웨어 사양이 바뀔 때마다 프로토콜을 갈아엎어야 할까요?

답변달기
halfenif   [-]

없애는것에 찬성도 반대도 안하지만.

밀레니엄버그가 생각난건 왜일까요?

답변달기
GN⁺   [-]
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을 전송함
    • 현재 방식이 잘 작동하고 있음
답변달기