CRLF, LF 및 혼합 텍스트 파일 줄바꿈 감지기

텍스트브라우저에서 실행(업로드 없음)

로컬 텍스트 파일의 원본 바이트를 검사해 CRLF, LF, CR, NEL, LS, PS 줄바꿈을 세고 형식 전환 위치와 마지막 줄 종결 여부를 확인합니다. 읽기 전용 보고서는 파일을 바꾸거나 정규화된 붙여넣기 텍스트로 추측하지 않고 인코딩과 바이너리 불확실성을 표시합니다.

다음에 할 작업

관련 작업 흐름을 이어가거나 이 작업 다음에 자주 사용하는 도구를 열어보세요.

작업 가이드

재인코딩 없이 CSV·텍스트 파일의 BOM 제거하기

보이지 않는 선두 서명 때문에 첫 CSV 헤더나 script token이 달라질 때 사용합니다. 원본 바이트에서 작업하고 UTF-32 LE를 UTF-16 LE 접두부와 구분하며, 대상 시스템이 확인되기 전에는 UTF-16·UTF-32의 바이트 순서 증거를 지우지 않습니다.

열기 관련 도구

UTF-8·UTF-16·UTF-32 파일의 BOM 제거

나머지 내용을 재인코딩하지 않고 파일 선두의 지원 BOM 하나만 정확한 바이트에서 제거합니다.

열기 관련 도구

바이트 증거로 텍스트 파일 인코딩 감지

로컬 파일 바이트에서 BOM, 엄격한 UTF-8, Unicode 구조, ASCII 호환성, 바이너리 단서를 검사합니다.

열기 관련 도구

빈 줄 제거 | 빈 행 모두 삭제 또는 연속 간격 줄이기

빈 행을 모두 지우거나 반복 간격을 한 줄로 줄이고 정확한 수치와 줄바꿈 결과를 확인합니다.

열기

이 도구 사용 방법

textarea에 붙여넣지 말고 원본 텍스트, 스크립트, 설정, CSV 또는 로그 파일을 선택하세요.

검사를 실행해 파일을 변경하지 않고 로컬에서 원본 바이트를 읽으세요.

먼저 인코딩 근거와 바이너리, 레거시, 손상된 Unicode, BOM 없는 추정 경고를 확인하세요.

CRLF, LF, CR, NEL, LS, PS 개수를 비교하고 실제 주요 형식을 확인하세요.

전환 표에서 형식이 바뀌는 첫 줄과 바이트 오프셋을 찾으세요.

마지막 종결 여부를 확인한 뒤 대상 작업 흐름이 요구할 때만 변환 방식과 저장소 정책을 선택하세요.

이 도구를 써야 할 때

교차 플랫폼 스크립트 오류 분석

Linux가 캐리지 리턴을 명령이나 인터프리터 경로의 일부로 해석하기 전에 셸 스크립트, Docker 진입점, CI 명령 파일의 CRLF를 찾습니다.

예상하지 못한 Git diff 설명

편집기나 포매터가 파일 전체를 다시 써서 검토하기 어려운 변경을 만들기 전에 소수의 혼합 줄을 식별합니다.

데이터 가져오기 전 파일 검증

가져오기 도구가 혼합 레코드 구분자를 서로 다르게 처리하기 전에 CSV, 로그, 내보낸 파일을 확인합니다.

생성기와 빌드 결과 감사

생성 파일이 필요한 마지막 줄바꿈으로 끝나는지, 모든 레코드가 같은 종결자를 쓰는지 확인합니다.

Unicode 텍스트 파일 검토

NUL 바이트를 별도 줄바꿈으로 오인하지 않고 UTF-16 또는 UTF-32 설정과 교환 파일을 검사합니다.

흔한 실수

붙여넣은 텍스트를 원본 바이트로 믿는 경우

브라우저 textarea가 제공하는 API 값은 줄바꿈을 LF로 정규화합니다. CRLF와 LF의 원본 근거가 필요하면 원본 파일을 선택하세요.

CRLF를 두 줄바꿈으로 세는 경우

CRLF는 두 코드 포인트로 구성된 하나의 줄바꿈 시퀀스입니다. CR과 LF를 따로 세면 Windows 줄바꿈이 두 배로 집계되고 거짓 혼합 결과가 생깁니다.

소수 형식을 무시하는 경우

가장 큰 개수는 주요 형식을 알려 주지만 다른 종결자가 하나만 있어도 스크립트나 Git diff에 문제가 생길 수 있습니다. 전환 표를 확인하세요.

바이너리 바이트 패턴을 텍스트 줄로 보는 경우

바이너리 데이터 안의 0D와 0A 바이트는 신뢰할 수 있는 텍스트 경계가 아닙니다. 인코딩 근거가 바이너리 의심으로 나오면 줄바꿈 집계를 확정 결과로 사용하지 마세요.

Git 정책을 확인하지 않고 변환하는 경우

한 번 변환하는 것만으로 저장소 정책이 정해지지 않습니다. 대규모 정규화 전에 .gitattributes, 편집기 설정, core.autocrlf를 확인하세요.

예시

셸 스크립트의 혼합 줄바꿈 찾기

파일이 Windows 형식의 shebang 줄로 시작해 LF로 바뀌었다가 CRLF로 돌아갑니다. 첫 형식 변화가 2번째 줄과 원본 바이트 오프셋으로 표시됩니다.

입력

#!/bin/sh
printf 'ready'
exit 0

출력

CRLF: 2, LF: 1, 일관성: 혼합, 첫 혼합 줄: 2, 마지막 종결자: CRLF

UTF-16LE 줄바꿈 검사

UTF-16LE BOM이 2바이트 코드 단위를 선택하므로 0D 00 0A 00을 서로 떨어진 원시 바이트가 아닌 하나의 CRLF로 셉니다.

입력

FF FE 61 00 0D 00 0A 00 62 00 0A 00

출력

인코딩 근거: UTF-16 LE, CRLF: 1, LF: 1, 일관성: 혼합

바이트를 보존하는 줄바꿈 검사의 작동 방식

CR은 U+000D, LF는 U+000A이며 CRLF는 U+000D U+000A 순서쌍입니다. 검사기는 단독 CR이나 LF를 판단하기 전에 CRLF를 하나로 소비합니다.

UTF-8과 ASCII 호환 파일은 바이트 경계에서 검사합니다. BOM으로 확정되거나 보수적으로 추정된 UTF-16과 UTF-32는 엔디언에 맞는 2바이트 또는 4바이트 코드 단위로 검사합니다.

NEL U+0085, LINE SEPARATOR U+2028, PARAGRAPH SEPARATOR U+2029도 별도로 유지해 ASCII 밖의 줄바꿈 기능이 숨겨지지 않게 합니다.

보존된 각 위치에는 1부터 시작하는 줄 번호, 원본의 0부터 시작하는 바이트 오프셋, 바이트 길이가 기록됩니다. 메모리를 안정적으로 유지하도록 상세 전환 수는 제한하지만 전체 집계는 정확히 유지합니다.

마지막으로 인식한 줄바꿈 시퀀스가 파일의 마지막 바이트에서 끝날 때만 마지막 종결자가 있다고 판단합니다. 뒤에 손상되거나 무관한 바이트가 있으면 거짓입니다.

25 MiB 제한으로 브라우저 메모리와 실행 시간을 제한합니다. 검사는 읽기 전용이며 바이너리처럼 보이는 바이트에서 정확한 레거시 문자셋이나 텍스트 의미를 지어내지 않습니다.

자주 묻는 질문

왜 텍스트 붙여넣기 대신 파일을 선택해야 하나요?

HTML textarea API 값은 줄바꿈을 LF로 정규화하므로 붙여넣은 텍스트는 원본 파일의 CRLF나 CR 바이트를 안정적으로 보존하지 못합니다. 이 도구는 선택한 파일을 직접 읽습니다.

이 감지기가 파일을 수정하거나 변환하나요?

아니요. 읽기 전용 검사기입니다. 목표 형식을 정하고 저장소 또는 후속 시스템의 요구사항을 확인한 뒤 관련 CRLF/LF 변환기를 사용하세요.

UTF-16과 UTF-32 파일은 어떻게 처리하나요?

BOM이 있으면 UTF-8, UTF-16, UTF-32와 바이트 순서를 확인합니다. BOM이 없으면 UTF-16/32는 보수적인 NUL 바이트 배열 근거로 추정하며, 모호한 레거시 인코딩은 미확정으로 남깁니다.

마지막 종결자 없음은 무슨 뜻인가요?

마지막 내용 줄이 CRLF, LF, CR, NEL, LS, PS로 닫히지 않았다는 뜻입니다. 일부 도구는 허용하지만 저장소와 POSIX 중심 작업 흐름은 마지막 줄바꿈을 요구하거나 권장할 수 있습니다.

바이너리 의심 파일에도 결과가 나오는 이유는 무엇인가요?

줄바꿈처럼 보이는 원시 바이트 개수는 표시할 수 있지만 그 바이트가 텍스트 레코드가 아닌 바이너리 구조일 수 있어 경고합니다. 조치하기 전에 파일 형식을 확인하세요.

NEL, LS, PS는 무엇인가요?

Unicode의 NEXT LINE U+0085, LINE SEPARATOR U+2028, PARAGRAPH SEPARATOR U+2029입니다. 이 도구는 이를 LF에 합치지 않고 따로 표시합니다.

파일이 비공개로 유지되나요?

네. 파일 읽기와 분석은 브라우저 안에서 수행됩니다. 집계 이벤트에는 바이트 수와 줄바꿈 개수가 포함될 수 있지만 파일명과 파일 내용은 포함되지 않습니다.

이 도구를 검증한 방법

관리 및 검수 SimpleWebUtils검토일 2026년 7월 18일

검증 방법: 이번 검증은 “Windows에서 편집한 배포 스크립트 복구”의 정확한 입력과 CRLF, LF 및 혼합 텍스트 파일 줄바꿈 감지기를 짝지어 수행했습니다. “실패한 파일을 보존하고 원본 바이트 검사” 단계를 거쳐 “실행 환경과 저장소 정책에서 목표 형식 선택” 이후 결과를 캡처해 예시와 비교했습니다. 명시적인 경계 질문은 “감지 전에 파일을 textarea에 붙여넣기”, “CRLF는 제거했지만 shebang 앞 BOM을 남김”였습니다.

기대 결과: 수정된 스크립트는 CRLF 3개를 LF로 바꾸고 최종 줄 종료 4개를 유지했으며, 명령문을 바꾸지 않고 shebang을 0번 바이트에서 다시 인식시켰습니다.

검증한 작업 가이드 열기

다음에 할 작업

재인코딩 없이 CSV·텍스트 파일의 BOM 제거하기

UTF-8·UTF-16·UTF-32 파일의 BOM 제거

바이트 증거로 텍스트 파일 인코딩 감지

빈 줄 제거 | 빈 행 모두 삭제 또는 연속 간격 줄이기

이 도구 사용 방법

이 도구를 써야 할 때

교차 플랫폼 스크립트 오류 분석

예상하지 못한 Git diff 설명

데이터 가져오기 전 파일 검증

생성기와 빌드 결과 감사

Unicode 텍스트 파일 검토

흔한 실수

붙여넣은 텍스트를 원본 바이트로 믿는 경우

CRLF를 두 줄바꿈으로 세는 경우

소수 형식을 무시하는 경우

바이너리 바이트 패턴을 텍스트 줄로 보는 경우

Git 정책을 확인하지 않고 변환하는 경우

예시

셸 스크립트의 혼합 줄바꿈 찾기

UTF-16LE 줄바꿈 검사

바이트를 보존하는 줄바꿈 검사의 작동 방식

자주 묻는 질문

왜 텍스트 붙여넣기 대신 파일을 선택해야 하나요?

이 감지기가 파일을 수정하거나 변환하나요?

UTF-16과 UTF-32 파일은 어떻게 처리하나요?

마지막 종결자 없음은 무슨 뜻인가요?

바이너리 의심 파일에도 결과가 나오는 이유는 무엇인가요?

NEL, LS, PS는 무엇인가요?

파일이 비공개로 유지되나요?

이 도구를 검증한 방법

관련 작업 가이드

재인코딩 없이 CSV·텍스트 파일의 BOM 제거하기

가져오기 전 텍스트 파일 인코딩 감지하기

원본 파일 바이트에서 깨진 텍스트 복구하기

텍스트 개정본을 비교하고 Unified Diff 검증하기

Git과 셸 스크립트에서 CRLF를 LF로 안전하게 변환하기

실제 숫자를 지우지 않고 복사한 텍스트의 줄 번호 제거

스택 트레이스에서 복사된 gutter 줄 번호 제거

복사한 줄에 고정 라벨과 구분자를 안전하게 추가하기

Unicode 계산 단위별 텍스트 길이 제한 검증

관련 도구

UTF-8·UTF-16·UTF-32 파일의 BOM 제거

바이트 증거로 텍스트 파일 인코딩 감지

빈 줄 제거 | 빈 행 모두 삭제 또는 연속 간격 줄이기

텍스트 정리 워크벤치 | 목록, 로그, 문단 정리

Unicode 정규화 | NFC·NFD·NFKC·NFKD 비교