텍스트

CRLF ↔ LF Converter

Windows(CRLF), Unix/macOS(LF), 클래식 Mac(CR) 간에 줄바꿈 문자를 변환하며, 혼합된 줄바꿈도 감지합니다.

변환 대상

브라우저가 입력란에 붙여넣은 텍스트를 자동으로 LF로 정규화하기 때문에 원본 CRLF/CR을 여기서 감지할 수 없습니다 — 실제 CRLF/CR이 포함된 파일을 분석하거나 변환하려면 위의 파일 업로드를 사용하세요.


                    

Windows, Unix/macOS, and the old classic Mac historically use different characters to mark the end of a line — CRLF, LF, and CR respectively. Mixing these styles in one file often causes odd artifacts in diffs or editors. This tool converts line endings to one style and detects mixed ones.

How to use it

Common uses

Things to keep in mind

Git can automate this conversion itself through core.autocrlf or .gitattributes — often more convenient than converting files in a repository by hand.

Mixed line endings in one file aren't always visible at a glance, but they can break parsers or scripts that expect one specific style.

이 도구에 대한 아티클: CRLF와 LF: 줄바꿈 문자가 여전히 문제를 일으키는 이유

자주 묻는 질문

CRLF, LF, CR은 왜 서로 다른가요?

Windows는 전통적으로 캐리지 리턴과 줄바꿈을 함께 쓰는 CRLF(\r\n)를, Unix 계열과 macOS는 LF(\n)만을, 구형 클래식 Mac은 CR(\r)만을 줄바꿈 문자로 사용해 왔기 때문입니다.

입력란에 붙여넣어도 원본 줄바꿈이 그대로 유지되나요?

아니요. 브라우저는 텍스트 입력란에 붙여넣은 내용을 자동으로 LF로 정규화하기 때문에 원본이 CRLF였는지 CR이었는지는 붙여넣기만으로는 알 수 없습니다. 실제 줄바꿈을 정확히 감지하거나 변환하려면 파일 업로드 기능을 사용해야 합니다.

줄바꿈 차이는 언제 문제가 되나요?

git이 줄바꿈을 변경 사항으로 인식하거나, 셸 스크립트가 CRLF 때문에 실행에 실패하거나, 여러 운영체제를 오가며 작업하는 파일에서 흔히 문제가 됩니다. 이 도구의 처리는 모두 브라우저 안에서 이루어지며 파일은 서버로 전송되지 않습니다.

한 파일 안에 CRLF와 LF가 섞여 있으면 어떻게 해야 하나요?

여러 에디터나 서로 다른 OS에서 편집된 파일에는 두 스타일이 동시에 섞여 있을 수 있습니다. 변환은 눈에 띄게 "의심스러운" 줄만이 아니라 파일 전체에 적용해야 합니다 — 그렇지 않으면 일부 문제 있는 줄바꿈이 눈에 띄지 않게 남을 수 있습니다.

git을 통해 변환을 자동화할 수 있나요?

네, git의 core.autocrlf 설정은 checkout과 commit 시 줄바꿈을 자동으로 변환하며, .gitattributes를 사용하면 저장소 안의 특정 파일 유형에 대해 줄바꿈 스타일을 명시적으로 지정할 수 있습니다.

아티클: 텍스트

camelCase, snake_case, kebab-case: 언제 어떤 스타일을 쓸까

camelCase, snake_case, kebab-case가 왜 존재하며, 각각 보통 어디에 쓰이는지.

Text Diff: 텍스트 차이를 찾는 알고리즘의 작동 원리

diff 알고리즘이 텍스트 두 버전 사이의 최소 변경 집합을 찾는 방법.

정규 표현식: 기초와 탐욕적 매칭의 함정

정규 표현식에서 탐욕적 매칭과 게으른 매칭의 차이, 그리고 실무에서 왜 중요한지.

줄 정렬: 알파벳순과 숫자순은 왜 다를까

알파벳순 정렬이 숫자를 텍스트처럼 다루는 이유와, 숫자 정렬과의 차이.

문자열 이스케이핑: JS, JSON, 셸, 정규식마다 규칙이 다른 이유

모든 곳에 통하는 단 하나의 이스케이핑 규칙이 없는 이유 — JS, JSON, 셸, 정규식 각각 고유한 규칙이 있다.

문자 수와 단어 수 세기: 유니코드가 왜 이것을 복잡하게 만드는가

유니코드에서 시각적으로 하나의 이모지가 여러 코드 포인트로 이루어질 수 있는 이유.

Lorem Ipsum: 이 더미 텍스트는 어디서 왔고 왜 의미가 없을까

Lorem Ipsum 텍스트가 실제로 어디서 왔는지, 실제 텍스트 대신 무의미한 텍스트를 쓰는 이유.

Slugify: 제목이 유효한 URL로 바뀌는 과정

기사 제목이 하이픈으로 구분된 깔끔하고 읽기 쉬운 URL로 바뀌는 과정.

Markdown: 문서화의 표준이 된 이유

HTML과 달리 Markdown이 원본 상태에서도 읽기 쉬운 이유.

보이지 않는 공백: 겉보기에 같은 텍스트 비교가 왜 실패할까

보이지 않는 공백 하나가 겉보기에 같은 두 텍스트의 비교를 실패하게 만드는 방법.

텍스트 뒤집기: 이모지에서 왜 깨질까

단순한 텍스트 뒤집기가 여러 코드 포인트로 이루어진 이모지를 왜 깨뜨리는지.

텍스트 빈도 분석: 워드 클라우드부터 암호 해독까지

문자 빈도 분석이 역사적으로 단순 치환 암호를 해독하는 데 어떻게 도움이 되었는지.