Новая линия

Чтобы узнать о других значениях, см. Новая линия (значения) .

«Эндл» перенаправляется сюда. Чтобы узнать о ботанике, см. Стефана Эндлихера .

Новая строка вставляется между словами «Привет» и «мир».

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

История

В середине 1800-х годов, задолго до появления телетайпов и телетайпов, операторы азбуки Морзе или телеграфисты изобрели и использовали знаки азбуки Морзе для кодирования форматирования текста пробелов в формальных письменных текстовых сообщениях. В частности, Морзе прознак BT (мнемонический разрыв текста ) , представленный конкатенацией буквальных текстовых символов кода Морзе «B» и «T», отправленных без обычного межсимвольного интервала, используется в азбуке Морзе для кодирования и обозначения новой строки. или новый раздел в официальном текстовом сообщении.

Позже, в эпоху современных телетайпов , были разработаны стандартизированные коды управления набором символов, помогающие форматировать текст с пробелами. ASCII был разработан одновременно Международной организацией по стандартизации (ISO) и Американской ассоциацией по стандартизации (ASA), причем последняя является предшественницей Американского национального института стандартов (ANSI). В период с 1963 по 1968 год проекты стандартов ISO поддерживали использование либо CR + НЧ или LF в качестве новой строки, в то время как проекты ASA поддерживают только CR + ЛФ .

Последовательность CR + LF обычно использовался во многих ранних компьютерных системах, в которых использовались телетайпы - обычно Teletype Model 33 ASR - в качестве консольного устройства, поскольку эта последовательность требовалась для позиционирования этих принтеров в начале новой строки. Разделение новой строки на две функции скрывало тот факт, что печатающая головка не могла вовремя вернуться из крайнего правого положения в начало следующей строки, чтобы напечатать следующий символ. Любой символ, напечатанный после CR часто печатался как пятно в середине страницы, пока печатающая головка все еще возвращала каретку в первое положение. «Решение заключалось в том, чтобы сделать новую строку двумя символами: CR , чтобы переместить каретку в первый столбец, и LF, чтобы переместить бумагу вверх». Фактически, часто приходилось отправлять дополнительные символы заполнения — лишние CR или NUL — которые игнорируются, но дают печатающей головке время переместиться к левому полю. Многие ранние видеодисплеи также требовали нескольких символов для прокрутки дисплея.

В таких системах приложениям приходилось напрямую взаимодействовать с телетайпом и следовать его соглашениям, поскольку концепция драйверов устройств , скрывающих такие детали оборудования от приложения, еще не была хорошо разработана. Поэтому текст обычно составлялся для удовлетворения потребностей телетайпов. Большинство миникомпьютерных систем DEC использовали это соглашение. CP/M также использовал его для печати на тех же терминалах, что и миникомпьютеры. Отсюда MS-DOS (1981) приняла CP/M . CR + LF для обеспечения совместимости, и это соглашение было унаследовано более поздней Microsoft Windows операционной системой .

Операционная система Multics начала разработку в 1964 году и использовала Только LF в качестве новой строки. Multics использовала драйвер устройства для преобразования этого символа в любую последовательность, необходимую принтеру (включая дополнительные символы заполнения ), и одиночный байт был более удобен для программирования. Что кажется более очевидным выбором — CR — не использовался, т.к. CR предоставил полезную функцию наложения одной строки на другую для создания эффектов жирного шрифта , подчеркивания и зачеркивания . Возможно, еще важнее то, что использование Сам по себе LF в качестве терминатора линии уже был включен в проекты будущего стандарта ISO/IEC 646 . Unix последовала практике Multics, а позже Unix-подобные системы последовали за Unix. Это создавало конфликты между Windows и Unix-подобными операционными системами , в результате чего файлы, созданные в одной операционной системе, не могли быть правильно отформатированы или интерпретированы другой операционной системой (например, сценарий оболочки UNIX , написанный в текстовом редакторе Windows, таком как Блокнот). ).

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

Понятия возврата каретки (CR) и перевода строки (LF) тесно связаны и могут рассматриваться как по отдельности, так и вместе. В физических носителях, таких как пишущие машинки и принтеры необходимы две оси движения: «вниз» и «поперек» , для создания новой строки на странице . Хотя при проектировании машины (пишущей машинки или принтера) они должны рассматриваться по отдельности, абстрактная логика программного обеспечения может объединить их как одно событие. Вот почему новая строка в кодировке символов может быть определена как CR и LF объединены в одну (обычно называемую CR+LF или CRLF).

Некоторые наборы символов предоставляют отдельный код символа новой строки. EBCDIC , например, предоставляет Код символа NL в дополнение к ЧР и ЛФ- коды. Unicode , помимо предоставления ASCII ЧР и LF Коды управления , также обеспечивают «следующую строку» ( NEL ) управляющий код, а также управляющие коды для маркеров «разделитель строк» ​​и «разделитель абзацев».

Программные приложения и представление операционной системы новой строки с одним или двумя управляющими символами.

Операционная система	Кодировка символов	Сокращение	шестнадцатеричное значение	декабрьское значение	Escape-последовательность
Системы, ориентированные на стандарт POSIX : Unix и Unix-подобные системы ( Linux , macOS , *BSD , AIX , Xenix и т. д.), QNX 4+, Multics , BeOS , Amiga , RISC OS и другие.	ASCII	НЧ	0А	10	\п
Windows , совместимость с MS-DOS , Atari TOS , DEC TOPS-10 , RT-11 , CP/M , MP/M , OS/2 , Symbian OS , Palm OS , Amstrad CPC и большинство других ранних версий, не относящихся к Unix и не-Unix. Операционные системы IBM		ЧР ЛФ	0Д 0А	13 10	\r\n
Commodore 64 , Commodore 128 , Acorn BBC , ZX Spectrum , TRS-80 , Apple II , Oberon , классическая Mac OS , HP Series 80 , MIT Lisp Machine и OS-9		ЧР	0D	13	\р
Желудь BBC и ОС RISC вывод буферного текста		ЛФ ЧР	0А 0Д	10 13	\п\р
Реализация QNX до POSIX (версия <4)		РС	1Е	30	\036
8-битные компьютеры Atari	ПРИЛОЖЕНИЯ	окончание срока действия	9Б	155
IBM Системы мейнфреймов , включая z/OS ( OS/390 ) и IBM i ( OS/400 )	EBCDIC	Нидерланды	15	21	\025
ZX80 и ZX81 (домашние компьютеры от Sinclair Research Ltd )	ZX80 / ZX81 Собственная кодировка		76	118

• Системы EBCDIC — в основном IBM системы мэйнфреймов , включая z/OS ( OS/390 ) и IBM i ( OS/400 ) — используют НЛ (Новая линия, 0x15 ) как символ, сочетающий в себе функции перевода строки и возврата каретки. Эквивалентный символ Юникода ( 0x85) называется НЭЛ (Следующая строка). EBCDIC также имеет управляющие символы, называемые ЧР и LF , но числовое значение НФ ( 0x25 ) отличается от используемого ASCII ( 0x0А ). Кроме того, некоторые варианты EBCDIC также используют NL , но присвойте символу другой цифровой код. Однако в этих операционных системах используется файловая система на основе записей , в которой текстовые файлы хранятся как одна запись в строке. В большинстве форматов файлов терминаторы строки фактически не сохраняются.
• Операционные системы серии CDC 6000 определяли новую строку как два или более шестибитных символа с нулевым значением в конце 60-битного слова. В некоторых конфигурациях символ с нулевым значением также определялся как символ двоеточия , в результате чего несколько двоеточий можно было интерпретировать как новую строку в зависимости от позиции.
• RSX-11 и OpenVMS также используют файловую систему на основе записей, в которой текстовые файлы хранятся как одна запись в строке. В большинстве форматов файлов терминаторы строк фактически не сохраняются, но служба управления записями может прозрачно добавлять терминатор к каждой строке, когда она извлекается приложением. Сами записи могут содержать одни и те же символы конца строки, что в зависимости от приложения можно считать особенностью или неудобством. RMS не только хранит записи, но также хранит метаданные о разделителях записей в разных битах, чтобы файл еще больше усложнил ситуацию (поскольку файлы могут иметь записи фиксированной длины, записи с префиксом счетчика или записи, заканчивающиеся определенным символом). ). Биты не являются общими, поэтому, хотя они могут указывать, что ЧР НЧ или НЧ или даже CR — это признак завершения строки, они не могут подменять какой-либо другой код.
• Фиксированная длина строки использовалась в некоторых ранних операционных системах для мэйнфреймов . Например, в такой системе неявный конец строки предполагался через каждые 72 или 80 символов. Символ новой строки не был сохранен. Если файл был импортирован из внешнего мира, строки короче длины строки нужно было дополнять пробелами, а строки длиннее длины строки приходилось усекать. Это имитировало использование перфокарт , на которых каждая строка хранилась на отдельной карте, обычно с 80 столбцами на каждой карте, часто с порядковыми номерами в столбцах 73–80. Многие из этих систем добавляли символ управления кареткой в ​​начало следующей записи ; это может указывать на то, является ли следующая запись продолжением строки, начатой ​​предыдущей записью, или новой строкой, или следует напечатать предыдущую строку (аналогично КР ). Зачастую это был обычный печатный знак типа #поэтому его нельзя было использовать в качестве первого символа в строке. Некоторые ранние построчные принтеры интерпретировали эти символы непосредственно в отправляемых им записях.

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

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

В некоторых старых протоколах за новой строкой может следовать символ контрольной суммы или четности.

Юникод

«Разделитель абзацев» перенаправляется сюда. О символе, также известном как «знак абзаца», см. Pilcrow .

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

 ЛФ :     Перевод строки, U + 000A

 ВТ :     Вертикальная вкладка , U + 000B

 ФФ :     Подача формы , U+000C

 ЧР :     Возврат каретки , U + 000D

CR + ЛФ : ЧР ( U+000D ), за которым следует НФ ( U + 000A )

 В :    Следующая линия, U + 0085

 ЛС :     Разделитель строк, U + 2028

 PS :     Разделитель абзацев, U + 2029

Хотя это может показаться слишком сложным по сравнению с таким подходом, как преобразование всех символов конца строки в один символ (например, LF ), поскольку Unicode предназначен для сохранения всей информации при преобразовании текстового файла из любой существующей кодировки в Unicode и обратно ( двусторонняя целостность ), Unicode должен делать такие же различия между разрывами строк, сделанными другими кодировками.

Например: NL является частью EBCDIC , который использует код 0x15 ; обычно он отображается в Unicode В , 0x85 , который является управляющим символом в наборе управления C1 . Таким образом, это определено ECMA 48, и распознается кодировками, соответствующими стандарту ISO/IEC 2022 (что эквивалентно ECMA 35). Комплект управления C1 также совместим с ISO-8859-1 . Подход, принятый в стандарте Unicode, позволяет двустороннему преобразованию сохранять информацию, в то же время позволяя приложениям распознавать все возможные типы терминаторов строки.

Распознавание и использование кодов новой строки больше, чем 0x7F ( В , ЛС и PS ) делается не часто. Это несколько байтов в UTF-8 , а код для NEL использовался как многоточие ( …) символ в Windows-1252 . Например:

• ECMAScript принимает ЛС и PS как переносы строк, но считает U + 0085 ( NEL ) пробел вместо разрыва строки.
• JSON позволяет ЛС и Символы PS внутри строк, тогда как ECMAScript до ES2019 рассматривал их как символы новой строки и, следовательно, незаконный синтаксис.
• ЯМЛ начиная с версии 1.2 больше не распознает их как разрывы строк, чтобы обеспечить совместимость с JSON .
• Блокнот Windows , текстовый редактор Microsoft Windows по умолчанию , не поддерживает ни один из В , ЛС или PS как переносы строк.
• gedit , текстовый редактор по умолчанию в GNOME среде рабочего стола , обрабатывает ЛС и ПС , но нет NEL , как разрыв строки.

Специальные символы Юникода U + 2424 ( СИМВОЛ НОВОЙ СТРОКИ , ␤), U + 23CE ( СИМВОЛ ВОЗВРАТА , ⏎), U + 240D ( СИМВОЛ ВОЗВРАТА КАРЕТКИ , ␍) и U + 240А ( СИМВОЛ ПЕРЕВОДА СТРОКИ , ␊) представляют собой глифы, предназначенные для представления видимого пользователем символа читателю документа, и поэтому сами по себе не распознаются как перевод строки.

В языках программирования

«\n» перенаправляется сюда. Аналогичное обозначение чисел см. в \nnn (значения) .

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

Язык программирования C предоставляет escape-последовательности. '\n' (новая строка) и '\r' (возврат каретки). Однако они не обязательно должны быть эквивалентны ASCII. НЧ и CR управляющие символы. Стандарт C гарантирует только две вещи:

1. Каждая из этих escape-последовательностей соответствует уникальному числу, определяемому реализацией, которое может храниться в одном файле. значение символа .
2. При записи в файл, узел устройства или сокет/FIFO в текстовом режиме '\n' прозрачно преобразуется в собственную последовательность новой строки, используемую системой, которая может быть длиннее одного символа. При чтении в текстовом режиме собственная последовательность новой строки преобразуется обратно в '\н' . В двоичном режиме трансляция не выполняется, а внутреннее представление, создаваемое '\n' выводится напрямую.

На платформах Unix, откуда возник C, исходной последовательностью новой строки является ASCII. НФ ( 0x0A ), поэтому '\n' был просто определен как это значение. Поскольку внутреннее и внешнее представление идентичны, перевод, выполняемый в текстовом режиме, не выполняется , и в Unix нет понятия текстового или двоичного режима. Это привело к тому, что многие программисты, разрабатывавшие свое программное обеспечение для систем Unix, просто полностью игнорировали это различие, в результате чего код не переносился на разные платформы.

Функция библиотеки C fgets () лучше избегать в двоичном режиме, поскольку любой файл, написанный не с соблюдением соглашения Unix о новой строке, будет неправильно прочитан. Кроме того, в текстовом режиме любой файл, записанный не с использованием собственной последовательности новой строки системы (например, файл, созданный в системе Unix, а затем скопированный в систему Windows), также будет неправильно прочитан.

Еще одной распространенной проблемой является использование '\n' при общении с использованием интернет-протокола, который требует использования ASCII. CR + LF для окончания строк. Письмо '\n' для потока текстового режима работает правильно в системах Windows, но создает только LF в Unix и нечто совершенно иное в более экзотических системах. С использованием «\r\n» в двоичном режиме немного лучше.

Многие языки, такие как C++ , Perl , и Haskell предоставляют одинаковую интерпретацию '\n' как C. C++ имеет альтернативную модель ввода-вывода , в которой манипулятор std::endl можно использовать для вывода новой строки (и очистки буфера потока).

Ява , PHP , и Питон предоставить Последовательность '\r\n' (для ASCII CR + ЛФ ). В отличие от C, они гарантированно представляют значения U+000D и U+000A соответственно.

Библиотеки ввода-вывода Java не транслируют их прозрачно в зависящие от платформы последовательности новой строки при вводе или выводе. Вместо этого они предоставляют функции для написания полной строки, которые автоматически добавляют собственную последовательность новой строки, и функции для чтения строк, которые принимают любой из ЧР , НЧ или CR + LF как терминатор линии (см. BufferedReader.readLine() ). Метод System.lineSeparator() можно использовать для получения базового разделителя строк.

Пример:

   Строка   eol   =   Система  .   Разделитель строк  (); 
     String   lineColor   =   "Цвет: Красный"   +   eol  ; 

Python допускает «универсальную поддержку новой строки» при открытии файла для чтения, при импорте модулей и при выполнении файла.

В некоторых языках созданы специальные переменные , константы и подпрограммы для облегчения перехода на новую строку во время выполнения программы. В некоторых языках, таких как PHP и Perl , двойные кавычки необходимы для выполнения escape-подстановки для всех escape-последовательностей, включая '\n' и '\р' . В PHP, чтобы избежать проблем с переносимостью, последовательности новой строки следует выдавать с использованием константы PHP_EOL.

Пример на С# :

   строка   eol   =   Окружающая среда  .   Новая линия  ; 
     строка   lineColor   =   "Цвет: Красный"   +   eol  ; 
   
     строка   eol2   =   "\n"  ; 
     строка   lineColor2   =   «Цвет: Синий»   +   eol2  ; 

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

, Текстовый файл созданный с помощью gedit и просмотренный с помощью шестнадцатеричного редактора . Помимо текстовых объектов, существуют только маркеры EOL с шестнадцатеричным значением 0A.

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

Текст в файлах, созданных с помощью программ, распространенных в Unix-подобных или классических Mac OS , отображается как одна длинная строка в большинстве программ, распространенных в MS-DOS и Microsoft Windows , поскольку они не отображают ни одного line feed или одиночный carriage return как разрыв строки.

И наоборот, при просмотре файла, созданного на компьютере Windows в Unix-подобной системе, дополнительные CR может отображаться как перенос второй строки, например ^M или как <cr> в конце каждой строки.

Более того, программы, отличные от текстовых редакторов, могут не принимать файл, например файл конфигурации, закодированный с использованием иностранного соглашения о новой строке, как действительный файл.

Проблему может быть трудно обнаружить, поскольку некоторые программы правильно обрабатывают внешние символы новой строки, а другие — нет. Например, компилятор может выйти из строя из-за непонятных синтаксических ошибок, даже если исходный файл выглядит правильно при отображении на консоли или в редакторе . Современные текстовые редакторы обычно распознают все разновидности CR + LF новые строки и позволяют пользователям конвертировать между различными стандартами. Веб-браузеры обычно также способны отображать текстовые файлы и веб-сайты, в которых используются различные типы символов новой строки.

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

Большинство текстовых интернет- протоколов (включая HTTP , SMTP , FTP , IRC и многие другие) требуют использования ASCII. CR + НФ ( '\r\n' , 0x0D 0x0A ) на уровне протокола, но рекомендуется, чтобы толерантные приложения распознавали одиночные НФ ( '\n' , 0x0A ) тоже. Несмотря на предписанный стандарт, многие приложения ошибочно используют C. escape-последовательность новой строки '\n' ( LF ) вместо правильной комбинации escape-последовательностей возврата каретки и escape-последовательностей новой строки. '\r\n' ( CR + LF ) (см. раздел «Новая строка в языках программирования» выше). Такое случайное использование неправильных escape-последовательностей приводит к проблемам при попытке взаимодействия с системами, придерживающимися более строгой интерпретации стандартов вместо предлагаемой толерантной интерпретации. Одной из таких нетерпимых систем является qmail агент передачи почты , который активно отказывается принимать сообщения от систем, которые отправляют пустые сообщения. LF вместо требуемого CR + ЛФ .

Стандартный формат интернет-сообщений для электронной почты указано: «CR и LF ДОЛЖНЫ встречаться только вместе как CRLF; они НЕ ДОЛЖНЫ появляться независимо в теле». Различия между реализациями SMTP в том, как они обрабатывают пустые символы LF и/или пустые символы CR, привели к атакам спуфинга SMTP, называемым «контрабандой SMTP».

Протокол передачи файлов может автоматически преобразовывать символы новой строки в файлах, передаваемых между системами с различными представлениями новой строки, когда передача выполняется в «режиме ASCII». Однако передача двоичных файлов в этом режиме обычно приводит к катастрофическим результатам: любое появление последовательности байтов новой строки, которая в этом контексте не имеет семантики терминатора строки, а является всего лишь частью нормальной последовательности байтов, будет преобразовано в любое представление новой строки. другая система использует, фактически повреждая файл. FTP-клиенты часто используют некоторые эвристики (например, проверку расширений имен файлов ) для автоматического выбора двоичного режима или режима ASCII, но в конечном итоге пользователи должны убедиться, что их файлы передаются в правильном режиме. Если есть какие-либо сомнения относительно правильного режима, следует использовать двоичный режим, поскольку в этом случае файлы не будут изменены FTP, хотя они могут отображаться неправильно.

Преобразование между форматами новой строки

Текстовые редакторы часто используются для преобразования текстового файла между различными форматами новой строки; большинство современных редакторов могут читать и записывать файлы, используя как минимум разные символы ASCII. ЧР / Соглашения ЛФ .

Например, редактор Vim может сделать файл совместимым с текстовым редактором «Блокнот» Windows. Внутри vim

:  установить   формат файла  =  dos 
   :  вк 

Редакторы могут оказаться непригодными для преобразования файлов большего размера или массового преобразования большого количества файлов. Для файлов большего размера (в Windows NT) часто используется следующая команда:

D:\>  ВВЕДИТЕ  unix_file  |   НАЙТИ /V  ""   >  dos_file 
 

Программы специального назначения для преобразования файлов между различными соглашениями о новой строке включают в себя unix2dos и дос2юникс , mac2unix и unix2mac , mac2dos и дос2мак и подбросить . Команда tr доступна практически в каждой Unix-подобной системе и может использоваться для выполнения произвольных операций замены отдельных символов. Текстовый файл DOS/Windows можно преобразовать в формат Unix, просто удалив все символы ASCII. CR символы с

$  tr  -d '\r' <  входной файл  >  выходной файл 

или, если в тексте есть только Новые строки CR , преобразуя все CR переводы строк в НЧ с

$  tr  '\r' '\n' <  входной файл  >  выходной файл 

Те же задачи иногда выполняются с помощью awk , sed или Perl , если на платформе есть интерпретатор Perl:

$  awk   '{sub("$","\r\n");   printf("%s",$0);}'   inputfile   >   outputfile    # UNIX в DOS (добавление CR в ОС на базе Linux и BSD, не имеющих расширений GNU) 
 $  awk   '{gsub("\r","");   print;}'   входной файл   >   выходной файл                # DOS в UNIX (удаление CR в ОС Linux и BSD, не имеющих расширений GNU) 
 $  sed   -e   's/$/\r/'   входной файл   >   выходной файл                # UNIX в DOS (добавление CR в ОС Linux, использующих расширения GNU) 
 $  sed   -e   's/\r$//'   inputfile   >   выходной файл                # DOS в UNIX (удаление CR в ОС Linux, использующих расширения GNU) 
 $  perl   -pe   's/\r ?\n|\r/\r\n/g'   входной файл   >   выходной файл    # Преобразовать в DOS 
 $  perl   -pe   's/\r?\n|\r/\n/g'     входной файл   >   выходной файл    # Преобразовать в UNIX 
 $  perl   -pe   's/\r?\n|\r/\r/g'     входной файл   >   выходной файл    # Преобразование в старый Mac 

The Команда file может определить тип окончания строки:

$  файл   myfile.txt 
    myfile.txt: текст на английском языке в формате ASCII с ограничителями строк CRLF. 

Команду Unix egrep (расширенная grep) можно использовать для печати имен файлов Unix или DOS (при условии, что это только файлы в стиле Unix и DOS, а не классические файлы в стиле Mac OS):

$  egrep   -L   '\r\n'   myfile.txt   # показать файл стиля UNIX (завершение LF) 
 $  egrep   -l   '\r\n'   myfile.txt   # показать файл стиля DOS (завершение CRLF) 

Другие инструменты позволяют пользователю визуализировать символы EOL:

$  od   -a   myfile.txt 
  $  cat   -e   мойфайл.txt 
  $  cat   -v   мойфайл.txt 
  $  hexdump   -c   мойфайл.txt 
 

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

Два способа просмотра новой строки, оба из которых являются самосогласованными , заключаются в том, что новые строки либо разделяют строки, либо завершают строки . Если новая строка считается разделителем, после последней строки файла новой строки не будет. В некоторых программах возникают проблемы с обработкой последней строки файла, если она не завершается символом новой строки. С другой стороны, программы, которые ожидают использования новой строки в качестве разделителя, будут интерпретировать последнюю новую строку как начало новой (пустой) строки. И наоборот, если новая строка считается терминатором, ожидается, что все текстовые строки, включая последнюю, будут завершаться новой строкой. Если последняя последовательность символов в текстовом файле не является новой строкой, последняя строка файла может считаться неправильной или неполной текстовой строкой, либо файл может считаться неправильно усеченным.

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

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

RI ( U +008D ОБРАТНАЯ ПЕРЕДАЧА СТРОКИ , ISO/IEC 6429 8D, десятичное 141) используется для перемещения позиции печати на одну строку назад (путем обратной подачи бумаги или перемещением курсора дисплея на одну строку вверх), чтобы другие символы могли быть напечатаны поверх существующего текста. Это можно сделать, чтобы сделать их жирнее или добавить подчеркивания, зачеркивания или другие символы, например диакритические знаки .

Сходным образом, PLD ( U +008B ЧАСТИЧНАЯ СТРОКА ВПЕРЕД, десятичное 139) и PLU ( U +008C ЧАСТИЧНАЯ СТРОЧКА НАЗАД, десятичное число 140) может использоваться для продвижения или изменения позиции печати текста на некоторую долю вертикального межстрочного интервала (обычно половину). Их можно использовать в сочетании для нижних индексов (переворачивая, а затем переворачивая) и надстрочных индексов (путем переворачивания и затем перестановки), а также могут быть полезны для печати диакритических знаков.

См. также

• Конец файла
• Введите ключ
• Разрыв страницы

Внешние ссылки

• Ссылка на Юникод; см. параграф 5.8 в главе 5 стандарта Unicode 4.0 (PDF)
• «Символ новой строки [NEL]» .
• Головоломка «Конец линии»
• Счетчик строк на основе символа новой строки
• Понимание новых строк в Wayback Machine (архивировано 20 августа 2006 г.)
• «История конца строки»