01
파일의 실제 바이트로 검사
최대 20개 파일을 선택하고 교체 내용을 확인한 뒤 적용합니다. BOM이 있으면 UTF-8 또는 UTF-16 바이트 순서를 결정합니다. 없으면 UTF-8이 기본이며, 필요할 때 UTF-16LE/BE나 Windows-1252를 직접 지정합니다.
텍스트와 바이트
줄바꿈 변환기보이지 않는 차이까지 확인
텍스트나 여러 파일의 줄바꿈을 통일하고, BOM과 실제 출력 바이트를 확인하세요.
줄바꿈 변환기
입력
UTF-8; BOM: 없음; 0바이트. CRLF 0, LF 0, CR 0; NUL 0; 마지막 줄바꿈: 없음.
결과
아직 결과가 없습니다.
텍스트와 파일은 이 브라우저에서 처리되며 입력 데이터는 업로드되지 않습니다.
최대 20개 파일: 각 2MiB, 입력 합계 16MiB, 출력 합계 32MiB.
텍스트를 입력하거나 파일을 선택하세요.
복사는 텍스트만 전달하며 인코딩이나 추가 BOM은 전달하지 않습니다. 다운로드는 표시된 출력 바이트를 보존합니다.
BOM은 실제 첫 바이트를 나타냅니다. 표시가 두 개였다면 하나를 제거해도 본문에 속한 표시가 맨 앞에 남을 수 있습니다.
화면에서 같은 줄로 보이더라도 끝에 남은 CR 때문에 스크립트가 실행되지 않을 수 있습니다. 줄바꿈 변환기는 CRLF 한 쌍, 단독 LF, 단독 CR을 따로 세어 혼합된 상태를 보여 줍니다.
원본 인코딩이나 BOM을 확인하려면 파일을 선택하세요. 붙여넣은 문자열로는 원래 바이트를 입증할 수 없습니다. 텍스트 입력은 UTF-8이며, 파일은 감지하거나 직접 선택한 인코딩을 기본으로 유지합니다.
줄바꿈 변환기에서 확인할 차이
내용은 유지하고 줄 끝만 통일
줄바꿈 변환기는 이미 있는 구분자만 선택한 형식으로 바꿉니다. 공백, 탭, 빈 줄, 마지막 줄바꿈의 유무는 유지합니다. 줄 끝 유지를 선택하면 BOM만 처리할 수도 있습니다.
파일 서명과 본문 문자를 구별
줄바꿈 변환기는 맨 앞의 서명 하나만 BOM으로 처리합니다. 두 번째 표시나 본문 속 U+FEFF는 남습니다. 전후의 16진수 바이트를 비교해 실제로 제거된 부분을 확인하세요.
변환 전에 원본 해석부터 선택
02
줄바꿈과 인코딩을 따로 결정
기본값은 LF, BOM 유지, 파일 인코딩 유지입니다. CRLF LF 변환은 기존 구분자만 바꿉니다. UTF-8 출력으로 인코딩을 변경하려면 확인란도 선택해야 합니다. 데이터나 변환 옵션을 수정하면 확인이 해제됩니다.
03
실제 출력 바이트를 확인
문자 미리보기는 10,000자, 바이트는 256바이트씩 더 볼 수 있습니다. 다운로드는 항상 전체 결과입니다. 자동 모드는 350ms 후 실행하며, 끄면 변환 버튼이나 Ctrl/Cmd+Enter를 사용합니다. 수정 직후에는 오래된 결과 내보내기가 잠깁니다.
눈에 보이지 않는 부분까지 검사
혼합된 줄바꿈을 개별 집계
줄바꿈 통일 전에 CRLF를 하나로 계산합니다. NUL 수와 마지막 줄바꿈의 유무도 표시합니다. U+0085, U+2028, U+2029는 줄 끝으로 바꾸지 않고 내용으로 보존합니다.
인코딩에 맞는 BOM 처리
BOM 제거만 하려면 줄 끝을 유지하세요. 추가할 때는 UTF-8과 UTF-16LE/BE 각각에 맞는 서명을 사용합니다. Windows-1252에는 BOM이 없으므로 UTF-8 전환 확인이 필요합니다.
잘못된 문자를 대체하지 않음
잘못된 UTF-8, 홀수 길이 UTF-16, 짝 없는 서로게이트는 오류입니다. Windows-1252는 WHATWG 매핑과 C1 값을 역변환 가능하게 처리합니다. 공백 정리, Unicode 정규화, 수식 실행은 하지 않습니다.
누락 없는 일괄 결과
각 파일의 BOM은 따로 감지하고 같은 변환 옵션을 적용합니다. ZIP에는 안전한 번호 이름을 붙여 중복을 피합니다. 하나라도 실패하면 전체 내보내기를 중지하며 일부 파일만 성공으로 표시하지 않습니다.
지원 범위와 바이트 보존 기준
- 용량을 초과하면 중단
- 입력 하나는 2MiB, 최대 20개 파일과 합계 16MiB, 출력 합계는 32MiB입니다. 메모리 한도이며 초과분을 잘라 저장하지 않습니다. 빈 파일과 BOM만 있는 파일도 유효합니다.
- 지원 인코딩을 명시
- UTF-8, UTF-16LE/BE를 지원하며 BOM이 없을 때 Windows-1252를 직접 선택할 수 있습니다. UTF-32는 감지 후 거부합니다. GBK, Shift_JIS, 임의 인코딩 추측, 바이너리 복구, Office나 압축 파일 읽기는 지원하지 않습니다.
- 따옴표 안의 실제 줄바꿈도 대상
- CSV나 코드 구조를 분석하지 않으므로 문자열 안의 실제 구분자도 변환됩니다. 마지막 줄바꿈을 새로 넣거나 없애지 않습니다. 빈 줄, 공백, 탭, NUL, 내부 U+FEFF는 유지합니다.
- 복사는 파일 바이트와 다름
- 붙여넣기 전에 앱이나 브라우저가 줄 끝을 바꿀 수 있습니다. 편집기는 받은 구분자를 유지하지만 이미 사라진 바이트는 복구하지 못합니다. 복사는 추가 서명 없는 텍스트를 전달합니다. 인코딩까지 정확히 받으려면 다운로드하세요.
- 교체를 검토하고 한 번 복원
- 예제, 비우기, 파일 교체는 영향 수량을 미리 보여 줍니다. 실행 취소는 두 입력, 옵션, 자동 모드, 확인 상태, 이전 결과를 복원합니다. 입력 방식 전환은 데이터를 지우지 않으며 원본 파일을 덮어쓰지 않습니다.
줄바꿈 변환기 자주 묻는 질문
CRLF, LF, CR은 어떻게 다른가요?
CRLF는 두 문자이고 LF와 CR은 각각 한 문자입니다. Windows 관련 작업에서는 CRLF, Unix 계열에서는 LF가 흔하며 CR은 오래된 형식에 남아 있습니다. 줄바꿈 변환기는 LF가 기본이지만 받는 프로그램의 요구를 우선하세요.
붙여넣기로 원본 줄 끝을 유지할 수 있나요?
편집기는 붙여넣기 이벤트로 받은 CRLF와 CR을 유지합니다. 다만 원본 앱이나 클립보드에서 이미 바뀌었다면 되돌릴 수 없습니다. 원본 파일을 선택하면 그 바이트를 직접 검사할 수 있습니다.
줄바꿈 차이는 언제 문제가 되나요?
Git 차이가 불필요하게 커지거나 셸 스크립트에 CR이 남아 실행에 실패할 때입니다. 입력 통계와 출력 바이트를 보고 받는 쪽의 형식 요구에 맞춰 통일하세요.
한 파일에 CRLF와 LF가 섞여 있으면 어떻게 하나요?
원하는 대상 형식으로 전체 구분자를 변환하세요. 일부 줄만 추정해 수정하지 않습니다. 단, 따옴표 안의 개행도 바뀌므로 데이터 형식의 요구를 확인해야 합니다.
Git에서 줄바꿈을 자동화할 수 있나요?
저장소의 text/eol 속성과 core.autocrlf 설정으로 인덱스와 작업 트리의 줄 끝을 관리할 수 있습니다. 다운로드한 파일도 체크아웃 과정에서 다시 바뀔 수 있습니다. 이 페이지는 Git 설정을 변경하지 않습니다.
예상과 다른 바이트가 있나요?