본문으로 건너뛰기
AZ Tools

줄바꿈 & BOM 변환

LF·CRLF·CR 줄바꿈 간 변환, UTF-8 BOM 추가/제거 — 입력이 얼마나 혼합됐는지 보이도록 종류별 카운트 제공.

타깃 줄바꿈
UTF-8 BOM
출력
입력 통계
  • LF 개수1
  • CRLF 개수1
  • 단독 CR 개수0
  • 전체 줄 수3
  • 출력 바이트 (UTF-8)28
  • BOM 있었음아니오

혼합 줄바꿈 파일은 보통 여러 플랫폼에서 편집된 결과 — 정규화하면 "왜 내 diff가 폭발하지" 문제 대부분 해결.

사용법

  1. 실제 줄바꿈을 보려면 파일 열기(또는 입력란에 끌어다 놓기). 변환만 할 때는 붙여넣기도 가능.
  2. 타깃 줄바꿈 선택 (LF: Unix/macOS, CRLF: Windows, CR: 옛 Mac).
  3. BOM 정책 선택 후 출력 복사.

자세한 설명

펼치기

정규화 전에 CRLF·단독 CR·단독 LF를 따로 카운트해서, 혼합된 파일(지저분한 git diff·Windows에서 깨지는 Bash 스크립트의 흔한 원인)을 식별. 출력 바이트는 BOM 포함 기준으로 표시 — 디스크에 정확히 무엇이 쓰일지 알 수 있음. 모든 처리는 브라우저 로컬. 개수를 세려면 파일 자체가 필요합니다. 브라우저의 입력란은 텍스트를 붙여넣거나 입력하는 순간 모든 CRLF와 단독 CR을 LF로 바꾸기 때문에, 붙여넣은 텍스트도 올바르게 변환되지만 원래 줄바꿈은 이미 사라진 뒤이고, 디스크에 있는 그대로 세어지는 것은 열거나 끌어다 놓은 파일뿐입니다. 개수는 장식이 아니라 진단입니다. CRLF와 LF가 섞인 파일은 깃에서 파일 전체가 바뀐 것처럼 보이게 만드는 원인이고, 홀로 쓰인 CR은 예전 맥 OS의 것으로 오늘날에는 거의 언제나 파일이 시퀀스 중간에 잘렸거나 뭔가 혼동한 도구가 썼다는 뜻입니다. 여기서 고치는 것은, 저장소를 건드리는 모든 기기에서 core.autocrlf와 씨름하는 대신 택할 수 있는 방법입니다.

자주 묻는 질문

BOM은 언제 유지?

일부 오래된 Windows 도구와 일부 Excel CSV 임포트가 BOM에 의존. 그 외 모든 경우(특히 셸 스크립트·JSON·현대 빌드 체인의 소스 코드)는 제거.

혼합 줄바꿈 파일이란?

LF/CRLF/CR 중 둘 이상이 섞인 파일. 플랫폼을 넘나들며 편집됐거나, 다른 소스의 조각을 이어붙인 생성기에서 흔히 발생. 한 스타일로 정규화하면 git diff와 하위 파서 정상 동작.

git이 파일 전체를 변경된 것으로 표시하는 이유는?

모든 줄이 달라졌기 때문이다. 한 방식으로 커밋된 파일이 다른 방식으로 저장되면 변경되지 않은 줄이 하나도 남지 않아 diff가 기댈 곳이 없다. 한 번 정규화해서 그 상태를 커밋하고, 다음 체크아웃에서 변환이 다시 적용되지 않도록 저장소의 줄바꿈 정책을 정해 두면 된다.

마지막 줄 끝에도 줄바꿈이 필요한가?

대부분의 유닉스 도구 기준으로는 그렇다. 줄은 줄바꿈으로 끝난다고 보기 때문에, diff가 파일 끝에 줄바꿈 없음이라고 표시하고, 그런 파일 둘을 이어 붙이면 앞 파일의 마지막 줄과 뒤 파일의 첫 줄이 붙어버린다. 어떤 줄바꿈 방식을 쓰느냐와는 별개의 문제다.

관련 도구