Символы перевода строки в компьютерных системах

Введение

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

Перевод строки (часто называемый концом строки, EOL, NEL или разрывом строки) — это управляющий символ или последовательность управляющих символов в спецификациях кодирования символов, таких как ASCII, EBCDIC, Unicode и другие. Этот символ или последовательность символов используется для обозначения конца строки текста и начала новой строки.

История

В середине 1800-х годов, задолго до появления телепринтеров и телетайпов, операторы или телеграфисты, использовавшие код Морзе, изобрели и применяли просигналы кода Морзе для кодирования форматирования пробелов в формальных письменных текстовых сообщениях. В частности, просигнал Морзе (мнемоническое «reak ext»), представленный последовательностью буквальных текстовых символов кода Морзе «B» и «T», отправляемых без обычных межсимвольных пробелов, использовался в коде Морзе для кодирования и обозначения новой строки или нового раздела в формальном текстовом сообщении. Позже, в эпоху современных телепринтеров, были разработаны стандартизированные коды управления символами для облегчения форматирования текста с пробелами. ASCII был разработан одновременно Международной организацией по стандартизации (ISO) и Американской ассоциацией стандартов (ASA), последняя являлась предшественницей Американского национального института стандартов (ANSI). В период с 1963 по 1968 год проекты стандартов ISO поддерживали использование либо + , либо только в качестве символа новой строки, в то время как проекты ASA поддерживали только +. Последовательность + широко использовалась во многих ранних компьютерных системах, принявших телетайпы – как правило, телетайп модели 33 ASR – в качестве консольного устройства, поскольку эта последовательность требовалась для позиционирования этих принтеров в начале новой строки. Разделение символа новой строки на две функции скрывало тот факт, что печатающая головка не успевала вернуться с правого края к началу следующей строки, чтобы напечатать следующий символ. Любой символ, напечатанный после , часто отпечатывался размытым пятном в середине страницы, пока печатающая головка перемещала каретку обратно в начальное положение. «Решением было сделать символ новой строки двумя символами: для перемещения каретки в первый столбец и для перемещения бумаги вверх». Фактически, часто требовалось отправлять дополнительные заполняющие символы – возврат каретки (CR) или нулевые символы (NUL), которые игнорировались, но давали печатающей головке время переместиться к левому краю. Многие ранние видеодисплеи также требовали нескольких временных интервалов символов для прокрутки дисплея. На таких системах приложения должны были напрямую взаимодействовать с телетайпом и следовать его соглашениям, поскольку концепция драйверов устройств, скрывающих такие аппаратные детали от приложения, еще не была достаточно развита. Поэтому текст обычно создавался с учетом требований телетайпов. Большинство миникомпьютерных систем от DEC использовали это соглашение. CP/M также использовала его для печати на тех же терминалах, что и миникомпьютеры. Затем MS DOS (1981) переняла + от CP/M для обеспечения совместимости, и это соглашение было унаследовано более поздней операционной системой Microsoft Windows. Операционная система Multics начала разрабатываться в 1964 году и использовала в качестве символа новой строки. Multics использовала драйвер устройства для преобразования этого символа в любую последовательность, необходимую принтеру (включая дополнительные заполняющие символы), и один байт был более удобен для программирования. Более очевидный выбор – не был использован, поскольку предоставлял полезную функцию наложения одной строки на другую для создания эффектов полужирного шрифта, подчеркивания и зачеркивания. Возможно, что более важно, использование в качестве символа конца строки уже было включено в проекты будущего стандарта ISO/IEC 646. Unix следовала практике Multics, а затем и Unix-подобные системы. Это создавало конфликты между операционными системами Windows и Unix, когда файлы, созданные в одной операционной системе, не могли быть правильно отформатированы или интерпретированы другой операционной системой (например, скрипт оболочки UNIX, написанный в текстовом редакторе Windows, таком как Блокнот).

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 (mnemonic reak ext) 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 + or 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 (1981) 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 (including extra padding characters), 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 (for example a UNIX shell script written in a Windows text editor like Notepad).

Представительство

Понятия возврата каретки (CR) и перевода строки (LF) тесно связаны и могут рассматриваться как отдельно, так и вместе. В физических устройствах, таких как пишущие машинки и принтеры, для создания новой строки на странице необходимы две оси движения: "вниз" и "вправо". Хотя при разработке устройства (пишущей машинки или принтера) они должны рассматриваться отдельно, абстрактная логика программного обеспечения может объединить их в одно событие. Поэтому новая строка в кодировке символов может быть определена как комбинация и , объединенных в один символ (обычно называемый или ). Некоторые наборы символов предоставляют отдельный код символа новой строки. Например, EBCDIC предоставляет код символа в дополнение к кодам и . Unicode, помимо кодов ASCII и контрольных кодов, также предоставляет контрольный код "следующая строка" (Next Line), а также контрольные коды для маркеров "разделитель строк" и "разделитель абзацев". +Представление новой строки в программных приложениях и операционных системах одним или двумя управляющими символами. Операционная система Кодировка символов Сокращение hex value dec value Escape sequence POSIX-ориентированные системы: Unix и Unix-подобные системы (Linux, macOS, *BSD, AIX, Xenix и т. д.), QNX 4+, Multics, BeOS, Amiga, RISC OS и другие ASCII Windows, MS DOS, Atari TOS, DEC TOPS 10, RT 11, CP/M, MP/M, OS/2, Symbian OS, Palm OS, Amstrad CPC и большинство других ранних не-Unix и не-IBM операционных систем Commodore 64, Commodore 128, Acorn BBC, ZX Spectrum, TRS 80, Apple II, Oberon, классическая Mac OS, HP Series 80, MIT Lisp Machine и OS 9 Acorn BBC и RISC OS, используют в качестве исходного текста QNX до POSIX (версия < 4) Atari 8-битные компьютеры ATASCII IBM основные системы, включая z/OS (OS/390) и IBM i (OS/400) EBCDIC ZX80 и ZX81 (домашние компьютеры от Sinclair Research Ltd) ZX80/ZX81 собственная кодировка

В системах EBCDIC — в основном в основных системах IBM, включая z/OS (OS/390) и IBM i (OS/400) — используется (New Line, ) как символ, объединяющий функции перевода строки и возврата каретки. Эквивалентный символ Unicode называется (Next Line). EBCDIC также имеет управляющие символы, называемые и , но числовое значение отличается от используемого в ASCII. Кроме того, некоторые варианты EBCDIC также используют , но присваивают символу другой числовой код. Однако эти операционные системы используют файловую систему, основанную на записях, которая хранит текстовые файлы в виде одной записи на строку. В большинстве форматов файлов фактические символы завершения строки не хранятся. Операционные системы для CDC 6000 серии определяли новую строку как два или более нулевых шестибитных символа в конце 60-битного слова. Некоторые конфигурации также определяли нулевой символ как символ двоеточия, в результате чего несколько двоеточий могли интерпретироваться как новая строка в зависимости от позиции. RSX 11 и OpenVMS также используют файловую систему, основанную на записях, которая хранит текстовые файлы в виде одной записи на строку. В большинстве форматов файлов фактические символы завершения строки не хранятся, но служба управления записями может прозрачно добавлять символ завершения к каждой строке при извлечении ее приложением. Сами записи могут содержать те же символы завершения строки, что может рассматриваться как полезная функция или недостаток в зависимости от приложения. RMS не только хранит записи, но и хранит метаданные о разделителях записей в разных битах файла, чтобы еще больше усложнить ситуацию (поскольку файлы могут иметь записи фиксированной длины, записи, которым предшествует счетчик, или записи, которые завершаются определенным символом). Биты не являются универсальными, поэтому, хотя они могут указывать, что или или даже является символом завершения строки, они не могут заменить какой-либо другой код. Фиксированная длина строки использовалась в некоторых ранних операционных системах мейнфреймов. В такой системе, например, предполагался неявный конец строки каждые 72 или 80 символов. Символ новой строки не хранился. Если файл импортировался из внешнего мира, строки короче длины строки должны были заполняться пробелами, а строки длиннее длины строки должны были обрезаться. Это имитировало использование перфокарт, на которых каждая строка хранилась на отдельной карте, обычно с 80 столбцами на каждой карте, часто с порядковыми номерами в столбцах 73–80. Многие из этих систем добавляли управляющий символ возврата каретки в начало следующей записи; это могло указывать, является ли следующая запись продолжением строки, начатой предыдущей записью, или новой строкой, или должна перезаписывать предыдущую строку (подобно ). Часто это был обычный печатный символ, такой как , который поэтому не мог использоваться в качестве первого символа в строке. Некоторые ранние линейные принтеры интерпретировали эти символы непосредственно в записях, отправляемых им.

EBCDIC systems—mainly IBM mainframe systems, including z/OS (OS/390) and IBM i (OS/400)—use (New Line, ) as the character combining the functions of line feed and carriage return. The equivalent Unicode character is called (Next Line). 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 (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 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 (similar to a ). 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.

Протоколы связи

Многие протоколы связи используют ту или иную конвенцию обозначения новой строки. В частности, протоколы, опубликованные рабочей группой по разработке интернет-стандартов (IETF), как правило, используют последовательность ASCII CRLF. В некоторых более старых протоколах за символом новой строки может следовать контрольная сумма или символ проверки чётности.

Проблемы с различными форматами новых строк

Различные соглашения о символах новой строки приводят к неправильному отображению текстовых файлов, переданных между системами разных типов. Текст в файлах, созданных в программах, распространенных в Unix или классической Mac OS, может отображаться как одна длинная строка в большинстве программ, распространенных в MS DOS и Microsoft Windows, поскольку они не распознают символ новой строки или символ возврата каретки как разрыв строки. И наоборот, при просмотре файла, созданного в Windows, на Unix-подобной системе, дополнительный символ новой строки может отображаться как двойной перенос строки, как , или как в конце каждой строки. Кроме того, программы, отличные от текстовых редакторов, могут не принимать файл, например, файл конфигурации, закодированный с использованием чужого соглашения о символах новой строки, как допустимый файл. Проблему бывает трудно обнаружить, поскольку некоторые программы корректно обрабатывают чужие символы новой строки, а другие — нет. Например, компилятор может завершиться с ошибками синтаксиса, даже если исходный файл выглядит правильно при отображении в консоли или редакторе. Современные текстовые редакторы обычно распознают все варианты символов новой строки и позволяют пользователям преобразовывать их между различными стандартами. Веб-браузеры обычно также способны отображать текстовые файлы и веб-сайты, использующие разные типы символов новой строки. Даже если программа поддерживает различные соглашения о символах новой строки, эти функции часто недостаточно четко обозначены, описаны или документированы. Обычно пользователям предоставляется меню или выпадающий список с перечислением различных соглашений о символах новой строки без указания, приведет ли выбор к переинтерпретации, временному преобразованию или постоянному преобразованию символов новой строки. Некоторые программы неявно преобразуют символы новой строки при открытии, копировании, вставке или сохранении — часто непоследовательно. Большинство текстовых интернет-протоколов (включая HTTP, SMTP, FTP, IRC и многие другие) требуют использования ASCII + (, ) на уровне протокола, но рекомендуют, чтобы приложения с высокой степенью устойчивости к ошибкам также распознавали одиночные символы новой строки (, ). Несмотря на установленный стандарт, многие приложения ошибочно используют escape-последовательность новой строки C вместо правильной комбинации escape-последовательности возврата каретки и escape-последовательности новой строки (+) (см. раздел «Newline в языках программирования» выше). Это случайное использование неправильных escape-последовательностей приводит к проблемам при попытке связи с системами, придерживающимися более строгой интерпретации стандартов, а не предлагаемой устойчивой к ошибкам интерпретации. Одной из таких нетерпимых систем является почтовый агент qmail, который активно отказывается принимать сообщения от систем, отправляющих одиночные символы новой строки вместо требуемых +. Стандартный формат интернет-сообщений для электронной почты гласит: «CR и LF ДОЛЖНЫ встречаться только вместе как CRLF; они НЕ ДОЛЖНЫ появляться независимо в теле сообщения». Различия в реализации SMTP в отношении обработки одиночных символов LF и/или CR привели к атакам спуфинга SMTP, известным как «SMTP smuggling». Протокол передачи файлов может автоматически преобразовывать символы новой строки в файлах, передаваемых между системами с разными представлениями символов новой строки, когда передача выполняется в «ASCII-режиме». Однако передача двоичных файлов в этом режиме обычно приводит к катастрофическим результатам: любое вхождение последовательности байтов новой строки, которая в данном контексте не имеет семантики завершения строки, а является просто частью обычной последовательности байтов, будет преобразовано в любое представление новой строки, используемое другой системой, что фактически повредит файл. FTP-клиенты часто используют некоторые эвристики (например, проверку расширений имен файлов) для автоматического выбора двоичного или ASCII-режима, но в конечном итоге пользователи должны убедиться, что их файлы передаются в правильном режиме. Если есть какие-либо сомнения относительно правильного режима, следует использовать двоичный режим, так как тогда файлы не будут изменены FTP, хотя они могут отображаться неправильно.

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 or a single as a line break. Conversely, when viewing a file originating from a Windows computer on a Unix like system, the extra may be displayed as a second line break, as , or as 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 + 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 + (, ) on the protocol level, but recommend that tolerant applications recognize lone (, ) as well. Despite the dictated standard, many applications erroneously use the C newline escape sequence instead of the correct combination of carriage return escape and newline escape sequences (+) (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 instead of the required +. The standard Internet Message Format 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". 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.

Интерпретация

Два способа интерпретации символов новой строки, оба логически непротиворечивые, заключаются в том, что они либо разделяют строки, либо завершают их. Если символ новой строки рассматривается как разделитель, то после последней строки файла не должно быть символа новой строки. Некоторые программы испытывают трудности при обработке последней строки файла, если она не завершается символом новой строки. С другой стороны, программы, ожидающие, что символ новой строки будет использоваться как разделитель, интерпретируют завершающий символ новой строки как начало новой (пустой) строки. Напротив, если символ новой строки считается признаком завершения строки, то все текстовые строки, включая последнюю, должны завершаться символом новой строки. Если последняя последовательность символов в текстовом файле не является символом новой строки, последняя строка файла может считаться некорректной или неполной, либо файл может считаться усеченным. В тексте, предназначенном в основном для чтения людьми с использованием программного обеспечения, реализующего автоматический перенос строк, символ новой строки обычно сохраняется только в том случае, если требуется разрыв строки независимо от того, поместится ли следующее слово на той же строке, например, между абзацами или в вертикальных списках. Поэтому в логике текстовых процессоров и большинства текстовых редакторов символ новой строки используется для обозначения конца абзаца и известен как "жесткий перенос строки", в отличие от "мягких переносов строк", которые динамически создаются для реализации переноса строк и могут изменяться при каждом отображении. Во многих приложениях существует отдельный управляющий символ, называемый "ручным переносом строки", для принудительного разрыва строки внутри одного абзаца. Графическое представление управляющего символа жесткого переноса строки обычно представляет собой пилькро (¶), а для ручного переноса строки – стрелку возврата каретки (↵).

Обратные и частичные каналы подачи

(U+008D REVERSE LINE FEED, ISO/IEC 6429 8D, десятичное число 141) используется для перемещения позиции печати на одну строку назад (путем обратной подачи бумаги или перемещения курсора дисплея вверх на одну строку), чтобы другие символы могли быть напечатаны поверх существующего текста. Это может быть сделано для выделения текста жирным шрифтом, добавления подчеркивания, зачеркивания или других символов, таких как диакритические знаки. Аналогично, (U+008B PARTIAL LINE FORWARD, десятичное число 139) и (U+008C PARTIAL LINE BACKWARD, десятичное число 140) могут использоваться для смещения позиции печати текста вперед или назад на часть вертикального интервала между строками (обычно, на половину). Их можно комбинировать для создания индексов (сначала смещая вперед, затем назад) и верхних индексов (сначала смещая назад, затем вперед), а также для печати диакритических знаков.