우아한테크코스 미션을 수행하던 도중 동료 크루에게 \n
은 OS에 따라 다르게 보일 수 있다는 피드백을 받았다.
// 문제의 코드
private void validateName(final String name) {
if (name.length() > MAX_NAME_LENGTH) {
throw new IllegalArgumentException("참여자의 이름은 최대 " + MAX_NAME_LENGTH + "글자를 넘을 수 없습니다.\n" + "Name : " + name);
}
\n이 왜 문제가될까?
CRLF에 대해 이야기하기 전에 잠시 타자기 이야기를 해보려고한다.
타자기를 사용하는 모습을 보면 종이를 밀어 끝으로 이동하는 모습을 볼 수 있다.
이 행위를 Carriage Return
이라고 한다.
종이를 왼쪽으로 밀었을 때 한 줄 위로 올라오면서 줄바꿈이 일어나는데 이 행위를 Line Feed
라고한다.
윈도우에서의 개행 표현방식인 CRLF는
\r
, \n
두 방식을 합하여 표현했다고 이해할 수 있다.
정리하자면 윈도우에서는 타자기의 행위를 기준으로 개행을 표현했기 때문에 하나의 개행을 표현할 때 \r\n
으로 표현한다고 할 수 있다.
리눅스, Mac과 같은 Unix 기반 운영체제는 Line Feed \n
만 사용하여 개행을 표현한다.
따라서 윈도우에서 LF만으로 작성된 개행을 읽을 때 개행이 꺠지는 현상이 생길 수 있으므로 주의가 필요하다.
솔직히 다음 한 문장으로 정리하고 끝낼 수도 있다.
윈도우에서는 개행을 표현할 때 \n 뿐만 아니라 \r도 같이 붙여서 운영체제별 호환에 문제가 생길 수 있다! 조심하자!
최신 에디터들은 CRLF 문제를 대부분 호환해주기 때문에 일반적으로 사용할 때 크게 어려움을 느낄 기회가 없을 것이다.
MacOS, Linux 사용자라면 더더욱 체감할 일이 없을지도 모른다.
하지만 다음과 같은 상황이 있을 수 있다.
서버의 스크립트를 Window 메모장에서 작성하고 Linux 환경인 서버에 복사-붙여넣기를 했다.
위와 같은 상황에서 Linux 환경의 서버에서 스크립트를 읽을 때 개행문자로 인해 문제가 발생할 수도 있다.
이러한 상황에서 CRLF를 한 번쯤 의심할 수 있는 키워드를 얻어가면 보다 빠른 오류 탐색을 기대할 수 있지 않을까?
CRLF를 소개하는 글이기 때문에 위 상황에서의 해결방법은 여러분의 몫으로 맡기겠습니다.
IntelliJ의 우측 하단을 보면 LF 혹은 CRLF라고 쓰여져 있는 모습을 볼 수 있다.
해당 설정에 따라 개행을 어떻게 표현할 지를 지정할 것인지를 선택할 수 있다.
정도로 이해할 수 있겠다. 만약 github에 올릴 때 해당 포멧이 다르면 포멧이 조금 달라질 것이 우려되니 개인적으로는 LF를 선호하는 편이다.
왼쪽으로 종이를 옮기는 행위가 컴퓨터에서 정말 필요했을까?
겨우 줄바꿈 하나를 하는 데 2byte나 사용하는게 너무 아깝다는 생각이 든다.
기능을 생각 할 때 현실세계의 행위를 너무 깊이 반영한 사례가 아닐까 싶다.
최근 우테코의 미션을 진행하면서 객체를 설계할 때 나 또한 현실세계를 너무 깊이 반영했었기 때문에 눈에 밟히는 부분이다.
프로그래밍을 할 때 현실세계와 어느정도의 경계를 둬야한다는 교훈을 리마인드하고 간다.
이거 먼 훗날 미션할 때 HTTP 바이트 수를 달라지게 해서 테스트 코드를 깨지게 하는 원흉이죠