뉴라인

Newline
"Hello"와 "world" 단어 사이에 삽입된 뉴라인

뉴라인(Newline, Line Ending, End of Line(EOL), 다음 라인(NEL) 또는 라인 브레이크라고 자주 불림)은 문자 인코딩 규격(예: ASCII, EBCDIC)의 컨트롤 문자 또는 시퀀스로, 텍스트 라인의 과 새로운 라인의 시작을 나타내는 데 사용된다.[1]

역사

1800년대 중반, 텔레프린터와 텔레타이프 기계가 등장하기 훨씬 전에, 모스 부호 연산자나 텔레그래피스트들모스 부호 프로시그들을 발명해 사용함으로써 공식적인 문자메세지로 화이트 스페이스 텍스트 서식을 인코딩하였다.특히 정상적인 문자간 간격 없이 전송되는 문자 문자 문자 Morse 코드 "B"와 "T" 문자의 결합으로 대표되는 Morse prosign BT(네모닉 브레이크 텍스트)는 Morse 코드에 사용되어 형식 문자 메시지에서 새로운 줄이나 새로운 섹션을 인코딩하고 표시한다.

이후 현대 텔레프린터 시대에는 화이트 스페이스 텍스트 포맷을 돕기 위해 표준화된 문자 집합 제어 코드가 개발되었다.ASCII는 국제표준화기구(ISO)와 미국표준협회(ASA)에 의해 동시에 개발되었으며, 후자는 미국 국립표준연구소(ANSI)의 전신이다.1963년부터 1968년까지 ISO 초안 표준은 CR+LF 또는 LF만 새로운 라인으로 사용하는 것을 지원하였고, ASA 초안은 CR+LF만 지원하였다.

시퀀스 CR+LF는 일반적으로 Teletype 머신(일반적으로 Teletype Model 33 ASR)을 콘솔 기기로 채택한 많은 초기 컴퓨터 시스템에서 사용되었는데, 이 시퀀스는 새로운 라인의 시작 부분에 이러한 프린터를 배치하기 위해 필요했기 때문이다.뉴라인이 두 가지 기능으로 분리되면서 인쇄 헤드가 다음 문자를 인쇄할 시간에 맞춰 오른쪽 끝에서 다음 라인의 시작 부분까지 돌아올 수 없다는 사실을 숨겼다.CR 뒤에 인쇄된 문자는 인쇄 헤드가 여전히 캐리지를 첫 번째 위치로 다시 이동하는 동안 페이지 중간에 스머지로 인쇄되는 경우가 많았다."해결책은 새 줄을 1열로 마차를 이동시키는 CR과 종이를 위로 이동시키는 LF라는 두 개의 문자로 만드는 것이었다.[2]사실, 종종 추가 문자(관련되지 않은 CR 또는 NUL)를 보내야 하는 경우가 있었는데, 이 문자는 무시되지만 인쇄 헤드가 왼쪽 여백으로 이동할 수 있는 시간을 준다.많은 초기 비디오 디스플레이도 디스플레이를 스크롤하는 데 여러 문자 시간이 필요했다.

그러한 시스템에서 애플리케이션은 그러한 하드웨어 세부사항을 애플리케이션으로부터 숨기는 장치 드라이버의 개념이 아직 잘 개발되지 않았기 때문에 텔레타이프 기계와 직접 대화하고 그 규약을 따라야 했다.따라서 텍스트는 텔레타이프 기계의 요구를 만족시키기 위해 일상적으로 구성되었다.DEC의 대부분의 미니컴퓨터 시스템은 이 규칙을 사용했다.CP/M도 미니컴퍼터가 사용하던 단말기에 인쇄하기 위해 사용했다.거기서부터 MS-DOS(1981)는 호환성을 위해 CP/MCR+LF를 채택하였고, 이 협약은 마이크로소프트의 후기 윈도 운영체제에 계승되었다.

멀티크스 운영체제는 1964년에 개발을 시작했으며 LF만을 뉴라인으로 사용했다.멀티픽스는 장치 드라이버를 사용하여 프린터에 필요한 시퀀스(추가 패딩 문자 포함)로 이 문자를 번역했으며, 단일 바이트는 프로그래밍에 더 편리했다.더 확실한 선택인 것 같군CRCR은 굵은 글꼴, 밑줄취소선 효과를 생성하기 위해 한 줄을 다른 선과 겹쳐 인쇄하는 유용한 기능을 제공했기 때문에 사용하지 않았다.아마도 더 중요한 것은 LF만을 회선 종단기로 사용하는 것이 이미 최종 ISO/IEC 646 표준의 초안에 통합되어 있었다.유닉스는 멀티틱스 관행을 따랐고, 이후 유닉스 비슷한 시스템이 유닉스를 따랐던 것이다.이로 인해 Windows와 Unix와 유사한 운영 체제 사이에 충돌이 발생하여 한 운영 체제에 구성된 파일은 다른 운영 체제에 의해 적절하게 포맷되거나 해석될 수 없다(예: 메모장과 같은 Windows 텍스트 편집기로 작성된 UNIX 스크립트).

표현

캐리지 리턴(CR)과 라인 피드(LF)의 개념은 밀접하게 연관되어 있으며 별도로 또는 함께 고려할 수 있다.타이프라이터프린터의 물리적 매체에서 페이지에 새로운 줄을 만들기 위해서는 모션의 두 인 "다운"과 "across"가 필요하다.기계(타입 작성기 또는 프린터)의 설계는 별도로 고려해야 하지만 소프트웨어의 추상적인 논리는 하나의 사건으로 이들을 결합시킬 수 있다.문자 인코딩의 뉴라인이 다음과 같이 정의될 수 있는 이유다.CR그리고LF하나로 합쳐서.CR+LF또는CRLF).

일부 문자 집합은 별도의 뉴라인 문자 코드를 제공한다.예를 들어 EBCDICCRLF 코드 외에 NL 문자 코드를 제공한다.유니코드ASCII CRLF 제어 코드를 제공하는 것 외에도 "다음 라인"(NEL) 제어 코드와 "라인 구분자" 및 "문단 구분자" 마커에 대한 제어 코드를 제공한다.

하나 또는 두 개의 제어 문자를 가진 새로운 라인의 소프트웨어 응용 프로그램 및 운영 체제 표현
운영 체제 문자 부호화 약어 육각 을 매기다 탈출 순서
Unix 및 Unix 유사 시스템(Linux, macOS, FreeBSD, AIX, Xenix 등), Multics, BeOS, Amiga, RISC OS[3] ASCII LF 0A 10 \n
Microsoft Windows, DOS(MS-DOS, PC DOS 등), Atari TOS, DEC TOPS-10, RT-11, CP/M, MP/M, OS/2, Symbian OS, 팜 OS, Amstrad CPC 및 기타 대부분의 초기 비유닉스 및 비-IBM 운영 체제 CR LF 0D 0A 13 10 \r\n
Commodore 8비트 머신(C64, C128), Aorton BBC, ZX Spectrum, TRS-80, Apple II 시리즈, Oberon, 클래식OS, MIT Lisp MachineOS-9 CR 0D 13 \r
QNX 사전 POSIX 구현(버전 < 4) RS 1E 30 \036
도토리[4] BBC 및 RISC OS 스풀 텍스트 출력[5] LF CR 0A 0D 10 13 \n\r
아타리 8비트 시스템 AT ASCII 9B 155
z/OS(OS/390) 및 IBM i(OS/400)를 포함한 IBM 메인프레임 시스템 EBCDIC NL 15 21 \025
ZX80ZX81(Sinclair Research Ltd.의 가정용 컴퓨터) 특정 비 ASC 사용II 문자 집합 뉴라인 76 118
  • EBCDIC 시스템—주로 z/OS(OS/390)와 IBM i(OS/400)를 포함한 IBM 메인프레임 시스템—NL(New Line, 0x15)[6]을 회선 피드와 캐리지 리턴의 기능을 결합한 문자로 사용한다.등가 유니코드 문자(0x85)는 NEL(Next Line)이라고 한다.EBCDIC는 또한 CRLF라는 제어 문자를 가지고 있지만, LF(0x25)의 숫자 값은 ASCII(0x0A)가 사용하는 값과 다르다.또한 일부 EBCDIC 변종도 NL을 사용하지만 문자에 다른 숫자 코드를 할당한다.그러나 이러한 운영체제는 텍스트 파일을 한 줄에 하나의 레코드로 저장하는 레코드 기반 파일 시스템을 사용한다.대부분의 파일 형식에서 실제로 저장되는 회선 종단기는 없다.
  • CDC 6000 시리즈의 운영 체제는 60비트 워드의 끝에서 두 개 이상의 영점 6비트 문자로 새로운 줄을 정의했다.일부 구성에서는 0의 값을 콜론 문자로 정의하기도 했는데, 그 결과 위치에 따라 여러 개의 콜론이 뉴라인으로 해석될 수 있었다.
  • RSX-11과 OpenVMS도 텍스트 파일을 한 줄에 하나의 레코드로 저장하는 레코드 기반 파일 시스템을 사용한다.대부분의 파일 형식에서, 실제로 저장되는 회선 종단기는 없지만, 레코드 관리 서비스 시설은 애플리케이션에 의해 검색될 때 각 회선에 종단기를 투명하게 추가할 수 있다.레코드 자체는 애플리케이션에 따라 특징이나 성가신 것으로 간주될 수 있는 동일한 줄 터미네이터 문자를 포함할 수 있다.RMS는 레코드를 저장했을 뿐만 아니라, 파일이 문제를 더욱 복잡하게 하기 위해 레코드 구분자에 관한 메타데이터를 다른 비트에 저장했다(파일은 고정된 길이 레코드를 가질 수 있기 때문에, 특정 문자에 의해 종료된 레코드 또는 카운트로 접두사가 된 레코드).비트는 일반적이지 않기 때문에 CRLF 또는 LF 또는 심지어 CR이 회선 종단기임을 지정할 수 있지만, 일부 다른 코드를 대체할 수는 없었다.
  • 일부 초기 메인프레임 운영 체제에서 고정 회선 길이를 사용했다.그러한 시스템에서는 예를 들어 72자 또는 80자마다 암묵적인 종단선을 가정하였다.뉴라인 캐릭터가 저장되지 않았다.파일을 외부 세계에서 가져온 경우, 줄 길이보다 짧은 줄은 공백으로 채워야 했고 줄 길이보다 긴 줄은 잘려야 했다.이것은 펀치 카드를 사용하는 것을 모방한 것인데, 그 위에 각 줄은 보통 각 카드에 80개의 열이 있고, 종종 73-80개의 열에 시퀀스 번호가 있는 별도의 카드에 저장되었다.이러한 시스템 중 많은 수가 다음 레코드의 시작에 캐리지 제어 문자를 추가했다. 이는 다음 레코드가 이전 레코드 또는 새로운 라인에 의해 시작된 라인의 연속인지 또는 이전 라인(CR과 유사)을 오버프린트해야 하는지를 나타낼 수 있다.종종 이것은 다음과 같은 평범한 인쇄 캐릭터였다.#따라서 줄의 첫 번째 문자로 사용할 수 없다.일부 초기 라인 프린터는 이 문자를 전송한 기록에서 직접 해석했다.

유니코드

유니코드 표준은 응용프로그램을 준수하는 여러 문자를 라인 종단기로 인식해야 하는 것으로 정의한다.[7]

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의 일부로서, 일반적으로 유니코드 NEL, 0x85에 매핑되며, 이는 C1 제어 세트의 제어 문자다.[8]이와 같이 ECMA 48에 의해 정의되며,[9] ISO/IEC 2022(ECMA 35에 해당)를 준수하는 인코딩에 의해 인정된다.[10]C1 제어 세트는 ISO-8859-1과도 호환된다.[citation needed]유니코드 표준에서 채택된 접근방식은 응용 프로그램이 가능한 모든 유형의 회선 종단기를 인식할 수 있도록 하는 동시에 왕복 변환이 정보를 보존할 수 있도록 한다.

0x7F(NEL, LS, PS)보다 큰 뉴라인 코드를 인식하고 사용하는 일이 자주 이루어지지 않는다.그것들은 UTF-8의 다중 바이트이며, NEL의 코드는 줄임표로 사용되어 왔다.Windows-1252의 문자.예를 들어,

  • ECMAScriptLSPS를 줄 바꿈으로 받아들이지만 줄 바꿈 대신 U+0085(NEL) 공백을 고려한다.[11][12]
  • 윈도 10은 기본 텍스트 편집기인 메모장에서 NEL, LS 또는 PS 중 어느 것도 줄 바꿈으로 취급하지 않는다.
  • GNOME 데스크톱 환경의 기본 텍스트 편집기geditLSPS를 새로운 선으로 취급하지만 NEL에게는 그렇지 않다.
  • JSON[13] 문자열 내에서 LSPS 문자를 허용하는 반면, ES2019[14][15] 이전의 ECMAScript는 문자열을 새로운 선으로 취급하여, 따라서 불법 구문을 허용한다.[16]
  • YAML[17] 더 이상 JSON과 호환되기 위해 버전 1.2의 특별한 것으로 인식하지 않는다.

유니코드 특수 문자 U+2424를 참조하십시오.뉴라인 기호,(), U+23CE(반환 기호,(), U+240D(캐리지 리턴에 대한 심볼,) 및 U+240A(라인 피드용 심볼,)은 문서 독자에게 사용자 정의 문자를 제시하기 위한 글립스로서, 따라서 그 자체를 뉴라인으로 인식하지 못한다.

프로그래밍 언어에서

휴대용 프로그램을 쉽게 만들 수 있도록 프로그래밍 언어는 다른 환경에서 사용되는 다양한 유형의 뉴라인 시퀀스를 처리하기 위한 추상화를 제공한다.

C 프로그래밍 언어탈출 시퀀스 '\n'(뉴라인)과 '\r'(캐리지 리턴)을 제공한다.단, ASCII LFCR 제어 문자와 동등할 필요는 없다.C 표준은 다음 두 가지 사항만 보장한다.

  1. 이러한 각 이스케이프 시퀀스는 단일 문자 값에 저장할 수 있는 고유한 구현 정의 번호에 매핑된다.
  2. 텍스트 모드에서 파일, 장치 노드 또는 소켓/50o에 쓸 때 '\n'은 시스템에서 사용하는 네이티브 뉴라인 시퀀스로 투명하게 번역되며, 이는 한 문자보다 길 수 있다.텍스트 모드에서 읽을 때 기본 뉴라인 시퀀스가 다시 '\n'으로 변환된다.바이너리 모드에서는 번역이 수행되지 않으며, '\n'에 의해 생성된 내부표현이 직접 출력된다.

C가 발원한 유닉스 플랫폼에서 기본 뉴라인 시퀀스는 ASCII LF(0x0A)이므로 '\n'은 단순히 그 값으로 정의되었다.내외부 표현이 동일한 상황에서 텍스트 모드에서 수행되는 번역은 no-op이며, Unix는 텍스트 모드나 이진 모드에 대한 개념이 없다.이로 인해 유닉스 시스템에서 소프트웨어를 개발한 많은 프로그래머들이 단순히 구별을 완전히 무시하게 되었고, 결과적으로 다른 플랫폼으로 이동하지 않는 코드가 생겨났다.

C 라이브러리 함수 fget()는 Unix newline 규약으로 작성되지 않은 파일은 잘못 읽히기 때문에 바이너리 모드에서는 피하는 것이 가장 좋다.또한 텍스트 모드에서는 시스템의 기본 뉴라인 시퀀스로 작성되지 않은 파일(예: Unix 시스템에서 생성된 파일, Windows 시스템에 복사된 파일)도 잘못 읽힌다.

또 다른 일반적인 문제는 종단선에 ASCII CR+LF 사용을 의무화하는 인터넷 프로토콜을 사용하여 통신할 때 '\n'을 사용하는 것이다.텍스트 모드 스트림에 '\n'을 쓰는 것은 Windows 시스템에서는 제대로 작동하지만 Unix에서는 LF만 생산하고, 좀 더 이색적인 시스템에서는 전혀 다른 무언가를 생산한다.바이너리 모드에서 "\r\n"을 사용하는 것이 약간 낫다.

C++, Perl,[18] Haskell과 같은 많은 언어들은 C와 같은 '\n'의 해석을 제공한다.C++에는 조작기 std::endl을 사용하여 뉴라인을 출력(그리고 스트림 버퍼를 플러시)할 수 있는 대체 I/O 모델이 있다.

Java, PHP,[19] Python[20] '\r\n' 시퀀스를 제공한다(ASCII CR+LF의 경우).C와 대조적으로 이것들은 각각 U+000DU+000A 값을 나타낼 수 있도록 보장된다.

Java I/O 라이브러리는 입력 또는 출력 시 플랫폼에 의존하는 뉴라인 시퀀스로 투명하게 변환하지 않는다.대신 기본 뉴라인 시퀀스를 자동으로 추가하는 풀라인 작성 기능과 CR, LF 또는 CR+LF 중 하나를 라인 터미네이터로 받아들이는 라인 읽기 기능을 제공한다(BufferedReader.readLine() 참조).System.lineSeparator() 방법을 사용하여 기본 라인 분리기를 검색할 수 있다.

예:

     = 시스템.라인분리기();     라인컬러 = "컬러: 레드" + ; 

Python은 읽기 위해 파일을 열 때, 모듈을 가져올 때, 파일을 실행할 때 "Universal Newline Support"를 허용한다.[21]

일부 언어는 프로그램 실행 중 새로운 선을 용이하게 하기 위해 특별한 변수, 상수서브루틴을 만들었다.PHPPerl과 같은 일부 언어에서는 '\n''\r'을 포함한 모든 탈출 시퀀스에 대해 탈출 대체를 수행하려면 큰따옴표가 필요하다.PHP에서는 휴대성 문제를 피하기 위해 PHP_를 사용하여 뉴라인 시퀀스를 발행해야 한다.EOL 상수.[22]

C#의 예:

   끈을 매다  = 환경.뉴라인;    끈을 매다 라인컬러 = "컬러: 레드" + ;        끈을 매다 eol2 = "\n";    끈을 매다 라인컬러2 = "컬러: 블루" + eol2; 

다른 뉴라인 형식 문제

gedit로 만들고 16진수 편집기로 보는 텍스트 파일.텍스트 개체 외에도 16진수 값이 0A인 EOL 마커만 있다.

다른 뉴라인 규약은 다른 유형의 시스템 간에 전송된 텍스트 파일을 잘못 표시하게 한다.

Unix 유사 또는 클래식한 Mac OS에서 공통적으로 사용되는 프로그램으로 만든 파일의 텍스트는 MS-DOSMicrosoft Windows에서 공통적으로 사용되는 대부분의 프로그램에서 하나의 긴 줄로 표시되며, 이는 단일 줄에 표시되지 않기 때문이다.line feed또는 싱글carriage return줄 바꿈으로

반대로 유닉스 유사 시스템의 Windows 컴퓨터에서 생성된 파일을 볼 때, 추가 CR은 두 번째 줄 바꿈, ^M 또는 각 줄 끝의 <cr>로 표시될 수 있다.

또한 텍스트 편집기를 제외한 프로그램은 외부 뉴라인 규칙을 사용하여 인코딩된 파일(예: 일부 구성 파일)을 유효한 파일로 받아들일 수 없다.

어떤 프로그램들은 외국 뉴스라인을 제대로 다루지만 다른 프로그램들은 그렇지 않기 때문에 이 문제는 발견하기 어려울 수 있다.예를 들어 콘솔이나 편집기에 표시될 때 소스 파일이 올바르게 표시되더라도 컴파일러는 모호한 구문 오류로 인해 실패할 수 있다.현대의 텍스트 편집기는 일반적으로 CR+LF의 모든 맛을 인식하고 사용자가 다른 표준들 사이에서 변환할 수 있도록 한다.웹 브라우저는 또한 보통 텍스트 파일과 다른 종류의 새로운 선을 사용하는 웹사이트를 표시할 수 있다.

프로그램이 다른 뉴라인 규약을 지원하더라도, 이러한 특징들은 종종 충분히 라벨이 붙거나 설명되거나 문서화되지 않는다.일반적으로 다른 뉴라인 규칙을 열거한 메뉴 또는 콤보 박스는 선택 항목이 새로운 라인을 다시 해석할지, 일시적으로 변환할지 또는 영구적으로 변환할지를 표시하지 않고 사용자에게 표시된다.일부 프로그램은 열린 상태, 복사, 붙여넣기 또는 저장 상태로 암묵적으로 변환된다.

대부분의 텍스트 인터넷 프로토콜(HTTP, SMTP, FTP, IRC 및 기타 다수 포함)은 프로토콜 레벨에서 ASCII CR+LF('\r\n', 0x0D 0x0A')의 사용을 의무화하지만, 관용적인 애플리케이션도 LF('\n', 0x0A)를 인식할 것을 권고한다.명령된 표준에도 불구하고 많은 애플리케이션은 캐리지 리턴 이스케이프 및 뉴라인 이스케이프 시퀀스 '\r\n'(CR+LF)의 올바른 조합 대신 C 뉴라인 이스케이프 시퀀스 '\n'(LF)을 잘못 사용한다(위 프로그래밍 언어의 섹션 Newline 참조).이러한 잘못된 탈출 시퀀스의 우발적인 사용은 제안된 내성적 해석 대신 표준의 보다 엄격한 해석에 따르는 시스템과 의사소통을 시도할 때 문제를 야기한다.그러한 편협한 시스템 중 하나는 필요한 CR+LF 대신 맨 LF를 보내는 시스템의 메시지를 적극적으로 거부하는 Qmail mail transfer 에이전트다.[23]

전자 메일의 표준 인터넷 메시지[24] 형식에는 "CR과 LF는 함께 CRLF로만 발생해야 하며, 본문에 독립적으로 나타나지 않아야 한다"라고 명시되어 있다.

파일 전송 프로토콜은 전송이 "ASCII 모드"에서 수행될 때, 서로 다른 뉴라인 표현을 가진 시스템 간에 전송되는 파일의 새로운 줄을 자동으로 변환할 수 있다.그러나, 이 모드에서 이진 파일을 전송하는 것은 보통 재앙적인 결과를 낳는다. 즉, 이 맥락에서 라인 터미네이터 의미론적 요소가 없지만, 정상적인 바이트 순서의 일부에 불과한 뉴라인 바이트 시퀀스의 발생은 다른 시스템이 사용하는 뉴라인 표현으로 변환되어 파일을 효과적으로 손상시킨다.FTP 클라이언트는 종종 바이너리 모드나 ASCII 모드를 자동으로 선택하기 위해 일부 휴리스틱스(예: 파일 이름 확장명 검사)를 채택하지만, 결국 자신의 파일이 올바른 모드로 전송되는지 확인하는 것은 사용자의 몫이다.올바른 모드에 대해 의문이 있을 경우, 파일이 잘못 표시될 수 있지만 FTP에 의해 변경되지 않으므로 이진 모드를 사용해야 한다.[25]

뉴라인 형식 간 변환

텍스트 편집기는 텍스트 파일을 다른 뉴라인 형식으로 변환하는 데 종종 사용된다. 대부분의 현대 편집자는 적어도 다른 ASCII CR/LF 규칙을 사용하여 파일을 읽고 쓸 수 있다.

예를 들어, 편집자 Vim은 Windows 메모장 텍스트 편집기와 호환되는 파일을 만들 수 있다.vim 안

 :set fileformat=dos :wq

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

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

다른 뉴라인 규약들 사이에서 파일을 변환하기 위한 특수 목적 프로그램에는 unix2dos와 dos2unix, mac2unixunix2mac, mac2dosdos2mac, 플립 등이 있다.[26]tr 명령은 거의 모든 Unix 유사 시스템에서 사용할 수 있으며 단일 문자로 임의 대체 작업을 수행하는 데 사용할 수 있다.DOS/Windows 텍스트 파일은 ASCII CR 문자를 모두 제거하기만 하면 Unix 형식으로 변환할 수 있다.

$ tr -d '\r' < 입력파일 > 출력파일

또는 텍스트에 CR 새 줄만 있는 경우 모든 CR 새 줄을 LF로 변환하여

$ tr '\r' '\n' < 입력 파일 > 출력 파일

플랫폼에 Perl 통역기가 있는 경우, 동일한 작업을 awk, sed 또는 Perl에서 수행하기도 한다.

도스(리눅스와 BSD기반 OS을 가지지 않GNU확장 프로그램에 관하CRs 추가)달러 이상 '{sub("달러","\r\n"), printf("%s",$ 0).}의inputfile>outputfile#유닉스달러 이상 '{gsub("\r",""), 인쇄합니다;}의inputfile>outputfile#DOS와 유닉스(리눅스와 BSD기반 OS에 끼치는 아니GNU확장 CRs 제거)달러 sed-e's/$ /\r/의inputfile>outputfi.르# UNIX to DOS(GNU 확장을 사용하는 Linux 기반 OS에 CR 추가) $s -e 's/\r$/' 입력파일 > 출력파일 # DOS (GNU 확장을 사용하는 Linux 기반 OS에 CR 제거) $perl -pe's/\r?\n \r/\r\n/g' 입력파일 > 출력파일 # DOS$ perl -pe 's/\r?\n \r/\n/g' 입력파일 > 출력파일 # UNIX$ perl -pe's/\r변환?\n \r/\r/g' 입력 파일 > 출력 파일 # 이전 Mac으로 변환

파일 명령은 다음 줄 끝의 유형을 식별할 수 있다.

 $my file.txt my filetxt: ASCII 영어 텍스트, CRLF 줄 마침표 포함

Unix egrep(확장 grep) 명령은 Unix 또는 DOS 파일의 파일 이름을 인쇄하는 데 사용할 수 있다(유닉스 및 DOS 스타일 파일만 가정하고, 클래식한 Mac OS 스타일 파일은 제외).

$ egrep -L '\r\n' my file.txt # show UNIX style file(LF 종료됨) $ egrep -l '\r\n' my file.txt # show DOS 스타일 파일(CRLF 종료)

사용자가 EOL 문자를 시각화할 수 있는 다른 도구:

$ OD - my file.txt $cat -e my file.txt $cat -v my file.txt $6xdump -c myfile.txt

해석

둘 다 일관성이 있는 새로운 선을 보는 두 가지 방법은 새로운 선이 별도의 회선 또는 회선을 종료하는 것이다.뉴라인이 구분자로 간주되면 파일의 마지막 줄 뒤에 뉴라인이 없다.일부 프로그램은 파일의 마지막 줄이 새 줄로 종료되지 않으면 처리하는데 문제가 있다.반면 뉴라인이 분리막으로 사용될 것으로 예상하는 프로그램들은 최종 뉴라인이 새로운 (빈)라인이 시작되는 것으로 해석할 것이다.반대로, 뉴라인이 터미네이터로 간주되는 경우, 마지막을 포함한 모든 텍스트 라인은 뉴라인에 의해 종료될 것으로 예상된다.텍스트 파일의 마지막 문자열이 새로운 줄이 아닌 경우, 파일의 마지막 줄은 부적절하거나 불완전한 텍스트 라인으로 간주되거나 파일이 잘못 잘린 것으로 간주될 수 있다.

주로 워드 랩 기능을 구현하는 소프트웨어를 사용하여 인간이 읽도록 의도된 텍스트에서, 새로운 줄 문자는 일반적으로 다음 단어가 단락 사이와 수직 목록과 같이 같은 줄에 맞는지 여부에 관계 없이 줄 바꿈이 필요한 경우에만 저장하면 된다.따라서 워드 프로세싱의 논리와 대부분의 텍스트 편집기의 논리에서 뉴라인은 단락 휴식처로 사용되며, 워드 래핑을 구현하기 위해 동적으로 생성되어 각 디스플레이 인스턴스에서 변경할 수 있는 "소프트 리턴"과는 대조적으로 "하드 리턴"으로 알려져 있다.많은 응용 프로그램에서 "수동 줄 바꿈"이라고 불리는 별도의 제어 문자는 단일 문단 내에서 줄 바꿈을 강제하기 위해 존재한다.하드 리턴에 대한 제어 문자의 글리프는 대개 필로크()이고 수동 라인 브레이크의 경우 일반적으로 캐리지 리턴 화살표(↵)이다.

리버스 라인 및 부분 라인 피드

RI, (U+008D REVERSE LINE FEED,[27] ISO/IEC 6429 8D, 10진수 141)을 사용하여 인쇄 위치를 한 줄 뒤로 이동(용지를 역 공급하거나 디스플레이 커서를 한 줄 위로 이동)하여 기존 텍스트 위에 다른 문자를 인쇄할 수 있다.이것은 그것들을 더 대담하게 만들거나 밑줄, 스트라이크 스루 또는 분음부 같은 다른 문자를 추가하기 위해 수행될 수 있다.

마찬가지로 PLD(U+008B 부분선 FORWARD, 10진수 139)와 PLU(U+008C 부분선 후진, 10진수 140)를 사용하여 텍스트 인쇄 위치를 수직선 간격의 일부(일반적으로 절반)만큼 앞당기거나 반전시킬 수 있다.이것들은 첨자(진행 후 역진)와 위첨자(후진 후 역진)에 함께 사용될 수 있으며, 분음계 인쇄에도 유용할 수 있다.

참고 항목

참조

  1. ^ "What is a Newline?". www.computerhope.com. Retrieved 10 May 2021.
  2. ^ Qualline, Steve (2001). Vi Improved - Vim (PDF). Sams. p. 120. ISBN 9780735710016.
  3. ^ "ASCII Chart".
  4. ^ Bray, Andrew C.; Dickens, Adrian C.; Holmes, Mark A. (1983). The Advanced User Guide for the BBC Microcomputer (PDF). pp. 103, 104. ISBN 978-0946827008. Retrieved 30 January 2019.
  5. ^ "RISC OS 3 Programmers' Reference Manual". Retrieved 18 July 2018.
  6. ^ IBM System/360 참조 데이터 카드, 간행물 GX20-1703, IBM 데이터 처리 부서, White Plains, NY
  7. ^ "UAX #14: Unicode Line Breaking Algorithm". www.unicode.org.
  8. ^ "C1 Control Character Set of ISO 6429" (PDF). ITSCJ. IPSJ. 1 October 1983. Retrieved 3 March 2022.
  9. ^ Control Functions for Coded Character Sets (PDF) (Report). ECMA International. June 1991.
  10. ^ Character Code Structure and Extension Techniques (PDF) (Report) (6th ed.). ECMA International. December 1994.
  11. ^ "ECMAScript 2019 Language Specification". ECMA International. June 2019. 11.3 Line Terminators.
  12. ^ "ECMAScript 2019 Language Specification". ECMA International. June 2019. 11.2 White Space.
  13. ^ Bray, Tim (March 2014). "The JavaScript Object Notation (JSON) Data Interchange Format". 7. Strings. RFC 7159. {{cite journal}}:Cite 저널은 필요로 한다. journal=(도움말)
  14. ^ "Subsume JSON (a.k.a. JSON ⊂ ECMAScript)". GitHub. 22 May 2018.
  15. ^ "ECMAScript 2019 Language Specification". ECMA International. June 2019. 11.8.4 String Literals.
  16. ^ "ECMAScript 2018 Language Specification". ECMA International. June 2018. 11.8.4 String Literals.
  17. ^ "YAML Ain't Markup Language (YAML) Version 1.2". yaml.org. 5.4. Line Break Characters.
  18. ^ "binmode - perldoc.perl.org". perldoc.perl.org.
  19. ^ "PHP: Strings - Manual". www.php.net.
  20. ^ "Lexical analysis – Python v3.0.1 documentation". docs.python.org.
  21. ^ "What's new in Python 2.3".
  22. ^ "PHP: Predefined Constants - Manual". www.php.net.
  23. ^ "cr.yp.to".
  24. ^ Resnick, Pete (April 2001). "RFC 2822 - Internet Message Format". The Internet Engineering Task Force.
  25. ^ "File Transfer". When in doubt, transfer in binary mode.
  26. ^ "ASCII text conversion between UNIX, Macintosh, MS-DOS". Archived from the original on 9 February 2009.
  27. ^ "C1 Controls and Latin-1 Supplement" (PDF). unicode.org. Retrieved 13 February 2016.

외부 링크