Newline
A newline, next line is a control character or sequence of control characters in character encoding specifications such as ASCII, EBCDIC, Unicode, etc. A newline is used to signify the end of a line of text and the start of a new one.
History
In the mid-1800s, long before the advent of teleprinters and teletype machines, Morse code operators or telegraphists invented and used Morse code prosigns to encode white space text formatting in formal written text messages. In particular, the Morse prosign , 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.Later, in the age of modern teleprinters, standardized character set control codes were developed to aid in white space text formatting. ASCII was developed simultaneously by the International Organization for Standardization and the American Standards Association, the latter being the predecessor organization to American National Standards Institute. During the period of 1963 to 1968, the ISO draft standards supported the use of either [|+] or #Representation| alone as a newline, while the ASA drafts supported only +.
The sequence + was commonly used on many early computer systems that had adopted 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 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: to move the carriage to column one, and to move the paper up." In fact, it was often necessary to send 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 scroll the display.
On such systems, applications had to talk directly to the Teletype machine and follow its conventions since the concept of device drivers 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 DEC used this convention. CP/M also used it in order to print on the same terminals that minicomputers used. From there MS-DOS adopted CP/M's + in order to be compatible, and this convention was inherited by Microsoft's later Windows operating system.
The Multics operating system began development in 1964 and used alone as its newline. Multics used a device driver to translate this character to whatever sequence a printer needed, and the single byte was more convenient for programming. What seems like a more obvious choice – – was not used, as provided the useful function of overprinting one line with another to create boldface, underscore and strikethrough effects. Perhaps more importantly, the use of 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 systems, whereby files composed on one operating system could not be properly formatted or interpreted by another operating system.
Representation
The concepts of carriage return and line feed are closely associated and can be considered either separately or together. In the physical media of typewriters and printers, two axes of motion, "down" and "across", are needed to create a new line on the page. Although the design of a machine 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 and combined into one.Some character sets provide a separate newline character code. EBCDIC, for example, provides an character code in addition to the and codes. Unicode, in addition to providing the ASCII and control codes, also provides a "next line" 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 in the Control Pictures block.
| Operating system | Character encoding | Abbreviation | hex value | dec value | Escape sequence |
| Multics POSIX standard oriented systems: Unix and Unix-like systems, QNX 4+ Others: BeOS, Amiga, RISC OS, and others | ASCII | ||||
| Windows, MS-DOS compatibles, Atari TOS, 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 | ASCII | ||||
| Commodore 64, Commodore 128, Acorn BBC, ZX Spectrum, TRS-80, Apple II, Oberon, classic Mac OS, HP Series 80, MIT Lisp Machine, and OS-9 | ASCII | ||||
| Acorn BBC and RISC OS spooled text output | ASCII | ||||
| QNX pre-POSIX implementation | ASCII | ||||
| Atari 8-bit computers | ATASCII | ||||
| IBM mainframe systems, including z/OS and IBM i | EBCDIC | ||||
| ZX80 and ZX81 | ZX80/ZX81 proprietary encoding |
- EBCDIC systems—mainly IBM mainframe systems, including z/OS and IBM i —use as the character combining the functions of line feed and carriage return. The equivalent Unicode character is called . EBCDIC also has control characters called and, but the numerical value of differs from the one used by ASCII. Additionally, some EBCDIC variants also use but assign a different numeric code to the character. However, those operating systems 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.
- 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 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. The bits are not generic, so while they can specify that or or even is the line terminator, they can not substitute some other code.
- Fixed line length was used by some early 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 cards, 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 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. Often this was a normal printing character such as 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
In some older protocols, the new line may be followed by a checksum or parity character.
Unicode
The Unicode standard defines a number of characters that conforming applications should recognize as line terminators:While it may seem overly complicated compared to an approach such as converting all line terminators to a single character, because Unicode is designed to preserve all information when converting a text file from any existing encoding to Unicode and back, Unicode needs to make the same distinctions between line breaks made by other encodings. For instance EBCDIC has,, and characters, so all three have to also exist in Unicode.
Most newline characters and sequences are in ASCII's C0 controls. The three newline characters outside of this range—, and —are often not recognized as newlines by software. For example:
- JSON recognizes and as whitespace, but not any other newline characters. C0 controls cannot appear unescaped within strings, but any other line break characters can.
- ECMAScript only recognizes,, and as line terminators. Historically, unescaped line terminators were not permitted in string literals, but this was changed in to allow unescaped and in strings for compatibility with JSON.
- YAML 1.1 recognized all three as line breaks; YAML 1.2 no longer recognizes them as line breaks in order to be compatible with JSON.
- Windows Notepad, the default text editor of Microsoft Windows, does not treat any of,, or as line breaks.
- gedit, the default text editor of the GNOME desktop environment, treats and as line breaks, but not.