Код символа перевода строки windows

Список из 256 символов и их коды в ASCII.

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 of text and the start of a new one.^[1]

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 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.

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 (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 CR+LF or LF alone as a newline, while the ASA drafts supported only CR+LF.

The sequence CR+LF 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 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: CR to move the carriage to column one, and LF to move the paper up.»^[2] 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 (1981) adopted CP/M’s CR+LF 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 LF alone as its newline. Multics used a device driver to translate this character to whatever sequence a printer needed (including extra padding characters), and the single byte was more convenient for programming. What seems like a more obvious choice – CR – was not used, as CR provided the useful function of overprinting one line with another to create boldface, underscore and strikethrough effects. Perhaps more importantly, the use of 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 systems, 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 Notepad^[3][4]).

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 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 (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 CR and LF combined into one (commonly called CR+LF or CRLF).

Some character sets provide a separate newline character code. EBCDIC, for example, provides an NL character code in addition to the CR and LF codes. Unicode, in addition to providing the ASCII CR and LF control codes, also provides a «next line» (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 Control Pictures block.

• EBCDIC systems—mainly IBM mainframe systems, including z/OS (OS/390) and IBM i (OS/400)—use NL (New Line, 0x15)^[8] as the character combining the functions of line feed and carriage return. The equivalent Unicode character (0x85) is called NEL (Next Line). EBCDIC also has control characters called CR and LF, but the numerical value of LF (0x25) differs from the one used by ASCII (0x0A). Additionally, some EBCDIC variants also use NL 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 (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 CRLF or LF or even CR 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 (similar to a CR). 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.

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.

«Paragraph separator» redirects here. For the symbol also known as a «paragraph sign», see Pilcrow.

The Unicode standard defines a number of characters that conforming applications should recognize as line terminators:^[9]

While it may seem overly complicated compared to an approach such as converting all line terminators to a single character (e.g. LF), because Unicode is designed to preserve all information when converting a text file from any existing encoding to Unicode and back (round-trip integrity), Unicode needs to make the same distinctions between line breaks made by other encodings. For instance EBCDIC has NL, CR, and LF characters, so all three have to also exist in Unicode.

Most newline characters and sequences are in ASCII’s C0 controls (i.e. have Unicode code points up to 0x1F). The three newline characters outside of this range—NEL, LS and PS—are often not recognized as newlines by software. For example:

• JSON recognizes CR and LF as whitespace, but not any other newline characters.^[10] C0 controls cannot appear unescaped within strings, but any other line break characters can.^[11]
• ECMAScript only recognizes CR, LF, LS and PS as line terminators.^[12] Historically, unescaped line terminators were not permitted in string literals,^[13] but this was changed in ES2019 to allow unescaped LS and PS in strings^[12] for compatibility with JSON.^[14]
• 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.^[15]
• Windows Notepad, the default text editor of Microsoft Windows, does not treat any of NEL, LS, or PS as line breaks.
• gedit, the default text editor of the GNOME desktop environment, treats LS and PS as line breaks, but not NEL.

Unicode includes some glyphs intended for presenting a user-visible character to the reader of the document, and are thus not recognized themselves as a newline:

• U+23CE ⏎ RETURN SYMBOL
• U+240A ␊ SYMBOL FOR LINE FEED
• U+240D ␍ SYMBOL FOR CARRIAGE RETURN
• U+2424 ␤ SYMBOL FOR NEWLINE

To facilitate creating portable programs, programming languages provide some abstractions to deal with the different types of newline sequences used in different environments.

The C language provides the escape sequences \n (newline) and \r (carriage return). However, these are not required to be equivalent to the ASCII LF and CR control characters. The C standard only guarantees two traits:

1. Each of these escape sequences maps to a unique implementation-defined number that can be stored in one char value.
2. When writing to a file, device node, or socket/fifo in text mode, \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 \n. In binary mode, no translation is performed, and the internal representation produced by \n is output directly.

On Unix operating system platforms, where C originated, the native newline sequence is ASCII LF (0x0A), so \n was simply defined to be that value. With the internal and external representation being identical, the translation performed in text mode is a 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 standard library function 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 \n when communicating using an Internet protocol that mandates the use of ASCII CR+LF for ending lines. Writing \n to a text mode stream works correctly on Windows systems, but produces only LF on Unix, and something completely different on more exotic systems. Using \r\n in binary mode is slightly better.

Many languages, such as C++, Perl,^[16] and Haskell provide the same interpretation of \n as C. C++ has an alternative input/output (I/O) model where the manipulator std::endl can be used to output a newline (and flushes the stream buffer).

Java, PHP,^[17] and Python^[18] provide the \r\n sequence (for ASCII CR+LF). In contrast to C, these are guaranteed to represent the values U+000D and U+000A, respectively.

The Java Class Library input/output (I/O) methods 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 CR, LF, or CR+LF as a line terminator (see BufferedReader.readLine()). The System.lineSeparator() method can be used to retrieve the underlying line separator.

Example:

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

Python permits «Universal Newline Support» when opening a file for reading, when importing modules, and when executing a file.^[19]

Some languages have created special variables, constants, and subroutines 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 \n and \r. In PHP, to avoid portability problems, newline sequences should be issued using the PHP_EOL constant.^[20]

Example in C#:

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

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 line feed or a single carriage return as a line break.

Conversely, when viewing a file originating from a Windows computer on a Unix-like system, the extra CR may be displayed as a second line break, as ^M, or as <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 console or in an editor. Modern text editors generally recognize all flavours of CR+LF newlines and allow users to convert between the different standards. Web browsers 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 protocols (including HTTP, SMTP, FTP, IRC, and many others) mandate the use of ASCII CR+LF (\r\n, 0x0D 0x0A) on the protocol level, but recommend that tolerant applications recognize lone LF (\n, 0x0A) as well. Despite the dictated standard, many applications erroneously use the C newline escape sequence \n (LF) instead of the correct combination of carriage return escape and newline escape sequences \r\n (CR+LF) (see section 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 LF instead of the required CR+LF.^[21]

The standard Internet Message Format^[22] 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».^[23]

The File Transfer Protocol can automatically convert newlines in files being transferred between 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 corrupting the file. FTP clients often employ some heuristics (for example, inspection of filename extensions) 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.^[24]

Text editors 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 CR/LF conventions.

For example, the editor Vim can make a file compatible with the Windows Notepad text editor. Within vim

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:

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

Special purpose programs to convert files between different newline conventions include unix2dos and dos2unix, mac2unix and unix2mac, mac2dos and dos2mac, and flip.^[25]
The 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 CR characters with

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

or, if the text has only CR newlines, by converting all CR newlines to LF with

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

The same tasks are sometimes performed with awk, sed, or in Perl if the platform has a Perl interpreter:

$ 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

The file command can identify the type of line endings:

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

The Unix 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):

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

Other tools permit the user to visualise the EOL characters:

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

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 paragraphs and in vertical lists. Therefore, in the logic of word processing and most text editors, 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 (↵).

RI (U+008D REVERSE LINE FEED,^[26] 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 diacritics.

Similarly, PLD (U+008B PARTIAL LINE FORWARD, decimal 139) and PLU (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.

• End-of-file
• Enter key
• Page break

• The Unicode reference; see paragraph 5.8 in Chapter 5 of the Unicode 4.0 standard (PDF)
• «The [NEL] Newline Character».
• The End of Line Puzzle
• Understanding Newlines at the Wayback Machine (archived 20 August 2006)
• «The End-of-Line Story»

• При развитии компьютеров возникла необходимость стандартизации формата хранения и отображения текстовых файлов, чтобы с текстом, составленным в компьютере одного производителя, можно было работать на компьютере другого производителя без необходимости какого-либо преобразования. Для этого в 1963 году была разработана стандартная таблица ASCII, определяющая, как должны кодироваться буквы английского языка, цифры, некоторые другие символы (+%,@$…), а также ряд управляющих символов, не имеющих графического представления и служащих для управления выводом.

• Первоначально таблица описывала 127 символов, позже была расширена до 255 символов (для хранения используются 8 бит). Коды символов из таблицы ASCII принято записывать в 16-ричном виде, например, латинская буква ‘A’ кодируется 10-тичным числом ’65’, которое в 16-ричном виде записывается как ‘0x41’.

• Следует подчеркнуть, что в то время еще не существовало графических интерфейсов для взаимодействия с компьютером. Вместо этого в качестве интерактивных терминалов для взаимодействия оператора и ЭВМ использовались «телетайпы» (teletype), представляющие что-то вроде электромеханических печатающих машин, в которых вывод осуществлялся печатью на бумагу (или, в более поздних моделях, отображением на текстовый дисплей). И управляющие символы из состава таблицы ASCII отражают специфику управления такими устройствами. Например:

  • Символ с кодом ‘0x07’ (bell) ничего не печатает, вместо этого воспроизводится звуковой сигнал для привлечения внимания оператора.

  • Символ с кодом ‘0x08’ (backspace) означает ‘вернуть печатающую головку на одну позицию назад’. Это, в частности, позволяло печатать несколько символов поверх друг-друга и реализовывать жирный или подчёркнутый шрифт.

  • Символ с кодом ‘0x0A‘ (line feed) означает ‘перевести строку’, т.е. сдвинуть печатающую головку на 1 строку вниз.

  • Символ с кодом ‘0x0С’ (form feed) заставляет принтер завершить печать на используемом листе бумаги, промотать этот лист и дальнейшую печать продолжать на следующем листе.

  • Символ с кодом ‘0x0D‘ (carriage return) означает ‘возврат каретки’, т.е. возвращает курсор или головку в начало текущей строки (без перевода строки)

• Однако полной стандартизации не получилось и так исторически сложилось, что в операционных системах разных семейств перевод строки в текстовом файле кодируется разными последовательностями управляющих символов ASCII:

  • Для семейств Unix / Linux / BSD / Solaris / … перевод строки кодируется одним символом с кодом ‘0x0A’. Видимо, подразумевается, что возврат на начало строки при этом происходит по умолчанию.

  • Для семейств DOS и Windows перевод строки кодируется двумя последовательными символами с 16-ричными кодами ‘0x0D’ и ‘0x0A’.

  • Для семейства Macintosh до версии 9.0 — одним символом с кодом ‘0x0D’.

  • Для семейства Macintosh после версии MacOS X — одним символом с кодом ‘0x0A’.

• В результате текстовый файл, составленный в ОС семейства Windows и скопированный на интерфейсный сервер, может содержать лишние символы с кодом ‘0x0D’, которые в некоторых ситуациях приведут к ошибкам при его обработке.

• Если такие символы присутствуют в скрипте для qsub, то попытка его запуска планировщиком завершится ошибкой следующего вида:

  -bash: /var/spool/PBS/mom_priv/jobs/XXXXXX.vm-pbs.SC: /bin/bash^M: bad interpreter: No such file or directory

  Дело в том, что вместо интерпретатора ‘/bin/bash’, указанного в самой первой строке скрипта, получился ‘/bin/bash^M’, а такого файла не существует (о чём и говорит фраза ‘No such file or directory’)

• Управляющие символы внутри текстового файла можно увидеть, например, из Midnight Commanger, встав на файл курсором и затем:

  • или нажав F4 (редактирование файла). Если в тексте присутствуют символы с кодом ‘0x0D’, они будут отображаться в конце строки как ‘^M‘

  • или нажав F3 (просмотр файла), а затем F4 (отображение в 16-ричном виде).

• Удалить все такие лишние символы ‘0x0D’ можно или вручную из mc, или выполнив на интерфейсном сервере утилиту ‘dos2unix‘, которой в качестве параметра сообщается имя файла, который необходимо преобразовать (будет модифицирован сам исходный файл, без создания нового файла или резервной копии):

  dos2unix submit.sh

  Существует и аналогичная утилита с именем ‘unix2dos’, осуществляющая преобразование в обратную сторону (добавляя ‘0x0D’ перед каждым ‘0x0A’).

• Кроме того, многие программы для передачи файлов умеют сами преобразовывать передаваемые файлы, автоматически добавляя или удаляя символы перевода строки. Например, WinSCP так поступает по умолчанию, если передаваемый файл имеет определённые расширения (txt, html, …), но расширение ‘sh’ в их состав не входит. Нужно или каждый раз при пересылке текстового файла переключать режим передачи в Text, или зайти в настройки и добавить нужные расширения.

• Либо, чтобы исключить необходимость перекодирования, создавать и редактировать текстовые файлы можно непосредственно на интерфейсном сервере.

Символ возврата каретки использовался в компьютерных терминалах, принтерах и системах обработки текста для перемещения курсора или печатающей головки в начало текущей строки.

В контексте компьютерных систем и текстовых файлов, символ Возврат каретки используется для обозначения конца строки. В разных операционных системах применяются разные комбинации символов для обозначения конца строки. В системах на базе UNIX и Linux используется символ





, а в операционных системах семейства Windows для обозначения конца строки используется комбинация символов





(Carriage Return) и





(Line Feed), представленная как «\r\n»

Как и остальные управляющие символы, этот символ не имеет визуального представления и не занимает места на экране или в печати. В разделе

Пиктограммы управляющих символов2400–243F

есть отдельный символ, представляющий графическое изображение символа возврата каретки в виде аббревиатуры CR (Carriage Return) —

␍

.

Escape-последовательность: \r.

Символ является одним из восьми управляющих символов, обязательного наличия которых требует стандарт POSIX:

• \0
  

  

  

  
  ;

• \a
  

  

  

  
  ;

• \b
  

  

  

  
  ;

• \t
  

  

  

  
  ;

• \n
  

  

  

  
  ;

• \v
  

  

  

  
  ;

• \f
  

  

  

  
  ;

• \r
  

  

  

  
  .

Символ «Возврат каретки» входит в подраздел «Управляющие символы C0» раздела «Основная латиница» и был утвержден как часть Юникода версии 1.1 в 1993 г.

Этот текст также доступен на следующих языках:
English;

Время на прочтение3 мин

Количество просмотров61K

Notepad в windows 10 начал понимать юниксовый перевод строки, а не только формат Windows.

С проблемой «каши» вместо удобочитаемого текста десятилетиями сталкивались те, кто пытался открыть в среде Windows текстовые документы, подготовленные на других операционных системах. Теперь же всё в одночасье изменяется. И это изменение столь же мало, сколь и эпично по своим практическим результатам и идеологическим последствиям. Microsoft вновь пытается играть в кросс-интеграцию и поддержку открытых стандартов.

Долгие годы Windows Блокнот мог нормально отображать только те текстовые документы, которые содержали символы начала новой строки в формате Windows End of Line (EOL) — «возврат каретки» (CR) и «подача на строку» (LF). На деле это приводило к тому, что Notepad не смог правильно отобразить содержимое текстовых файлов, созданных в Unix, Linux и macOS, где в качестве признака конца строки использовался только символ LF.

Например, вот скриншот Notepad, пытающегося отобразить содержимое текстового файла Linux .bashrc, который содержит только символы Unix LF EOL:

Картинка с сайта: habr.com

А вот скриншот недавно обновленного «Блокнота», отображающего содержимое того же самого файла UNIX / Linux .bashrc, но с правильными переносами:

Картинка с сайта: habr.com

Обратите внимание, что строка состояния указывает обнаруженный формат EOL текущего открытого файла.

Так же для гибкого управления новой возможностью в разделе реестра [HKEY_CURRENT_USER\Software\Microsoft\Notepad] вводятся два дополнительных ключа:

Картинка с сайта: habr.com

По накалу страстей спор о способе начала новой строки в электронных документах сравним со спором о пробелах и табуляциях в исходных текстах программ. У этого противостояния «за строку» было много причин, как лежащих в области древних стандартов и традиций, так и берущих свои корни в особенностях конструкции печатных машин и телетайпов. Не меньшую роль сыграло и стремление одних программистов буквально выполнять (интерпретировать) команды и управляющие символы, а других — следовать здравому смыслу.

Что мы можем узнать о проблеме из Википедии

Исторически на механических пишущих машинках был рычаг, который возвращал каретку к левому краю страницы и прокручивал вал, подвигая бумагу вверх на строку. На телетайпах и более поздних алфавитно-цифровых печатающих устройствах (АЦПУ) вместо каретки была головка, в лазерных принтерах она перестала быть материальной, но в термине возврат каретки всё это продолжали называть кареткой, чтобы его не менять. На телетайпах возврат каретки и подачу строки разделили, откуда традиция представления перевода строки как CR+LF перешла и к текстовым файлам.

Системы, основанные на ASCII или совместимом наборе символов, используют или LF (перевод строки, 0x0A), или CR (возврат каретки, 0x0D) по отдельности, или последовательность CR+LF. Эти названия основаны на командах принтера: перевод строки означает, что одна строка на бумаге должна быть перенесена при печати, а возврат каретки означает, что каретка печатающего устройства должна вернуться к началу текущей строки.

• CR (ASCII 0x0D) использовался в 8-битовых машинах Commodore, машинах TRS-80, Apple II, системах Mac OS до версии 9 и OS-9;
• LF (ASCII 0x0A) используется в Multics, UNIX, UNIX-подобных операционных системах (GNU/Linux, AIX, Xenix, Mac OS X, FreeBSD), BeOS, Amiga UNIX, RISC OS и других;
• CR+LF (ASCII 0x0D 0x0A) используется в DEC RT-11 и большинстве других ранних не-UNIX- и не-IBM-систем, а также в CP/M, MP/M, MS-DOS, OS/2, Microsoft Windows, Symbian OS, протоколах Интернет.

По стандарту, любое совместимое с Юникодом приложение должно воспринимать как перевод строки каждый из нижеследующих символов:

• LF (U+000A): англ. line feed — подача строки <ПС>;
• CR (U+000D): англ. carriage return — возврат каретки <ВК>;
• NEL (U+0085): англ. next line — переход на следующую строку;
• LS (U+2028): англ. line separator — разделитель строк;
• PS (U+2029): англ. paragraph separator — разделитель абзацев.

Причем, последовательность CR+LF (U+000D U+000A) надлежит воспринимать как один перевод строки, а не два.

Но как известно, стандарты стандартами, а реализации у всех часто выходят разными. И масла в огонь подливает необходимость корректно отображать унаследованные документы, созданные до эпохи юникода. Отсутствие единого общепринятого представления перевода строки в разных операционных системах надолго осложнило обмен текстовыми данными между ними.

Юникод старается примирить эту разницу, уравнивая CR, LF и CR+LF, однако вступает в противоречие с наследуемым им ASCII при трактовке последовательности LF+CR, не предварённой CR: согласно ASCII это один перевод строки, а согласно Юникоду — два.

Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку