캐리지 리턴 (CR) 및 줄 바꿈 (LF)의 개념은 밀접하게 연관되어 있으며 개별적으로 또는 함께 고려 될 수 있습니다. 타자기와 프린터의 물리적 매체에서 페이지에 새 선을 만들려면 두 개의 모션 축인 “아래쪽”과 “횡단”이 필요합니다. 기계 (타자기 나 프린터)의 디자인은 그것들을 따로 고려해야하지만, 소프트웨어의 추상적 인 논리는 그것들을 하나의 이벤트로 결합 할 수 있습니다. 이것이 문자 인코딩의 개행을 CR 과 LF 가 하나로 결합 된 것으로 정의 할 수있는 이유입니다. (일반적으로 CR + LF 또는 CRLF 라고 함)

일부 문자 세트는 별도의 개행 문자 코드를 제공합니다. 예를 들어 EBCDIC는 CR 및 LF 코드 외에도 NL 문자 코드를 제공합니다. 유니 코드는 ASCII CR 및 LF 제어 코드를 제공하는 것 외에도 “NEL (next line)”제어 코드와 “행 분리 자”및 “단락 분리 자”마커에 대한 제어 코드도 제공합니다.

• EBCDIC 시스템 (주로 z / OS (OS / 390) 및 i5 / OS (OS / 400)을 포함한 IBM 메인 프레임 시스템)은 줄 바꿈 및 캐리지 기능을 결합한 문자로 NL (New Line, 0x15)을 사용합니다. 반환. 동등한 유니 코드 문자 ( 0x85 )를 NEL (Next Line)이라고합니다. EBCDIC에는 CR 및 LF라는 제어 문자도 있지만 LF (0x25)의 숫자 값은 ASCII (0x0A)에서 사용하는 값과 다릅니다. 또한 일부 EBCDIC 변형은 NL도 사용하지만 문자에 다른 숫자 코드를 지정합니다. 그러나 이러한 운영 체제는 텍스트 파일을 한 줄에 하나의 레코드로 저장하는 레코드 기반 파일 시스템을 사용합니다. 대부분의 파일 형식에서 실제로는 줄 종결자가 저장되지 않습니다.
• CDC 6000 시리즈의 운영 체제에서는 60 비트 단어 끝에있는 두 개 이상의 0 값 6 비트 문자로 줄 바꿈을 정의했습니다. 일부 구성에서는 값이 0 인 문자를 콜론 문자로 정의하기도하므로 여러 콜론이 위치에 따라 줄 바꿈으로 해석 될 수 있습니다.
• RSX-11 및 OpenVMS도 레코드 기반 파일 시스템을 사용합니다. , 텍스트 파일을 한 줄에 하나의 레코드로 저장합니다. 대부분의 파일 형식에서 실제로는 줄 종결자가 저장되지 않지만 Record Management Services 기능은 응용 프로그램에서 검색 할 때 각 줄에 종결자를 투명하게 추가 할 수 있습니다. 레코드 자체에는 동일한 줄 종결 문자가 포함될 수 있으며 이는 응용 프로그램에 따라 기능이나 성가신 것으로 간주 될 수 있습니다. RMS는 레코드를 저장할뿐만 아니라 파일이 문제를 더욱 복잡하게하기 위해 다른 비트에 레코드 구분 기호에 대한 메타 데이터를 저장했습니다 (파일에는 고정 길이 레코드, 개수로 접두사가 붙은 레코드 또는 특정 문자로 끝나는 레코드가있을 수 있기 때문) ). 비트는 일반적이지 않았기 때문에 CRLF 또는 LF 또는 CR이 라인 종결 자임을 지정할 수는 있었지만 다른 코드를 대체 할 수는 없었습니다.
• 일부 초기 메인 프레임 운영에서 고정 라인 길이를 사용했습니다. 시스템. 이러한 시스템에서는 예를 들어 72 자 또는 80 자마다 암시 적 줄 끝이 가정됩니다. 개행 문자가 저장되지 않았습니다. 외부에서 파일을 가져온 경우 줄 길이보다 짧은 줄은 공백으로 채워야하고 줄 길이보다 긴 줄은 잘 려야했습니다. 이것은 천공 카드의 사용을 모방 한 것으로, 각 라인은 일반적으로 각 카드에 80 개의 열이 있고 종종 73-80 열에 시퀀스 번호가있는 별도의 카드에 저장되었습니다. 이러한 시스템의 대부분은 다음 레코드의 시작 부분에 캐리지 제어 문자를 추가했습니다. 이것은 다음 레코드가 이전 레코드로 시작된 줄의 연속인지 또는 새 줄인지 또는 이전 줄을 겹쳐 인쇄해야하는지 여부를 나타낼 수 있습니다 (CR과 유사). 종종 이것은 # 와 같은 일반적인 인쇄 문자 였으므로 한 줄의 첫 번째 문자로 사용할 수 없습니다. 일부 초기 라인 프린터는 전송 된 레코드에서 이러한 문자를 직접 해석했습니다.

UnicodeEdit

유니 코드 표준은 준수 응용 프로그램이 줄 종결 자로 인식해야하는 여러 문자를 정의합니다.

LF : 줄 바꿈, U + 000A VT : 수직 탭, U + 000B FF : 용지 공급, U + 000C CR : 캐리지 리턴, U + 000D CR + LF : CR (U + 000D) 다음에 LF (U + 000A) NEL : 다음 줄, U + 0085 LS : 줄 구분 기호, U + 2028 PS : 단락 구분 기호, U + 2029

모든 줄 종결자를 단일 문자 (예 : LF)로 변환하는 것과 같은 접근 방식에 비해 지나치게 복잡해 보일 수 있습니다. 그러나 유니 코드는 텍스트 파일을 기존 인코딩에서 유니 코드로 변환 할 때 모든 정보를 보존하도록 설계되었습니다. 따라서 유니 코드는 기존 인코딩에 포함 된 문자를 포함해야합니다.NL은 코드 0x15로 EBCDIC에 포함되며 종종 C1 제어 세트의 제어 문자 인 NEL에 맵핑됩니다. 따라서 ECMA 48에 의해 정의되고 ISO / IEC 2022 (ECMA 35와 동일)를 준수하는 인코딩으로 인식됩니다. C1 컨트롤 세트는 ISO-8859-1 과도 호환됩니다. 유니 코드 표준에서 취한 접근 방식을 사용하면 왕복 변환이 정보를 보존하는 동시에 응용 프로그램이 가능한 모든 유형의 줄 종결자를 인식 할 수 있습니다.

0x7F (NEL, LS)보다 큰 줄 바꿈 코드 인식 및 사용 및 PS)는 자주 수행되지 않습니다. UTF-8의 다중 바이트이며 Windows-1252에서는 NEL 코드가 줄임표 (… ) 문자로 사용되었습니다. 예 :

• ECMAScript는 LS 및 PS를 줄 바꿈으로 허용하지만 줄 바꿈 대신 U + 0085 (NEL) 공백을 고려합니다.
• Windows 10은 NEL, LS 또는 PS를 기본 텍스트 편집기 인 메모장에서 줄 바꿈으로 처리하지 않습니다.
• GNOME 데스크톱 환경의 기본 텍스트 편집기 인 gedit , LS 및 PS는 줄 바꿈으로 처리하지만 NEL에는 해당되지 않습니다.
• JSON은 문자열 내에서 LS 및 PS 문자를 허용하는 반면 ES2019 이전의 ECMAScript는 줄 바꿈으로 처리하므로 잘못된 구문입니다.
• YAML은 JSON과 호환되도록 더 이상 버전 1.2부터 특수한 것으로 인식하지 않습니다.

유니 코드 문자 U + 2424 (SYMBOL FOR NEWLINE, ␤ ), U + 23CE (반환 기호, ⏎ ), U + 240D (SYMBOL FOR 캐리지 리턴, ␍ ) 및 U + 240A (라인 피드 기호, ␊ )는 문서의 독자에게 사용자가 볼 수있는 문자를 제공하기위한 것이므로 개행 문자로 인식되지 않습니다.

이스케이프 시퀀스 편집

이스케이프 시퀀스는 다음과 같은 문자의 조합입니다. 텍스트가 없음을 나타냅니다. 텍스트로 표시되는 대신 프로그램에서 가로 채고 특수 기능이 수행되어야합니다. 이스케이프 시퀀스는 특수 문자를 처리 (설정, 검색, 대체 등)하는데도 사용됩니다.

프로그래밍 언어에서 편집

이식 가능한 프로그램을 쉽게 만들 수 있도록 프로그래밍 언어는 여러 환경에서 사용되는 여러 유형의 줄 바꿈 시퀀스를 처리 할 수있는 추상화를 제공합니다.

C 프로그래밍 언어는 이스케이프 시퀀스 “\ n”(줄 바꿈) 및 “\ r”(캐리지 리턴)을 제공합니다. 그러나 이들은 ASCII LF 및 CR 제어 문자와 동일 할 필요는 없습니다. C 표준은 두 가지만 보장합니다.

1. 이러한 각 이스케이프 시퀀스는 단일 char 값에 저장할 수있는 고유 한 구현 정의 숫자에 매핑됩니다.
2. 작성할 때 텍스트 모드의 파일, 장치 노드 또는 소켓 / fifo에 “\ n”은 시스템에서 사용하는 기본 줄 바꿈 시퀀스로 투명하게 변환되며 이는 한 문자보다 길 수 있습니다. 텍스트 모드에서 읽을 때 기본 줄 바꿈 시퀀스는 다시 “\ n”으로 변환됩니다. 바이너리 모드에서는 변환이 수행되지 않고 “\ n”에 의해 생성 된 내부 표현이 직접 출력됩니다.

C가 시작된 Unix 플랫폼에서 기본 줄 바꿈 시퀀스는 ASCII LF ( 0x0A), “\ n”은 단순히 그 값으로 정의되었습니다. 내부 및 외부 표현이 동일하기 때문에 텍스트 모드에서 수행되는 변환은 작동하지 않으며 Unix에는 텍스트 모드 또는 바이너리 모드 개념이 없습니다. 이로 인해 Unix 시스템에서 소프트웨어를 개발 한 많은 프로그래머가 그 차이를 완전히 무시하고 코드를 다른 플랫폼으로 이식 할 수 없게되었습니다.

C 라이브러리 함수 fgets ()는 바이너리 모드에서 피하는 것이 가장 좋습니다. Unix 개행 규칙으로 작성되지 않은 파일은 잘못 읽히기 때문입니다. 또한 텍스트 모드에서 시스템의 기본 줄 바꿈 시퀀스로 작성되지 않은 파일 (예 : Unix 시스템에서 생성 된 다음 Windows 시스템에 복사 된 파일)도 잘못 읽 힙니다.

또 다른 일반적인 문제는 끝 줄에 ASCII CR + LF를 사용해야하는 인터넷 프로토콜을 사용하여 통신 할 때 “\ n”을 사용하는 것입니다. 텍스트 모드 스트림에 “\ n”을 쓰는 것은 Windows 시스템에서 제대로 작동하지만 LF 만 생성합니다. Unix, 그리고 좀 더 이국적인 시스템에서는 완전히 다른 것입니다. 바이너리 모드에서 “\ r \ n”을 사용하는 것이 약간 더 좋습니다.

Java I / O 라이브러리는이를 플랫폼에 따라 다른 줄 바꿈 시퀀스로 투명하게 변환하지 않습니다. 대신 기본 줄 바꿈 시퀀스를 자동으로 추가하는 전체 줄을 작성하는 함수와 줄 종결 자로 CR, LF 또는 CR + LF를 허용하는 줄을 읽는 함수를 제공합니다 (BufferedReader.readLine (참조). System.lineSeparator () 메서드를 사용하여 기본 줄 구분 기호를 검색 할 수 있습니다.

예 :

 String eol = System.lineSeparator(); String lineColor = "Color: Red" + eol;

Python은 읽기 위해 파일을 열 때 “Universal Newline Support”를 허용합니다. 모듈을 가져오고 파일을 실행할 때.

일부 언어는 프로그램 실행 중에 줄 바꿈을 용이하게하기 위해 특수 변수, 상수 및 서브 루틴을 생성했습니다. PHP 및 Perl과 같은 일부 언어에서는 “\ n”및 “\ r”을 포함한 모든 이스케이프 시퀀스에 대한 이스케이프 대체를 수행하려면 큰 따옴표가 필요합니다. PHP에서 이식성 문제를 방지하려면 PHP_EOL 상수를 사용하여 줄 바꿈 시퀀스를 발행해야합니다.

C #의 예 :

 string eol = Environment.NewLine; string lineColor = "Color: Red" + eol; string eol2 = "\n"; string lineColor2 = "Color: Blue" + eol2;

다른 줄 바꿈 형식의 문제 편집

텍스트 파일에서 사용하는 해당 문자 인코딩 테이블에 제어 문자가 명확하게 정의되어 있더라도 , 여전히 문제가 있습니다. 줄 바꿈을 설정하고 표시하는 다른 규칙이 있습니다.

단일 줄 바꿈을 나타 내기 위해 Unix 프로그램은 줄 바꿈을 사용합니다. , ASCII의 16 진수 값은 0a 인 반면 MS-DOS 및 Microsoft Windows에 일반적인 대부분의 프로그램은 캐리지 리턴 + 라인 피드 , ASCII의 16 진수 값은 0d 0a . ASCII에서 캐리지 리턴은 고유 한 제어 문자입니다.

다른 줄 바꿈 규칙으로 인해 다른 유형의 시스템간에 전송 된 텍스트 파일이 잘못 표시됩니다.

생성 된 파일의 텍스트 Unix 유사 또는 클래식 Mac OS에서 일반적인 프로그램은 MS-DOS 및 Microsoft Windows에 공통적 인 대부분의 프로그램에서 하나의 를 표시하지 않기 때문에 하나의 긴 줄로 나타납니다. 줄 바꿈 또는 단일 캐리지 리턴 (줄 바꿈)

반대로 Windows 컴퓨터에서 가져온 파일을 볼 때 Unix 계열 시스템에서 추가 CR은 ^ M 또는 < cr >로 두 번째 줄 바꿈으로 표시 될 수 있습니다.

또한 텍스트 편집기 이외의 프로그램은 파일을 허용하지 않을 수 있습니다. 외부 줄 바꿈 규칙을 사용하여 인코딩 된 일부 구성 파일은 유효한 파일입니다.

일부 프로그램은 외부 줄 바꿈을 제대로 처리하는 반면 다른 프로그램은 그렇지 않기 때문에 문제를 파악하기 어려울 수 있습니다. 예를 들어, 소스 파일이 콘솔이나 편집기에 표시 될 때 올바르게 표시 되더라도 컴파일러가 모호한 구문 오류로 인해 실패 할 수 있습니다. Unix 계열 시스템에서 cat -v myfile.txt 명령은 파일을 stdout (일반적으로 터미널)로 보내고 ^ M을 표시하므로 디버깅에 유용 할 수 있습니다. 최신 텍스트 편집기는 일반적으로 CR + LF 줄 바꿈의 모든 특징을 인식하고 사용자가 서로 다른 표준간에 변환 할 수 있도록합니다. 웹 브라우저는 일반적으로 다른 유형의 줄 바꿈을 사용하는 텍스트 파일과 웹 사이트를 표시 할 수도 있습니다.

프로그램이 다른 줄 바꿈 규칙을 지원하더라도 이러한 기능은 종종 충분한 레이블, 설명 또는 문서화되지 않습니다. 일반적으로 다른 줄 바꿈 규칙을 열거하는 메뉴 또는 콤보 상자는 선택 항목이 줄 바꿈을 다시 해석하거나 일시적으로 변환하거나 영구적으로 변환할지 여부를 표시하지 않고 사용자에게 표시됩니다. 일부 프로그램은 열기, 복사, 붙여 넣기 또는 저장시 묵시적으로 변환되며 종종 일관성이 없습니다.

대부분의 텍스트 인터넷 프로토콜 (HTTP, SMTP, FTP, IRC 및 기타 여러 프로토콜 포함)에서는 ASCII CR +를 사용해야합니다. 프로토콜 수준의 LF ( “\ r \ n”, 0x0D 0x0A),하지만 허용되는 응용 프로그램은 고독한 LF ( “\ n”, 0x0A)도 인식하는 것이 좋습니다. 지시 된 표준에도 불구하고, 많은 응용 프로그램은 캐리지 리턴 이스케이프 및 줄 바꿈 이스케이프 시퀀스 “\ r \ n”(CR + LF)의 올바른 조합 대신 C 줄 바꿈 이스케이프 시퀀스 “\ n”(LF)를 잘못 사용합니다 (섹션의 줄 바꿈 참조). 위의 프로그래밍 언어). 잘못된 이스케이프 시퀀스를 실수로 사용하면 제안 된 허용 해석 대신 표준에 대한보다 엄격한 해석을 고수하는 시스템과 통신하려고 할 때 문제가 발생합니다. 그러한 편협한 시스템 중 하나는 필수 CR + LF 대신 베어 LF를 보내는 시스템의 메시지 수신을 적극적으로 거부하는 큐메일 메일 전송 에이전트입니다.

이메일을위한 표준 인터넷 메시지 형식은 다음과 같습니다. CRLF로만 함께 발생합니다. 그들은 본문에서 독립적으로 나타나지 않아야합니다.

파일 전송 프로토콜은 “ASCII 모드”에서 전송이 수행 될 때 다른 줄 바꿈 표현을 가진 시스템간에 전송되는 파일의 줄 바꿈을 자동으로 변환 할 수 있습니다.그러나이 모드에서 이진 파일을 전송하면 일반적으로 비참한 결과가 발생합니다.이 컨텍스트에서 줄 종결 자 의미가 없지만 정상적인 바이트 시퀀스의 일부인 줄 바꿈 바이트 시퀀스의 발생은 모든 줄 바꿈 표현으로 변환됩니다. 다른 시스템이 사용하여 파일을 효과적으로 손상시킵니다. FTP 클라이언트는 종종 몇 가지 휴리스틱 (예 : 파일 이름 확장자 검사)을 사용하여 바이너리 또는 ASCII 모드를 자동으로 선택하지만 결국에는 파일이 올바른 모드로 전송되는지 확인하는 것은 사용자의 몫입니다. 올바른 모드가 확실하지 않은 경우 바이너리 모드를 사용해야합니다. 그러면 파일이 잘못 표시 될 수 있지만 FTP에 의해 파일이 변경되지 않습니다.

개행 형식 간의 변환 편집

텍스트 편집기는 종종 다른 개행 형식 사이에서 텍스트 파일을 변환하는 데 사용됩니다. 대부분의 최신 편집기는 최소한 다른 ASCII CR / LF 규칙을 사용하여 파일을 읽고 쓸 수 있습니다. 예를 들어, Vim 편집기는 Windows 메모장 텍스트 편집기와 호환되는 파일을 만들 수 있습니다. vim 내에서

 :set fileformat=dos :wq

편집기는 더 큰 파일을 변환하거나 많은 파일을 대량 변환하는 데 적합하지 않을 수 있습니다. 대용량 파일 (Windows NT / 2000 / XP)의 경우 다음 명령이 자주 사용됩니다.

D:\>TYPE unix_file | FIND /V "" > dos_file

변환 할 특수 목적 프로그램 다른 줄 바꿈 규칙 사이의 파일에는 unix2dos 및 dos2unix, mac2unix 및 unix2mac, mac2dos 및 dos2mac 및 flip이 포함됩니다. tr 명령은 거의 모든 Unix 계열 시스템에서 사용할 수 있으며 단일 문자에 대해 임의의 대체 작업을 수행하는 데 사용할 수 있습니다. DOS / Windows 텍스트 파일은

$ tr -d "\r" < inputfile > outputfile

를 사용하여 모든 ASCII CR 문자를 제거하거나 텍스트에 CR 줄 바꿈 만있는 경우 다음을 사용하여 Unix 형식으로 변환 할 수 있습니다. 모든 CR 개행을 LF로 변환

$ tr "\r" "\n" < inputfile > outputfile

플랫폼에 Perl 인터프리터가있는 경우 awk, sed 또는 Perl에서 동일한 작업이 수행되는 경우가 있습니다.

p>

파일 명령은 줄 끝의 유형을 식별 할 수 있습니다 :

 $ file myfile.txt myfile.txt: ASCII English text, with CRLF line terminators

Unix egrep (확장 grep) 명령 Unix 또는 DOS 파일의 파일 이름을 인쇄하는 데 사용할 수 있습니다 (Mac OS가 아닌 Unix 및 DOS 스타일 파일 만 가정) :

$ egrep -L "\r\n" myfile.txt # show UNIX style file (LF terminated)$ egrep -l "\r\n" myfile.txt # show DOS style file (CRLF terminated)

다른 도구를 사용하면 사용자가 EOL 문자를 시각화 할 수 있습니다.

$ od -a myfile.txt$ cat -e myfile.txt$ hexdump -c myfile.txt