View source for Newline

You do not have permission to edit this page, for the following reasons:

This IP address has been blocked from editing Wikipedia.
This does not affect your ability to read Wikipedia pages.
Most people who see this message have done nothing wrong. Some kinds of blocks restrict editing from specific service providers or telecom companies in response to recent abuse or vandalism, and can sometimes affect other users who are unrelated to that abuse. Review the information below for assistance if you do not believe that you have done anything wrong.

The IP address or range 3.234.0.0/16 has been blocked by ‪ST47‬ for the following reason(s):

The IP address that you are currently using has been blocked because it is believed to be a web host provider. To prevent abuse, web hosts may be blocked from editing Wikipedia.
You will not be able to edit Wikipedia using a web host provider because it hides your IP address, much like a proxy or VPN.
We recommend that you attempt to use another connection to edit. For example, if you use a proxy or VPN to connect to the internet, turn it off when editing Wikipedia. If you edit using a mobile connection, try using a Wi-Fi connection, and vice versa. If you are using a corporate internet connection, switch to a different Wi-Fi network. If you have a Wikipedia account, please log in.
If you do not have any other way to edit Wikipedia, you will need to request an IP block exemption.

How to appeal if you are confident that your connection does not use a web host's IP address:
If you are confident that you are not using a web host, you may appeal this block by adding the following text on your talk page: {{unblock|reason=Caught by a web host block but this host or IP is not a web host. My IP address is _______. Place any further information here. ~~~~}}. You must fill in the blank with your IP address for this block to be investigated. Your IP address can be determined here. Alternatively, if you wish to keep your IP address private you can use the unblock ticket request system. There are several reasons you might be editing using the IP address of a web host (such as if you are using VPN software or a business network); please use this method of appeal only if you think your IP address is in fact not a web host.

Administrators: The IP block exemption user right should only be applied to allow users to edit using web host in exceptional circumstances, and they should usually be directed to the functionaries team via email. If you intend to give the IPBE user right, a CheckUser needs to take a look at the account. This can be requested most easily at SPI Quick Checkuser Requests. Unblocking an IP or IP range with this template is highly discouraged without at least contacting the blocking administrator.

This block will expire on 21:48, 22 February 2026. Your current IP address is 3.234.183.118.

Even when blocked, you will usually still be able to edit your user talk page, as well as email administrators and other editors.

For information on how to proceed, please read the FAQ for blocked users and the guideline on block appeals. The guide to appealing blocks may also be helpful.

Other useful links: Blocking policy · Help:I have been blocked
This IP address range has been globally blocked.
This does not affect your ability to read Wikipedia pages.
Most people who see this message have done nothing wrong. Some kinds of blocks restrict editing from specific service providers or telecom companies in response to recent abuse or vandalism, and can sometimes affect other users who are unrelated to that abuse. Review the information below for assistance if you do not believe that you have done anything wrong.

This block affects editing on all Wikimedia wikis.
The IP address or range 3.234.0.0/16 has been globally blocked by ‪Jon Kolbert‬ for the following reason(s):

Open proxy/Webhost: See the help page if you are affected

This block will expire on 05:35, 21 February 2029. Your current IP address is 3.234.183.118.

Even while globally blocked, you will usually still be able to edit pages on Meta-Wiki.

If you believe you were blocked by mistake, you can find additional information and instructions in the No open proxies global policy. Otherwise, to discuss the block please post a request for review on Meta-Wiki. You could also send an email to the stewards VRT queue at stewards@wikimedia.org including all above details.

Other useful links: Global blocks · Help:I have been blocked

You can view and copy the source of this page:

{{short description|Special characters in computing signifying the end of a line of text}}
{{Other uses|New Line (disambiguation)}}
{{redirect|Endl|the botanist|Stephan Endlicher}}
{{Use dmy dates|date=November 2020}}
{{more citations needed|date=February 2016}}

[[File:Illustration of a newline.png|thumb|Newline inserted between the words "Hello" and "world"]]
A '''newline''' (frequently called '''line ending''', '''end of line''' ('''EOL'''), '''next line''' ('''NEL''') or '''line break''') is a [[control character]] or sequence of control characters in [[character encoding]] specifications such as [[ASCII]], [[EBCDIC]], [[Unicode]], etc. This character, or a sequence of characters, is used to signify the end of a [[line (text file)|line of text]] and the start of a new one.<ref>{{Cite web|title=What is a Newline?|url=https://www.computerhope.com/jargon/n/newline.htm|access-date=2021-05-10|website=www.computerhope.com|language=en}}</ref>

== History ==
In the mid-1800s, long before the advent of [[teleprinter]]s and teletype machines, [[Morse code]] operators or [[telegraphist]]s invented and used [[Prosigns for Morse code|Morse code prosigns]] to encode white space text formatting in formal written text messages. In particular, the [[International Morse code|Morse]] prosign '''{{overline|BT}}''' (mnemonic break text), represented by the concatenation of literal textual Morse codes "B" and "T" characters, sent without the normal inter-character spacing, is used in Morse code to encode and indicate a ''new line'' or ''new section'' in a formal text message.<!-- two "A" codes {{overline|AA}} are dubious: They have /always/ been used in "Continental Morse" to represent the character '''Ä''' (which use came before International Morse). Their use in the middle 1900s appears to be unique to [[ARRL]] coding. -->

Later, in the age of modern [[teleprinter]]s, standardized character set control codes were developed to aid in white space text formatting. ASCII was developed simultaneously by the [[International Organization for Standardization]] (ISO) and the American Standards Association (ASA), the latter being the predecessor organization to [[American National Standards Institute]] (ANSI). During the period of 1963 to 1968, the ISO draft standards supported the use of either [[#Representation|{{mono|CR}}+{{mono|LF}}]] or [[#Representation|{{mono|LF}}]] alone as a newline, while the ASA drafts supported only {{mono|CR}}+{{mono|LF}}.

The sequence {{mono|CR}}+{{mono|LF}} was commonly used on many early computer systems that had adopted [[Teletype Corporation|Teletype]] machines—typically a [[Teletype Model 33]] ASR—as a console device, because this sequence was required to position those printers at the start of a new line. The separation of newline into two functions concealed the fact that the print head could not return from the far right to the beginning of the next line in time to print the next character. Any character printed after a {{mono|CR}} would often print as a smudge in the middle of the page while the print head was still moving the carriage back to the first position. "The solution was to make the newline two characters: {{mono|CR}} to move the carriage to column one, and {{mono|LF}} to move the paper up."<ref>{{cite book |last=Qualline |first=Steve |title=Vi Improved - Vim |year=2001 <!-- PDF date=1 August 2002 -->|publisher=[[Sams Publishing]] |isbn=9780735710016 |page=[http://ftp.vim.org/pub/vim/doc/book/vimbook-OPL.pdf#page=120 120] |url=http://ftp.vim.org/pub/vim/doc/book/vimbook-OPL.pdf  |access-date=4 January 2023 |archive-date=8 April 2022 |archive-url=https://web.archive.org/web/20220408110814/http://ftp.vim.org/pub/vim/doc/book/vimbook-OPL.pdf}}</ref> In fact, it was often necessary to send [[Output padding|extra padding characters]]—extraneous CRs or NULs—which are ignored but give the print head time to move to the left margin. Many early video displays also required multiple character times to [[Scrolling|scroll]] the display.

On such systems, applications had to talk directly to the Teletype machine and follow its conventions since the concept of [[device driver]]s hiding such hardware details from the application was not yet well developed. Therefore, text was routinely composed to satisfy the needs of Teletype machines. Most minicomputer systems from [[Digital Equipment Corporation|DEC]] used this convention. [[CP/M]] also used it in order to print on the same terminals that minicomputers used. From there [[MS-DOS]] (1981) adopted [[CP/M]]'s {{mono|CR}}+{{mono|LF}} in order to be compatible, and this convention was inherited by Microsoft's later [[Microsoft Windows|Windows]] operating system.

The [[Multics]] operating system began development in 1964 and used {{mono|LF}} alone as its newline. Multics used a device driver to translate this character to whatever sequence a printer needed (including extra [[Output padding|padding characters]]), and the single byte was more convenient for programming. What seems like a more obvious <!-- WP:SKYBLUE --> choice—{{mono|CR}}—was not used, as {{mono|CR}} provided the useful function of overprinting one line with another to create [[Emphasis (typography)|boldface]], [[underscore]] and [[strikethrough]] effects. Perhaps more importantly, the use of {{mono|LF}} alone as a line terminator had already been incorporated into drafts of the eventual [[ISO/IEC 646]] standard. [[Unix]] followed the Multics practice, and later [[Unix-like]] systems followed Unix. This created conflicts between Windows and Unix-like [[operating system]]s, whereby files composed on one operating system could not be properly formatted or interpreted by another operating system (for example a [[UNIX shell script]] written in a Windows text editor like [[Microsoft Notepad|Notepad]]<ref>{{Cite news |title=Windows Notepad finally understands everyone else's end of line characters |url=https://www.zdnet.com/article/windows-notepad-finally-understands-everyone-elses-end-of-line-characters/ |access-date=4 January 2023 |publisher=[[ZDNet]] |language=en|last=Duckett|first=Chris |quote=[A]fter decades of frustration, and having to download a real text editor to change a single line in a config file from a Linux box, Microsoft has updated Notepad to be able to handle end of line characters used in Unix, Linux, and macOS environments.|archive-url=https://web.archive.org/web/20180513055845/https://www.zdnet.com/article/windows-notepad-finally-understands-everyone-elses-end-of-line-characters/|archive-date=13 May 2018}}</ref><ref>{{Cite web |last=Lopez |first=Michel |date=8 May 2018 |title=Introducing extended line endings support in Notepad |url=https://devblogs.microsoft.com/commandline/extended-eol-in-notepad/ |access-date=4 January 2023 |website=Windows Command Line |language=en-US|quote=As with any change to a long-established tool, there’s a chance that this new behavior may not work for your scenarios, or you may prefer to disable this new behavior and return to Notepad’s original behavior. To do this, you can change [...registry keys...] to tweak how Notepad handles pasting of text, and which EOL character to use when Enter/Return is hit|archive-url=https://web.archive.org/web/20190406132933/https://devblogs.microsoft.com/commandline/extended-eol-in-notepad/|archive-date=6 April 2019}}</ref>).

== Representation ==
The concepts of [[carriage return]] (CR) and line feed (LF) are closely associated and can be considered either separately or together. In the physical media of [[typewriter]]s and [[printer (computing)|printer]]s, two [[Cartesian coordinate system|axes]] of motion, "down" and "across", are needed to create a new line on the [[page (paper)|page]]. Although the design of a machine (typewriter or printer) must consider them separately, the abstract logic of software can combine them together as one event. This is why a newline in [[character encoding]] can be defined as {{code|CR}} and {{code|LF}} combined into one (commonly called {{code|CR+LF}} or {{code|CRLF}}).

Some [[character encoding|character sets]] provide a separate newline character code. [[EBCDIC]], for example, provides an {{mono|NL}} character code in addition to the {{mono|CR}} and {{mono|LF}} codes. [[Unicode]], in addition to providing the [[ASCII]] {{mono|CR}} and {{mono|LF}} [[control character|control codes]], also provides a "next line" ({{mono|NEL}}) control code, as well as control codes for "line separator" and "paragraph separator" markers. Unicode also contains printable characters for visually representing line feed ␊, carriage return ␍, and other C0 control codes (as well as a generic newline, ␤) in the [[Unicode control characters#Control Pictures|Control Pictures]] block.

{| class="wikitable plainrowheaders" style="text-align: center;"
|+Software applications and operating system representation of a newline with one or two [[control character]]s
! scope="col"| [[Operating system]]
! scope="col"| [[Character encoding]]
! scope="col"| Abbreviation
! scope="col"| [[hexadecimal|hex]] value
! scope="col"| [[decimal|dec]] value
! scope="col"| [[Escape sequence]]
|-
! scope="row" style="text-align:left;" | [[Multics]]<br />[[POSIX]] standard oriented systems: [[Unix]] and [[Unix-like]] systems ([[Linux]], [[macOS]], [[List of BSD operating systems|*BSD]], [[IBM AIX|AIX]], [[Xenix]], etc.), [[QNX]] 4+<br />Others: [[BeOS]], [[Amiga]], [[RISC OS]]<!-- I thought it used CR, but seems to be contradicted, for later versions only? www.riscos.com/the_archive/rol/productsdb/admin/riscos.htm "RISC OS uses the same end-of-line sequence (i.e. 'LF') as Unix as opposed to Windows and MacOS which use 'CR LF' and 'CR' respectively."
From old docs: www.riscos.com/support/developers/prm/charoutput.html#66036 "CR (ASCII 13) causes a newline to be generated."
-->, and others<ref>{{cite web |last1=Kahn-Greene |first1=Will Guaraldi |title=ASCII chart |url=https://www.bluesock.org/~willg/dev/ascii.html |website=bluesock.org}}</ref>
| rowspan="5" | [[ASCII]]
| {{mono|LF}}
| {{mono|0A}}
| {{mono|10}}
| {{mono|\n}}
|-
! scope="row" style="text-align:left;" | [[Windows]], [[MS-DOS]] compatibles, [[Atari TOS]], [[Digital Equipment Corporation|DEC]] [[TOPS-10]], [[RT-11]], [[CP/M]], [[MP/M]], [[OS/2]], [[Symbian OS]], [[Palm OS]], [[Amstrad CPC]], and most other early non-Unix and non-IBM operating systems
| {{mono|CR LF}}
| {{mono|0D 0A}}
| {{mono|13 10}}
| {{mono|\r\n}}
|-
! scope="row" style="text-align:left;" | [[Commodore 64]], [[Commodore 128]], [[BBC Micro|Acorn BBC]], [[ZX Spectrum]], [[TRS-80]], [[Apple II]], [[Oberon (operating system)|Oberon]], [[classic Mac OS]], [[HP Series 80]], MIT [[Lisp machine|Lisp Machine]], and [[OS-9]]
| {{mono|CR}}
| {{mono|0D}}
| {{mono|13}}
| {{mono|\r}}
|-
! scope="row" style="text-align:left;" | [[BBC Micro|Acorn BBC]]<ref>{{cite book |last1=Bray |first1=Andrew C. |last2=Dickens |first2=Adrian C. |last3=Holmes |first3=Mark A. |title=The Advanced User Guide for the BBC Microcomputer |year=1983 |isbn=978-0946827008 |pages=103, 104 |publisher=Cambridge Microcomputer Centre |url=http://stardot.org.uk/mirrors/www.bbcdocs.com/filebase/essentials/BBC%20Microcomputer%20Advanced%20User%20Guide.pdf |access-date=30 January 2019}}</ref> and [[RISC OS]] spooled text output<ref>{{cite web |work=RISC OS 3 Programmers' Reference Manual |title=Character Output |url=http://www.riscos.com/support/developers/prm/charoutput.html#66036 |publisher=3QD Developments Ltd |date=3 November 2015 |access-date=18 July 2018}}</ref>
| {{mono|LF CR}}
| {{mono|0A 0D}}
| {{mono|10 13}}
| {{mono|\n\r}}
|- 
! scope="row" style="text-align:left;" | [[QNX]] pre-POSIX implementation (version < 4)
| {{mono|[[Record Separator|RS]]}}
| {{mono|1E}}
| {{mono|30}}
| {{mono|\036}}
|-
! scope="row" style="text-align:left;" | [[Atari 8-bit computers]] 
| rowspan="1" |  [[ATASCII]]
| {{mono|EOL}}
| {{mono|9B}}
| {{mono|155}}
| 
|-
! scope="row" style="text-align:left;" | [[IBM]] mainframe systems, including [[z/OS]] ([[OS/390]]) and [[IBM i]] ([[OS/400]])
| [[EBCDIC]]
| {{mono|NL}}
| {{mono|15}}
| {{mono|21}}
| {{mono|\025}}
|-
! scope="row" style="text-align:left;" | [[ZX80]] and [[ZX81]] (home computers from [[Sinclair Research|Sinclair Research Ltd]])
| [[ZX80 character set|ZX80]]/[[ZX81 character set|ZX81]] proprietary encoding
| 
| {{mono|76}}
| {{mono|118}}
| 
|}

*[[EBCDIC]] systems—mainly [[IBM]] mainframe systems, including [[z/OS]] ([[OS/390]]) and [[IBM i]] ([[OS/400]])—use {{mono|NL}} (New Line, {{mono|0x15}})<ref>IBM System/360 Reference Data Card, Publication GX20-1703, IBM Data Processing Division, White Plains, NY</ref> as the character combining the functions of line feed and carriage return. The equivalent Unicode character ({{code|0x85}}) is called {{mono|NEL}} (Next Line). EBCDIC also has control characters called {{mono|CR}} and {{mono|LF}}, but the numerical value of {{mono|LF}} ({{mono|0x25}}) differs from the one used by ASCII ({{mono|0x0A}}). Additionally, some EBCDIC variants also use {{mono|NL}} but assign a different numeric code to the character. However, those operating systems use a [[Record-oriented filesystem|record-based file system]], which stores text files as one record per line. In most file formats, no line terminators are actually stored.
*Operating systems for the [[CDC 6000 series]] defined a newline as two or more zero-valued six-bit characters at the end of a 60-bit word. Some configurations also defined a zero-valued character as a [[colon (punctuation)|colon]] character, with the result that multiple colons could be interpreted as a newline depending on position.
*[[RSX-11]] and [[OpenVMS]] also use a record-based file system, which stores text files as one record per line. In most file formats, no line terminators are actually stored, but the [[Record Management Services]] facility can transparently add a terminator to each line when it is retrieved by an application. The records themselves can contain the same line terminator characters, which can either be considered a feature or a nuisance depending on the application. RMS not only stores records, but also stores metadata about the record separators in different bits for the file to complicate matters even more (since files can have fixed length records, records that are prefixed by a count or records that are terminated by a specific character). The bits are not generic, so while they can specify that {{mono|CR}}{{mono|LF}} or {{mono|LF}} or even {{mono|CR}} is the line terminator, they can not substitute some other code.
*''Fixed line length'' was used by some early [[mainframe computer|mainframe]] operating systems. In such a system, an implicit end-of-line was assumed every 72 or 80 characters, for example. No newline character was stored. If a file was imported from the outside world, lines shorter than the line length had to be padded with spaces, while lines longer than the line length had to be truncated. This mimicked the use of [[punched card]]s, on which each line was stored on a separate card, usually with 80 columns on each card, often with sequence numbers in columns 73–80. Many of these systems added a [[ASA carriage control characters|carriage control character]] to the start of the ''next'' record; this could indicate whether the next record was a continuation of the line started by the previous record, or a new line, or should overprint the previous line (similar to a {{mono|CR}}). Often this was a normal printing character such as {{code|#}} that thus could not be used as the first character in a line. Some early line printers interpreted these characters directly in the records sent to them.

=== Communication protocols ===
Many communications protocols have some sort of new line convention. In particular, protocols published by the [[Internet Engineering Task Force]] (IETF) typically use the ASCII CRLF sequence.

In some older protocols, the new line may be followed by a checksum or parity character.

=== Unicode ===
{{redir|Paragraph separator|the symbol also known as a "paragraph sign"|Pilcrow}}
The [[Unicode]] standard defines a number of characters that conforming applications should recognize as line terminators:<ref>{{cite web |last1=Heninger |first1=Andy |title=UAX #14: Unicode Line Breaking Algorithm |url=https://www.unicode.org/reports/tr14/tr14-32.html |publisher=The Unicode Consortium |date=2013-09-20}}</ref>

:{{mono|&nbsp;{{ctrl|LF}}}}:{{mono|&nbsp;&nbsp;&nbsp;}} Line Feed, {{mono|U+000A}}
:{{mono|&nbsp;{{ctrl|VT}}}}:{{mono|&nbsp;&nbsp;&nbsp;}} [[Vertical Tab]], {{mono|U+000B}}
:{{mono|&nbsp;{{ctrl|FF}}}}:{{mono|&nbsp;&nbsp;&nbsp;}} [[Form Feed]], {{mono|U+000C}}
:{{mono|&nbsp;{{ctrl|CR}}}}:{{mono|&nbsp;&nbsp;&nbsp;}} [[Carriage return|Carriage Return]], {{mono|U+000D}}
:{{mono|&nbsp;CR}}+{{mono|LF}}: {{mono|CR}} ({{mono|U+000D}}) followed by {{mono|LF}} ({{mono|U+000A}})
:{{mono|&nbsp;{{ctrl|NEL}}}}:{{mono|&nbsp;&nbsp;}} Next Line, {{mono|U+0085}}
:{{mono|&nbsp;{{ctrl|LS}}}}:{{mono|&nbsp;&nbsp;&nbsp;}} Line Separator, {{mono|U+2028}}
:{{mono|&nbsp;{{ctrl|PS}}}}:{{mono|&nbsp;&nbsp;&nbsp;}} Paragraph Separator, {{mono|U+2029}}

While it may seem overly complicated compared to an approach such as converting all line terminators to a single character (e.g. {{mono|LF}}), because Unicode is designed to preserve all information when converting a text file from any existing encoding to Unicode and back ([[Round-trip format conversion|round-trip integrity]]), Unicode needs to make the same distinctions between line breaks made by other encodings.

For example: {{mono|{{ctrl|NL}}}} is part of [[EBCDIC]], which uses code {{mono|0x15}}; it is normally mapped to Unicode {{mono|NEL}}, {{mono|0x85}}, which is a control character in the [[C0 and C1 control codes|C1 control set]].<ref>{{cite web |title=C1 Control Character Set of ISO 6429 |date=1 October 1983 |publisher=IPSJ |department=ITSCJ |url=https://www.itscj-ipsj.jp/ir/077.pdf |access-date=3 March 2022}}</ref> As such, it is defined by ECMA 48,<ref>{{cite report |title=Control Functions for Coded Character Sets |date=June 1991 |publisher=ECMA International |url=http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-048.pdf}}</ref> and recognized by encodings compliant with [[ISO/IEC 2022]] (which is equivalent to ECMA 35).<ref>{{cite report |title=Character Code Structure and Extension Techniques |edition=6th |date=December 1994 |publisher=ECMA International |url=http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-035.pdf}}</ref> C1 control set is also compatible with [[ISO-8859-1]].{{citation needed|date=October 2011}} The approach taken in the Unicode standard allows round-trip transformation to be information-preserving while still enabling applications to recognize all possible types of line terminators.

Recognizing and using the newline codes greater than {{mono|0x7F}} ({{mono|NEL}}, {{mono|LS}} and {{mono|PS}}) is not often done. They are multiple bytes in [[UTF-8]], and the code for {{mono|NEL}} has been used as the [[ellipsis]] ({{code|…}}) character in [[Windows-1252]]. For instance:
*[[ECMAScript]] accepts {{mono|LS}} and {{mono|PS}} as line breaks,<ref>{{cite web |title=ECMAScript 2019 Language Specification |date=June 2019 |publisher=ECMA International |at=[https://www.ecma-international.org/ecma-262/10.0/#sec-line-terminators 11.3 Line Terminators] |url=https://www.ecma-international.org/ecma-262/10.0/}}</ref> but considers {{mono|U+0085}} ({{mono|NEL}}) [[whitespace character|whitespace]] instead of a line break.<ref>{{cite web |title=ECMAScript 2019 Language Specification |url=https://www.ecma-international.org/ecma-262/10.0/ |at=[https://www.ecma-international.org/ecma-262/10.0/#sec-white-space 11.2 White Space] |publisher= ECMA International |date=June 2019}}</ref>
*[[JSON]]<ref>{{cite IETF |title=The JavaScript Object Notation (JSON) Data Interchange Format |section=7 |sectionname=Strings |rfc=7159 |date=March 2014|last1=Bray |first1=Tim}}</ref> allows {{mono|LS}} and {{mono|PS}} characters within strings, while ECMAScript prior to {{Pslink|ECMAScript|ES2019}}<ref>{{cite web |url=https://github.com/tc39/proposal-json-superset |title=Subsume JSON (a.k.a. JSON ⊂ ECMAScript) |date=22 May 2018 |website=GitHub }}</ref><ref>{{cite web |title=ECMAScript 2019 Language Specification |url=https://www.ecma-international.org/ecma-262/10.0/ |at=[https://www.ecma-international.org/ecma-262/10.0/#sec-literals-string-literals 11.8.4 String Literals] |publisher= ECMA International |date=June 2019}}</ref> treated them as newlines, and therefore illegal syntax.<ref>{{cite web |title=ECMAScript 2018 Language Specification |url=https://www.ecma-international.org/ecma-262/9.0/ |at=[https://www.ecma-international.org/ecma-262/9.0/#sec-literals-string-literals 11.8.4 String Literals] |publisher= ECMA International |date=June 2018}}</ref>
*[[YAML]]<ref>{{cite web |work=YAML Ain't Markup Language revision 1.2.2 |date=2021-10-01 |title=5.4. Line Break Characters |url=https://yaml.org/spec/1.2/spec.html#id2774608}}</ref> no longer recognizes them as line breaks as of version 1.2, in order to be compatible with [[JSON]].
*[[Windows Notepad]], the default [[text editor]] of [[Microsoft Windows]], does not treat any of {{mono|NEL}}, {{mono|LS}}, or {{mono|PS}} as line breaks.
*[[gedit]], the default [[text editor]] of the [[GNOME]] [[desktop environment]], treats {{mono|LS}} and {{mono|PS}}, but not {{mono|NEL}}, as line breaks.

The Unicode special characters {{mono|U+2424}} ({{sc2|SYMBOL FOR NEWLINE}}, {{code|␤}}), {{mono|U+23CE}} ({{sc2|RETURN SYMBOL}}, {{code|⏎}}), {{mono|U+240D}} ({{sc2|SYMBOL FOR CARRIAGE RETURN}}, {{code|␍}}) and {{mono|U+240A}} ({{sc2|SYMBOL FOR LINE FEED}}, {{code|␊}}) are [[glyph]]s intended for presenting a user-visible character to the reader of the document, and are thus not recognized themselves as a newline.

=== In programming languages ===
{{Redir|\n|the similar number notation|\nnn (disambiguation)}}
To facilitate creating [[Porting|portable]] programs, [[programming language]]s provide some abstractions to deal with the different types of newline sequences used in different environments.

The [[C (programming language)|C language]] provides the [[escape sequence]]s {{mono|'\n'}} (newline) and {{mono|'\r'}} (carriage return). However, these are not required to be equivalent to the ASCII {{mono|LF}} and {{mono|CR}} control characters. The C standard only guarantees two traits:
# Each of these escape sequences maps to a unique implementation-defined number that can be stored in one {{mono|char}} value.
# When writing to a file, device node, or socket/fifo in ''text mode'', {{mono|'\n'}} is transparently translated to the native newline sequence used by the system, which may be longer than one character. When reading in text mode, the native newline sequence is translated back to {{mono|'\n'}}. In ''binary mode'', no translation is performed, and the internal representation produced by {{mono|'\n'}} is output directly.

On [[Unix]] [[operating system]] platforms, where C originated, the native newline sequence is ASCII {{mono|LF}} ({{mono|0x0A}}), so {{mono|'\n'}} was simply defined to be that value. With the internal and external representation being identical, the translation performed in text mode is a [[NOP (code)|no-op]], and Unix has no notion of text mode or binary mode. This has caused many programmers who developed their software on Unix systems simply to ignore the distinction completely, resulting in code that is not portable to different platforms.

The C [[Library (computing)|library]] function {{mono|[[fgets]]()}} is best avoided in binary mode because any file not written with the Unix newline convention will be misread. Also, in text mode, any file not written with the system's native newline sequence (such as a file created on a Unix system, then copied to a Windows system) will be misread as well.

Another common problem is the use of {{mono|'\n'}} when communicating using an Internet protocol that mandates the use of ASCII {{mono|CR}}+{{mono|LF}} for ending lines. Writing {{mono|'\n'}} to a text mode stream works correctly on Windows systems, but produces only {{mono|LF}} on Unix, and something completely different on more exotic systems. Using {{mono|"\r\n"}} in binary mode is slightly better.

Many languages, such as [[C++]], [[Perl]],<ref>{{cite web |title=binmode |url=https://perldoc.perl.org/functions/binmode |work=Perl documentation |publisher=Perl 5 Porters}}</ref> and [[Haskell]] provide the same interpretation of {{mono|'\n'}} as C. C++ has an [[Input/output (C++)|alternative input/output (I/O) model]] where the manipulator {{mono|std::endl}} can be used to output a newline (and flushes the stream buffer).

[[Java (programming language)|Java]], [[PHP]],<ref>{{cite web |title=PHP: Strings - Manual |url=https://www.php.net/manual/en/language.types.string.php#language.types.string.syntax.double |work=PHP Manual |publisher=The PHP Group}}</ref> and [[Python (programming language)|Python]]<ref>{{cite web |title=2. Lexical analysis |url=https://docs.python.org/3.11/reference/lexical_analysis.html#string-and-bytes-literals |work=The Python Language Reference |publisher=The Python Foundation}}</ref> provide the {{mono|'\r\n'}} sequence (for ASCII {{mono|CR}}+{{mono|LF}}). In contrast to C, these are guaranteed to represent the values {{mono|U+000D}} and {{mono|U+000A}}, respectively.

The Java [[input/output]] (I/O) libraries do not transparently translate these into platform-dependent newline sequences on input or output. Instead, they provide functions for writing a full line that automatically add the native newline sequence, and functions for reading lines that accept any of {{mono|CR}}, {{mono|LF}}, or {{mono|CR}}+{{mono|LF}} as a line terminator (see [http://download.oracle.com/javase/6/docs/api/java/io/BufferedReader.html#readLine%28%29 {{mono|BufferedReader.readLine()}}]). The {{mono|[http://docs.oracle.com/javase/8/docs/api/java/lang/System.html#lineSeparator-- System.lineSeparator()]}} method can be used to retrieve the underlying line separator.

Example:
<syntaxhighlight lang="java">
   String eol = System.lineSeparator();
   String lineColor = "Color: Red" + eol;
</syntaxhighlight>

Python permits "Universal Newline Support" when opening a file for reading, when importing modules, and when executing a file.<ref>{{cite web |title=What's new in Python 2.3 |url=https://www.python.org/download/releases/2.3/highlights/ |publisher=Python Software Foundation}}</ref>

Some languages have created special [[variable (computer science)|variables]], [[constant (computer programming)|constants]], and [[subroutine]]s to facilitate newlines during program execution. In some languages such as [[PHP]] and [[Perl]], [[double quotes]] are required to perform escape substitution for all escape sequences, including {{mono|'\n'}} and {{mono|'\r'}}. In PHP, to avoid portability problems, newline sequences should be issued using the PHP_EOL constant.<ref>{{cite web |title=PHP: Predefined Constants - Manual |url=https://www.php.net/manual/en/reserved.constants.php |work=PHP Manual |publisher=The PHP Group}}</ref>

Example in [[C Sharp (programming language)|C#]]:
<syntaxhighlight lang="C#">
   string eol = Environment.NewLine;
   string lineColor = "Color: Red" + eol;
   
   string eol2 = "\n";
   string lineColor2 = "Color: Blue" + eol2;
</syntaxhighlight>

=== Issues with different newline formats ===
[[File:Newline hex 0A.png|thumb|300px|A [[text file]] created with [[gedit]] and viewed with a [[hex editor]]. Besides the text objects, there are only EOL markers with the [[hexadecimal]] value 0A.]]
The different newline conventions cause text files that have been transferred between systems of different types to be displayed incorrectly.

Text in files created with programs which are common on [[Unix-like]] or [[classic Mac OS]], appear as a single long line on most programs common to [[MS-DOS]] and [[Microsoft Windows]] because these do not display a single {{code|line feed}} or a single {{code|carriage return}} as a line break.

Conversely, when viewing a file originating from a Windows computer on a Unix-like system, the extra {{mono|CR}} may be displayed as a second line break, as {{mono|^M}}, or as {{mono|<cr>}} at the end of each line.

Furthermore, programs other than text editors may not accept a file, e.g. some configuration file, encoded using the foreign newline convention, as a valid file.

The problem can be hard to spot because some programs handle the foreign newlines properly while others do not. For example, a [[compiler]] may fail with obscure syntax errors even though the source file looks correct when displayed on the [[command-line interface|console]] or in an [[Text editor|editor]]. Modern text editors generally recognize all flavours of {{mono|CR}}+{{mono|LF}} newlines and allow users to convert between the different standards. [[Web browser]]s are usually also capable of displaying text files and websites which use different types of newlines.

Even if a program supports different newline conventions, these features are often not sufficiently labeled, described, or documented. Typically a menu or combo-box enumerating different newline conventions will be displayed to users without an indication if the selection will re-interpret, temporarily convert, or permanently convert the newlines. Some programs will implicitly convert on open, copy, paste, or save—often inconsistently.

Most textual [[Internet]] [[protocol (computing)|protocols]] (including [[HTTP]], [[Simple Mail Transfer Protocol|SMTP]], [[File Transfer Protocol|FTP]], [[Internet Relay Chat|IRC]], and many others) mandate the use of ASCII {{mono|CR}}+{{mono|LF}} ({{mono|'\r\n'}}, {{mono|0x0D 0x0A}}) on the protocol level, but recommend that tolerant applications recognize lone {{mono|LF}} ({{mono|'\n'}}, {{mono|0x0A}}) as well. Despite the dictated standard, many applications erroneously use the [[C (programming language)|C]] newline escape sequence {{mono|'\n'}} ({{mono|LF}}) instead of the correct combination of carriage return escape and newline escape sequences {{mono|'\r\n'}} ({{mono|CR}}+{{mono|LF}}) (see section [[#In programming languages|Newline in programming languages]] above). This accidental use of the wrong escape sequences leads to problems when trying to communicate with systems adhering to the stricter interpretation of the standards instead of the suggested tolerant interpretation. One such intolerant system is the [[qmail]] [[mail transfer agent]] that actively refuses to accept messages from systems that send bare {{mono|LF}} instead of the required {{mono|CR}}+{{mono|LF}}.<ref>{{cite web |last1=Bernstein |first1=D. J. |author-link=Daniel J. Bernstein |title=Bare LFs in SMTP |url=https://cr.yp.to/docs/smtplf.html}}</ref>

The standard Internet Message Format<ref>{{cite IETF|rfc=2822|title=Internet Message Format|url=https://tools.ietf.org/html/rfc2822|date=April 2001|last1=Resnick|first1=Pete}}</ref> for email states: "CR and LF MUST only occur together as CRLF; they MUST NOT appear independently in the body". Differences between SMTP implementations in how they treat bare LF and/or bare CR characters have led to SMTP spoofing attacks referred to as "SMTP smuggling".<ref>{{cite web |last1=Longin |first1=Timo |title=SMTP Smuggling - Spoofing E-Mails Worldwide |url=https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/ |website=SEC Consult |date=18 December 2023}}</ref>

The [[File Transfer Protocol]] can automatically convert newlines in files being transferred between [[operating system|systems]] with different newline representations when the transfer is done in "ASCII mode". However, transferring binary files in this mode usually has disastrous results: any occurrence of the newline byte sequence—which does not have line terminator semantics in this context, but is just part of a normal sequence of bytes—will be translated to whatever newline representation the other system uses, effectively [[data corruption|corrupting]] the file. FTP clients often employ some [[heuristic (computer science)|heuristic]]s (for example, inspection of [[filename extension]]s) to automatically select either binary or ASCII mode, but in the end it is up to users to make sure their files are transferred in the correct mode. If there is any doubt as to the correct mode, binary mode should be used, as then no files will be altered by FTP, though they may display incorrectly.<ref>{{cite web |last1=Zeil |first1=Steven |title=File Transfer |url=https://www.cs.odu.edu/~zeil/cs252/s15/Public/ftp/ |publisher=Old Dominion University |archive-url=https://web.archive.org/web/20160514130116/https://www.cs.odu.edu/~zeil/cs252/s15/Public/ftp/ |archive-date=14 May 2016 |url-status=dead |date=19 January 2015 |quote=When in doubt, transfer in binary mode.}}</ref>

=== Conversion between newline formats ===
[[Text editor]]s are often used for converting a text file between different newline formats; most modern editors can read and write files using at least the different ASCII {{mono|CR}}/{{mono|LF}} conventions.

For example, the editor [[Vim (text editor)|Vim]] can make a file compatible with the Windows Notepad text editor. Within vim
<syntaxhighlight lang="vim">
 :set fileformat=dos
 :wq
</syntaxhighlight>
Editors can be unsuitable for converting larger files or bulk conversion of many files. For larger files (on Windows NT) the following command is often used:
<syntaxhighlight lang="doscon">
D:\>TYPE unix_file | FIND /V "" > dos_file
</syntaxhighlight>
Special purpose programs to convert files between different newline conventions include [[unix2dos|{{mono|unix2dos}} and {{mono|dos2unix}}]], {{mono|mac2unix}} and {{mono|unix2mac}}, {{mono|mac2dos}} and {{mono|dos2mac}}, and {{mono|flip}}.<ref>{{cite web |last1=Sapp |first1=Craig Stuart |title=ASCII text converstion between UNIX, Macintosh, MS-DOS |url=http://ccrma-www.stanford.edu/~craig/utility/flip/ |publisher=Center for Computer Research in Music and Acoustics |archive-url=https://web.archive.org/web/20090209015201/http://ccrma-www.stanford.edu/~craig/utility/flip/ |archive-date=9 February 2009}}</ref>
The {{mono|[[tr (Unix)|tr]]}} command is available on virtually every [[Unix-like]] system and can be used to perform arbitrary replacement operations on single characters. A DOS/Windows text file can be converted to Unix format by simply removing all ASCII {{mono|CR}} characters with
 $ [[tr (Unix)|tr]] -d '\r' &lt; ''inputfile'' &gt; ''outputfile''
or, if the text has only {{mono|CR}} newlines, by converting all {{mono|CR}} newlines to {{mono|LF}} with
 $ [[tr (Unix)|tr]] '\r' '\n' &lt; ''inputfile'' &gt; ''outputfile''

The same tasks are sometimes performed with [[awk]], [[sed]], or in [[Perl]] if the platform has a Perl interpreter:
<syntaxhighlight lang="console">
$ awk '{sub("$","\r\n"); printf("%s",$0);}' inputfile > outputfile  # UNIX to DOS  (adding CRs on Linux and BSD based OS that haven't GNU extensions)
$ awk '{gsub("\r",""); print;}' inputfile > outputfile              # DOS to UNIX  (removing CRs on Linux and BSD based OS that haven't GNU extensions)
$ sed -e 's/$/\r/' inputfile > outputfile              # UNIX to DOS  (adding CRs on Linux based OS that use GNU extensions)
$ sed -e 's/\r$//' inputfile > outputfile              # DOS  to UNIX (removing CRs on Linux based OS that use GNU extensions)
$ perl -pe 's/\r?\n|\r/\r\n/g' inputfile > outputfile  # Convert to DOS
$ perl -pe 's/\r?\n|\r/\n/g'   inputfile > outputfile  # Convert to UNIX
$ perl -pe 's/\r?\n|\r/\r/g'   inputfile > outputfile  # Convert to old Mac
</syntaxhighlight>
The {{mono|[[File (command)|file]]}} command can identify the type of line endings:
<syntaxhighlight lang="console">
 $ file myfile.txt
 myfile.txt: ASCII English text, with CRLF line terminators
</syntaxhighlight>
The Unix [[grep#Implementations|egrep]] (extended grep) command can be used to print filenames of Unix or DOS files (assuming Unix and DOS-style files only, no classic Mac OS-style files):
<syntaxhighlight lang="console">
$ egrep -L '\r\n' myfile.txt # show UNIX style file (LF terminated)
$ egrep -l '\r\n' myfile.txt # show DOS style file (CRLF terminated)
</syntaxhighlight>

Other tools permit the user to visualise the EOL characters:
<syntaxhighlight lang="console">
$ od -a myfile.txt
$ cat -e myfile.txt
$ cat -v myfile.txt
$ hexdump -c myfile.txt
</syntaxhighlight>

== Interpretation ==
Two ways to view newlines, both of which are [[self-consistent]], are that newlines either ''separate'' lines or that they ''terminate'' lines. If a newline is considered a separator, there will be no newline after the last line of a file. Some programs have problems processing the last line of a file if it is not terminated by a newline. On the other hand, programs that expect newline to be used as a separator will interpret a final newline as starting a new (empty) line. Conversely, if a newline is considered a terminator, all text lines including the last are expected to be terminated by a newline. If the final character sequence in a text file is not a newline, the final line of the file may be considered to be an improper or incomplete text line, or the file may be considered to be improperly truncated.

In text intended primarily to be read by humans using software which implements the [[word wrap]] feature, a newline character typically only needs to be stored if a line break is required independent of whether the next word would fit on the same line, such as between [[paragraph]]s and in vertical lists. Therefore, in the logic of [[word processor|word processing]] and most [[text editor]]s, newline is used as a ''paragraph break'' and is known as a "hard return", in contrast to "soft returns" which are dynamically created to implement word wrapping and are changeable with each display instance. In many applications a separate [[control character]] called "manual line break" exists for forcing line breaks inside a single paragraph. The [[glyph]] for the control character for a hard return is usually a [[pilcrow]] (¶), and for the manual line break is usually a carriage return arrow (↵).

== Reverse and partial line feeds ==
{{mono|RI}} ([[Unicode|U]]+008D [[line starve|REVERSE LINE FEED]],<ref>{{cite web|url=https://www.unicode.org/charts/PDF/U0080.pdf|title=C1 Controls and Latin-1 Supplement|website=unicode.org|access-date=13 February 2016}}</ref> [[ISO/IEC 6429]] 8D, decimal 141) is used to move the printing position back one line (by reverse feeding the paper, or by moving a display cursor up one line) so that other characters may be printed over existing text. This may be done to make them bolder, or to add underlines, strike-throughs or other characters such as [[diacritic]]s.

Similarly, {{mono|PLD}} ([[Unicode|U]]+008B PARTIAL LINE FORWARD, decimal 139) and {{mono|PLU}} ([[Unicode|U]]+008C PARTIAL LINE BACKWARD, decimal 140) can be used to advance or reverse the text printing position by some fraction of the vertical line spacing (typically, half). These can be used in combination for subscripts (by advancing and then reversing) and superscripts (by reversing and then advancing), and may also be useful for printing diacritics.

== See also ==<!---♦♦♦ Please keep the list in alphabetical order ♦♦♦--->
*[[End-of-file]]
*[[Enter key]]
*[[Page break]]

== References ==
{{reflist|colwidth=30em}}

== External links ==
*The Unicode reference; see paragraph 5.8 in [https://www.unicode.org/versions/Unicode4.0.0/ch05.pdf Chapter 5] of the Unicode 4.0 standard (PDF)
*{{cite web |url=https://www.w3.org/TR/newline |title=The [NEL] Newline Character}}
*[http://www.oualline.com/practical.programmer/eol.html The End of Line Puzzle]
*{{webarchive|url=https://web.archive.org/web/20060820133536/http://onlamp.com/pub/a/onlamp/2006/08/17/understanding-newlines.html|title=Understanding Newlines|date=20 August 2006}}
*[https://www.rfc-editor.org/old/EOLstory.txt "The End-of-Line Story"]

[[Category:Control characters]]
[[Category:Whitespace]]
[[Category:Programming language comparisons]]
<!-- Hidden categories below -->
[[Category:Articles with example C Sharp code]]
[[Category:Articles with example Java code]]

Pages transcluded onto the current version of this page (help):

Endl (edit)
Paragraph separator (edit)
\n (edit)
Template:Ambox (view source) (template editor protected)
Template:Category handler (view source) (protected)
Template:Citation (view source) (protected)
Template:Citation needed (view source) (protected)
Template:Cite IETF (view source) (semi-protected)
Template:Cite IETF/doctypes (view source) (semi-protected)
Template:Cite IETF/makelink (view source) (semi-protected)
Template:Cite book (view source) (protected)
Template:Cite news (view source) (protected)
Template:Cite report (view source) (template editor protected)
Template:Cite web (view source) (protected)
Template:Code (view source) (template editor protected)
Template:Control code link (edit)
Template:Control code link/alias (edit)
Template:Control code link/styles.css (edit)
Template:Ctrl (edit)
Template:DMCA (view source) (template editor protected)
Template:Dated maintenance category (view source) (template editor protected)
Template:Dated maintenance category (articles) (view source) (template editor protected)
Template:Delink (view source) (protected)
Template:FULLROOTPAGENAME (view source) (template editor protected)
Template:Find sources mainspace (view source) (template editor protected)
Template:Fix (view source) (protected)
Template:Fix/category (view source) (protected)
Template:Ifsubst (view source) (template editor protected)
Template:Last word (view source) (template editor protected)
Template:Main other (view source) (protected)
Template:Mono (view source) (template editor protected)
Template:Mono/styles.css (view source) (template editor protected)
Template:More citations needed (view source) (template editor protected)
Template:Ns has subpages (view source) (protected)
Template:Other uses (view source) (template editor protected)
Template:Overline (view source) (template editor protected)
Template:Pagetype (view source) (protected)
Template:Part section link (view source) (semi-protected)
Template:Pslink (view source) (semi-protected)
Template:Redir (view source) (semi-protected)
Template:Redirect (view source) (template editor protected)
Template:Reflist (view source) (protected)
Template:Reflist/styles.css (view source) (protected)
Template:SDcat (view source) (protected)
Template:Sc2 (view source) (semi-protected)
Template:Short description (view source) (protected)
Template:Short description/lowercasecheck (view source) (protected)
Template:Smallcaps/styles.css (view source) (template editor protected)
Template:Smallcaps2 (view source) (semi-protected)
Template:Use dmy dates (view source) (template editor protected)
Template:Webarchive (view source) (template editor protected)
Template:Yesno (view source) (protected)
Module:Arguments (view source) (protected)
Module:Category handler (view source) (protected)
Module:Category handler/blacklist (view source) (protected)
Module:Category handler/config (view source) (protected)
Module:Category handler/data (view source) (protected)
Module:Category handler/shared (view source) (protected)
Module:Check for unknown parameters (view source) (protected)
Module:Citation/CS1 (view source) (protected)
Module:Citation/CS1/COinS (view source) (protected)
Module:Citation/CS1/Configuration (view source) (protected)
Module:Citation/CS1/Date validation (view source) (protected)
Module:Citation/CS1/Identifiers (view source) (protected)
Module:Citation/CS1/Utilities (view source) (protected)
Module:Citation/CS1/Whitelist (view source) (protected)
Module:Citation/CS1/styles.css (view source) (protected)
Module:Citation mode (view source) (extended confirmed protected)
Module:Delink (view source) (protected)
Module:Disambiguation/templates (view source) (protected)
Module:Find sources (view source) (template editor protected)
Module:Find sources/config (view source) (template editor protected)
Module:Find sources/links (view source) (template editor protected)
Module:Find sources/templates/Find sources mainspace (view source) (template editor protected)
Module:Format link (view source) (template editor protected)
Module:Hatnote (view source) (template editor protected)
Module:Hatnote/styles.css (view source) (template editor protected)
Module:Hatnote list (view source) (template editor protected)
Module:Message box (view source) (protected)
Module:Message box/ambox.css (view source) (protected)
Module:Message box/configuration (view source) (protected)
Module:Namespace detect/config (view source) (protected)
Module:Namespace detect/data (view source) (protected)
Module:Ns has subpages (view source) (protected)
Module:Other uses (view source) (template editor protected)
Module:Pagetype (view source) (protected)
Module:Pagetype/config (view source) (protected)
Module:Pagetype/disambiguation (view source) (protected)
Module:Pagetype/rfd (view source) (protected)
Module:Pagetype/setindex (view source) (protected)
Module:Pagetype/softredirect (view source) (protected)
Module:Redirect hatnote (view source) (template editor protected)
Module:SDcat (view source) (protected)
Module:String (view source) (protected)
Module:TableTools (view source) (protected)
Module:Template wrapper (view source) (template editor protected)
Module:Unsubst (view source) (protected)
Module:Webarchive (view source) (template editor protected)
Module:Webarchive/data (view source) (template editor protected)
Module:Wikitext Parsing (view source) (protected)
Module:Yesno (view source) (protected)

Return to Newline.

Retrieved from "https://en.wikipedia.org/wiki/Newline"