텍스트 및 일상 도구 · 텍스트 도구 키트
CR, LF 및 CRLF: 줄 끝의 출처 및 붙여넣은 텍스트가 끊어지는 이유
· 배경
줄 끝 텍스트 정리 데이터 내보내기
캐리지 리턴 및 줄 바꿈의 텔레타이프 기원, 운영 체제가 다른 규칙을 선택한 이유, 이러한 선택이 이중 빈 줄 및 붙여넣은 텍스트에서 잘못된 문자로 표시되는 방식을 설명합니다.
모든 행 뒤에 빈 줄이 있는 내보내기 — 다른 시스템의 파일이 두 배 더 많은 줄을 붙여넣는 이유
3행 내보내기를 붙여넣고 모든 레코드 뒤에 빈 줄이 표시됩니다. 즉시 Windows CRLF를 비난하고 싶지만 표준을 준수하는 텍스트 영역은 일반적으로 정규화된 형식으로 줄바꿈을 표시합니다. 이중 행은 이전 변환에서 캐리지 리턴과 줄 바꿈을 두 개의 독립적인 구분 기호로 처리했거나 레코드 사이에 추가 줄 바꿈을 삽입했음을 의미하는 경우가 많습니다.
어느 단계에서 변경되었는지 알 때까지 원본을 보관하세요. 제어 문자를 표시할 수 있는 편집기에서 소스를 비교한 다음 붙여넣은 줄 수를 비교합니다. ToolAcre는 의도적으로 CRLF, LF 및 Lone CR을 각각 하나의 경계로 허용하므로 손대지 않은 3개 레코드 파일은 단지 Windows에서 왔기 때문에 6개가 아닌 3개의 라인을 생성해야 합니다.
추가 빈 행은 증상일 뿐 CRLF만으로 문제가 발생했다는 증거는 아닙니다.
이름은 인쇄 터미널의 물리적 동작을 설명합니다. 캐리지 리턴은 캐리지를 현재 줄의 시작 부분으로 이동시키는 반면, 줄 바꿈은 용지를 다음 줄로 이동시킵니다. 두 모션 중 하나를 독립적으로 요청할 수 있기 때문에 이는 별도의 제어였습니다. ASCII는 이를 십진수 13의 제어 문자 CR과 십진수 10의 LF로 유지했습니다.
최신 화면은 더 이상 종이를 옮기지 않지만 바이트 값은 파일, 프로토콜 및 프로그래밍 인터페이스에 남아 있습니다. 역사는 왜 CR과 LF가 상호 교환 가능한 문장 부호가 아닌지, 그리고 왜 CRLF가 두 문자 시퀀스인지 설명합니다. 이는 모든 최신 응용 프로그램이 이를 별도로 처리한다는 의미는 아닙니다. 파서는 일반적으로 쌍을 하나의 논리적 줄 끝으로 인식합니다.
세 가지 규칙 — Unix 및 최신 macOS의 LF, Windows의 CRLF, 클래식 Mac OS의 CR 및 각각이 합리적이라고 생각되는 이유
Unix 및 Unix 계열 시스템은 일반적으로 줄 끝으로 LF를 사용하며 최신 macOS는 이 규칙을 따릅니다. Windows 텍스트 파일은 일반적으로 CRLF를 사용합니다. Classic Mac OS에서는 CR만 사용했지만 Mac OS X에서는 Unix 기반과 LF를 채택했습니다. 정규화에 동의하지 않고 도구가 일반 텍스트를 교환할 때 이러한 선택 사항은 계속 표시됩니다.
어떤 관례도 단어 자체를 다르게 만들지 않습니다. 문제는 독자가 하나의 표현만을 기대하거나 모든 제어 문자에서 순진하게 분할되는 경계에서 나타납니다. 강력한 라인 파서는 단독 CR 또는 LF를 확인하기 전에 CRLF를 쌍으로 확인합니다. ToolAcre은 정렬된 패턴 ` | | `을 사용하여 정확히 이를 수행한 다음 변환된 출력을 LF와 결합합니다.
브라우저 텍스트 상자에서 발생하는 일 — 붙여넣기 시 일반적으로 줄바꿈이 정규화되는 방식과 잘못된 문자가 계속 나타나는 위치
HTML은 텍스트 컨트롤의 줄 바꿈에 대한 특수 처리를 정의합니다. 텍스트 영역 값에서 브라우저는 노출된 값에서 CRLF 및 단독 CR을 LF로 정규화하는 반면 양식 제출은 줄 바꿈에 대한 양식 데이터 규칙을 적용할 수 있습니다. 결과적으로 상자에서 올바르게 보이는 페이스트도 다른 레이어에 의해 다르게 직렬화되거나 다른 규칙을 사용하여 소프트웨어에 복사될 수 있습니다.
텍스트가 일반 텍스트 영역을 우회하는 경우, 리터럴 문자 `\r`과 같은 이스케이프된 바이트가 표시되는 경우 또는 파서가 LF에서만 분할하고 CR을 각 필드에 첨부된 상태로 남겨 두는 경우 Stray CR이 계속 나타날 수 있습니다. 브라우저는 파일, 클립보드 생성자, API 및 명령줄 소비자에 대한 범용 복구 서비스가 아닌 경로의 한 단계입니다.
브라우저는 텍스트 영역 줄 바꿈을 정규화하지만 클립보드와 다운스트림 형식은 여전히 다릅니다.
빈 행과 후행 캐리지 리턴에는 다른 진단이 필요합니다. 빈 줄 제거는 ToolAcre가 세 가지 줄 끝 스타일을 모두 인식한 후 내용이 비어 있거나 공백인 행을 삭제합니다. Trim Lines는 모든 행에서 선행 및 후행 공백을 제거합니다. ToolAcre의 스플리터는 실제 CR 구분 기호를 사용하기 때문에 일반적으로 해당 구분 기호를 지우는 데 트리밍이 필요하지 않습니다.
공백, 탭 또는 리터럴 사용되지 않은 문자가 남아 있는 경우에만 트리밍을 사용하고 변경하기 전에 의미 있는 들여쓰기를 검사하십시오. 텍스트에 눈에 보이는 `^M`이 포함된 경우 뷰어가 실제 CR을 렌더링하는지 아니면 인쇄 가능한 두 문자를 렌더링하는지 확인하세요. 블랭킷 교체는 의도한 콘텐츠를 손상시킬 수 있는 반면, 전후의 개수를 확인하면 검토 가능한 결과를 얻을 수 있습니다.
빈 줄을 제거하면 빈 행이 수정됩니다. ToolAcre가 CR을 올바르게 분할한 후에는 일반적으로 트리밍이 필요하지 않습니다.
재현 가능한 예를 위해 손상된 중간 표현에 각 이름 사이에 빈 행이 포함된 세 개의 이름(`Ada`, 공백, `Grace`, 공백, `Linus`)으로 시작합니다. 단어 및 문자 카운터는 5줄을 보고합니다. 이는 의도적으로 입력을 두 배로 늘린 것입니다. 진짜 CRLF 시퀀스만으로도 하나의 경계로 인식되며 ToolAcre에서 빈 행을 생성하지 않습니다.
빈 줄 제거를 선택하면 출력은 LF와 결합된 세 줄이 됩니다. 이제 카운터는 3개를 보고해야 합니다. 가져온 값에도 패딩이 있는 경우 Trim Lines를 별도로 실행하고 결과를 검토하세요. 이러한 작업을 분리하면 모든 정리를 Windows 텍스트의 모호한 변환에 귀속시키는 대신 각 작업이 수정된 결함이 무엇인지 입증됩니다.
작업 예: 의도적으로 두 배로 늘린 내보내기를 정리하고 줄 수를 확인합니다.
줄 끝 정리는 하나의 논리적 문장이 의도적으로 열 너비에서 끊어진 하드 래핑을 복구하지 않습니다. 해당 자료에서 모든 개행을 제거하면 실제 단락과 목록 항목도 결합됩니다. 전체 블록에 선 작업을 적용하기 전에 경계가 레코드, 단락 또는 시각적 줄 바꿈을 나타내는지 여부를 결정합니다.
또한 문자 인코딩을 진단하지 않습니다. UTF-8 바이트 순서 표시, 교체 다이아몬드, mojibake 및 디코딩 실패는 CR 또는 LF가 해당 문자를 행으로 분리하는지 여부가 아니라 바이트가 문자가 되는 방식과 관련됩니다. 눈에 보이는 이상한 기호를 줄 끝으로 처리하기 전에 원본 파일을 보존하고 적절한 파일 인식 도구를 사용하여 해당 인코딩을 식별하십시오.
요점 — 줄 끝은 볼 수 있는 기록입니다. Text Toolkit의 라인 도구와 카운터를 사용하면 몇 초 만에 증상을 수정할 수 있습니다.
CR, LF 및 CRLF는 현재 호환성 결과를 가져온 과거 컨트롤입니다. 가장 안전한 정신 모델은 여러 물리적 표현이 포함된 하나의 논리적 선 경계입니다. 레코드 수를 세고, 소스 규칙을 검사하고, 삭제하기 전에 빈 행을 도입했거나 제어 문자를 유지한 단계를 식별합니다.
붙여넣은 자료의 경우 `/tools/text/`에서 텍스트 도구 키트를 열고, 초기 줄 수를 기록하고, 빈 행이 정말로 원하지 않는 경우에만 빈 줄 제거를 적용하고, 주변 공백에 대해서만 줄 자르기를 사용하세요. 나중에 카운트 및 샘플 기록을 다시 확인하십시오. 짧은 감사는 눈에 보이지 않는 서식 문제를 제어되고 되돌릴 수 있는 텍스트 변환으로 바꿉니다.