Новая строка
Эта статья нуждается в дополнительных цитатах для проверки . ( февраль 2016 г. ) |
Символ новой строки (часто называемый концом строки , концом строки ( EOL ), следующей строкой ( NEL ) или разрывом строки ) — это управляющий символ или последовательность управляющих символов в спецификациях кодировки символов , таких как ASCII , EBCDIC , Unicode и т. д. Этот символ или последовательность символов, используется для обозначения конца строки текста и начала новой. [1]
История
[ редактировать ]В середине 1800-х годов, задолго до появления телетайпов и телетайпов, азбуки Морзе операторы или телеграфисты изобрели и использовали символы азбуки Морзе для кодирования форматирования текста с пробелами в формальных письменных текстовых сообщениях. В частности, Морзе прознак BT (мнемонический , ) разрыв текста представленный конкатенацией буквальных текстовых символов кода Морзе «B» и «T», отправленных без обычного межсимвольного интервала, используется в азбуке Морзе для кодирования и обозначения новой строки. или новый раздел в официальном текстовом сообщении.
Позже, в эпоху современных телетайпов , были разработаны стандартизированные коды управления набором символов, помогающие форматировать текст с пробелами. ASCII был разработан одновременно Международной организацией по стандартизации (ISO) и Американской ассоциацией стандартов (ASA), последняя из которых является предшественницей Американского национального института стандартов (ANSI). В период с 1963 по 1968 год проекты стандартов ISO поддерживали использование либо CR + НЧ или LF в качестве новой строки, в то время как проекты ASA поддерживают только CR + ЛФ .
Последовательность CR + LF обычно использовался во многих ранних компьютерных системах, в которых использовались телетайпы - обычно Teletype Model 33 ASR - в качестве консольного устройства, поскольку эта последовательность требовалась для позиционирования этих принтеров в начале новой строки. Разделение новой строки на две функции скрывало тот факт, что печатающая головка не могла вовремя вернуться из крайнего правого положения в начало следующей строки, чтобы напечатать следующий символ. Любой символ, напечатанный после CR часто печатался как пятно в середине страницы, пока печатающая головка все еще возвращала каретку в первое положение. «Решение заключалось в том, чтобы сделать новую строку двумя символами: CR, чтобы переместить каретку в первый столбец, и LF , чтобы переместить бумагу вверх». [2] Фактически, часто приходилось отправлять дополнительные символы заполнения — лишние 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, таком как Блокнот). [3] [4] ).
Представительство
[ редактировать ]Понятия возврата каретки (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 и другие. [5] |
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 [6] и ОС RISC вывод буферного текста [7] | ЛФ ЧР | 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 ) [8] как символ, сочетающий в себе функции перевода строки и возврата каретки. Эквивалентный символ Юникода (
0x85
) называется НЭЛ (Следующая строка). EBCDIC также имеет управляющие символы, называемые ЧР и LF , но числовое значение НФ ( 0x25 ) отличается от используемого ASCII ( 0x0А ). Кроме того, некоторые варианты EBCDIC также используют NL , но присвойте символу другой цифровой код. Однако в этих операционных системах используется файловая система на основе записей , в которой текстовые файлы хранятся как одна запись в строке. В большинстве форматов файлов терминаторы строки фактически не сохраняются. - Операционные системы серии CDC 6000 определяли новую строку как два или более шестибитных символа с нулевым значением в конце 60-битного слова. В некоторых конфигурациях символ с нулевым значением также определялся как символ двоеточия , в результате чего несколько двоеточий можно было интерпретировать как новую строку в зависимости от позиции.
- RSX-11 и OpenVMS также используют файловую систему на основе записей, в которой текстовые файлы хранятся как одна запись в строке. В большинстве форматов файлов терминаторы строк фактически не сохраняются, но служба управления записями может прозрачно добавлять терминатор к каждой строке, когда она извлекается приложением. Сами записи могут содержать одни и те же символы конца строки, что в зависимости от приложения можно считать особенностью или неудобством. RMS не только хранит записи, но также хранит метаданные о разделителях записей в разных битах, чтобы файл еще больше усложнил ситуацию (поскольку файлы могут иметь записи фиксированной длины, записи с префиксом счетчика или записи, заканчивающиеся определенным символом). ). Биты не являются общими, поэтому, хотя они могут указывать, что ЧР НЧ или НЧ или даже CR — это признак завершения строки, они не могут подменять какой-либо другой код.
- Фиксированная длина строки использовалась в некоторых ранних операционных системах для мэйнфреймов . Например, в такой системе неявный конец строки предполагался через каждые 72 или 80 символов. Символ новой строки не был сохранен. Если файл был импортирован из внешнего мира, строки короче длины строки нужно было дополнить пробелами, а строки длиннее длины строки нужно было обрезать. Это имитировало использование перфокарт , на которых каждая строка хранилась на отдельной карте, обычно с 80 столбцами на каждой карте, часто с порядковыми номерами в столбцах 73–80. Многие из этих систем добавляли символ управления кареткой в начало следующей записи; это может указывать на то, является ли следующая запись продолжением строки, начатой предыдущей записью, или новой строкой, или следует напечатать предыдущую строку (аналогично КР ). Зачастую это был обычный печатный знак типа
#
поэтому его нельзя было использовать в качестве первого символа в строке. Некоторые ранние построчные принтеры интерпретировали эти символы непосредственно в отправляемых им записях.
Протоколы связи
[ редактировать ]Многие протоколы связи имеют своего рода соглашение о новых линиях. В частности, протоколы, опубликованные Инженерной группой Интернета (IETF), обычно используют последовательность ASCII CRLF.
В некоторых старых протоколах за новой строкой может следовать символ контрольной суммы или четности.
Юникод
[ редактировать ]Стандарт Unicode определяет ряд символов, которые соответствующие приложения должны распознавать как ограничители строк: [9]
- ЛФ : Перевод строки, 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 . [10] Таким образом, это определено ECMA 48, [11] и распознается кодировками, соответствующими стандарту ISO/IEC 2022 (что эквивалентно ECMA 35). [12] Комплект управления C1 также совместим с ISO-8859-1 . [ нужна ссылка ] Подход, принятый в стандарте Unicode, позволяет двустороннему преобразованию сохранять информацию, в то же время позволяя приложениям распознавать все возможные типы терминаторов строки.
Распознавание и использование кодов новой строки больше, чем 0x7F ( В , ЛС и PS ) делается не часто. Это несколько байтов в UTF-8 , а код для NEL использовался как многоточие ( …
) символ в Windows-1252 . Например:
- ECMAScript принимает ЛС и PS как переносы строк, [13] но считает U + 0085 ( NEL ) пробел вместо разрыва строки. [14]
- JSON [15] позволяет ЛС и Символы PS внутри строк, тогда как ECMAScript до ES2019 [16] [17] рассматривал их как символы новой строки и, следовательно, незаконный синтаксис. [18]
- ЯМЛ [19] начиная с версии 1.2 больше не распознает их как разрывы строк, чтобы обеспечить совместимость с JSON .
- Блокнот Windows , текстовый редактор Microsoft Windows по умолчанию , не поддерживает ни один из В , ЛС или PS как переносы строк.
- gedit , текстовый редактор по умолчанию в GNOME среде рабочего стола , обрабатывает ЛС и ПС , но нет NEL , поскольку разрывы строк.
Специальные символы Юникода U + 2424 ( СИМВОЛ НОВОЙ СТРОКИ , 
), U + 23CE ( СИМВОЛ ВОЗВРАТА , ⏎
), U + 240D ( СИМВОЛ ВОЗВРАТА КАРЕТКИ , ␍
) и U + 240А ( СИМВОЛ ПЕРЕВОДА СТРОКИ , ␊
) представляют собой глифы , предназначенные для представления видимого пользователем символа читателю документа, и поэтому сами по себе не распознаются как перевод строки.
В языках программирования
[ редактировать ]Чтобы облегчить создание переносимых программ, языки программирования предоставляют некоторые абстракции для работы с различными типами последовательностей новой строки, используемыми в разных средах.
Язык программирования C предоставляет escape-последовательности. '\n' (новая строка) и '\r' (возврат каретки). Однако они не обязательно должны быть эквивалентны ASCII. НЧ и CR управляющие символы. Стандарт C гарантирует только две вещи:
- Каждая из этих escape-последовательностей соответствует уникальному числу, определяемому реализацией, которое может храниться в одном файле. значение символа .
- При записи в файл, узел устройства или сокет/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 , [20] и Haskell предоставляют одинаковую интерпретацию '\n' как C. C++ имеет альтернативную модель ввода-вывода , в которой манипулятор std::endl можно использовать для вывода новой строки (и очистки буфера потока).
Ява , PHP , [21] и Питон [22] предоставить Последовательность '\r\n' (для ASCII CR + ЛФ ). В отличие от C, они гарантированно представляют значения U+000D и U+000A соответственно.
Библиотеки ввода-вывода Java не транслируют их прозрачно в зависящие от платформы последовательности новой строки при вводе или выводе. Вместо этого они предоставляют функции для написания полной строки, которые автоматически добавляют собственную последовательность новой строки, и функции для чтения строк, которые принимают любой из ЧР , НЧ или CR + LF как терминатор линии (см. BufferedReader.readLine() ). Метод System.lineSeparator() можно использовать для получения базового разделителя строк.
Пример:
String eol = System.lineSeparator();
String lineColor = "Color: Red" + eol;
Python допускает «универсальную поддержку новой строки» при открытии файла для чтения, при импорте модулей и при выполнении файла. [23]
В некоторых языках созданы специальные переменные , константы и подпрограммы для облегчения перехода на новую строку во время выполнения программы. В некоторых языках, таких как PHP и Perl , двойные кавычки необходимы для выполнения escape-подстановки для всех escape-последовательностей, включая '\n' и '\ г' . В PHP, чтобы избежать проблем с переносимостью, последовательности новой строки следует выдавать с использованием константы PHP_EOL. [24]
Пример на С# :
string eol = Environment.NewLine;
string lineColor = "Color: Red" + eol;
string eol2 = "\n";
string lineColor2 = "Color: Blue" + eol2;
Проблемы с различными форматами новой строки
[ редактировать ]Различные соглашения о новой строке приводят к неправильному отображению текстовых файлов, которые были переданы между системами разных типов.
Текст в файлах, созданных с помощью программ, распространенных в 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 + ЛФ . [25]
Стандартный формат интернет-сообщений [26] для электронной почты указано: «CR и LF ДОЛЖНЫ встречаться только вместе как CRLF; они НЕ ДОЛЖНЫ появляться независимо в теле». Различия между реализациями SMTP в том, как они обрабатывают пустые символы LF и/или пустые CR, привели к атакам спуфинга SMTP, называемым «контрабанда SMTP». [27]
Протокол передачи файлов может автоматически преобразовывать символы новой строки в файлах, передаваемых между системами с различными представлениями новой строки, когда передача выполняется в «режиме ASCII». Однако передача двоичных файлов в этом режиме обычно приводит к катастрофическим результатам: любое появление последовательности байтов новой строки, которая в этом контексте не имеет семантики терминатора строки, а является всего лишь частью нормальной последовательности байтов, будет преобразовано в любое представление новой строки. другая система использует, фактически повреждая файл. FTP-клиенты часто используют некоторые эвристики (например, проверку расширений имен файлов ) для автоматического выбора двоичного режима или режима ASCII, но в конечном итоге пользователи должны убедиться, что их файлы передаются в правильном режиме. Если есть какие-либо сомнения относительно правильного режима, следует использовать двоичный режим, поскольку в этом случае файлы не будут изменены FTP, хотя они могут отображаться неправильно. [28]
Преобразование между форматами новой строки
[ редактировать ]Текстовые редакторы часто используются для преобразования текстового файла между различными форматами новой строки; большинство современных редакторов могут читать и записывать файлы, используя как минимум разные символы ASCII. ЧР / Соглашения ЛФ .
Например, редактор Vim может сделать файл совместимым с текстовым редактором «Блокнот» Windows. Внутри vim
:set fileformat=dos
:wq
Редакторы могут оказаться непригодными для преобразования файлов большего размера или массового преобразования большого количества файлов. Для файлов большего размера (в Windows NT) часто используется следующая команда:
D:\>TYPE unix_file | FIND /V "" > dos_file
Программы специального назначения для преобразования файлов между различными соглашениями о новой строке включают в себя unix2dos и дос2юникс , mac2unix и unix2mac , mac2dos и дос2мак и подбросить . [29] Команда tr доступна практически в каждой Unix-подобной системе и может использоваться для выполнения произвольных операций замены отдельных символов. Текстовый файл DOS/Windows можно преобразовать в формат Unix, просто удалив все символы ASCII. CR символы с
$ tr -d '\r' < inputfile > outputfile
или, если в тексте есть только Новые строки CR , преобразуя все CR переводы строк в НЧ с
$ tr '\r' '\n' < inputfile > outputfile
Те же задачи иногда выполняются с помощью awk , sed или Perl , если на платформе есть интерпретатор Perl:
$ 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 может определить тип окончания строки:
$ file myfile.txt
myfile.txt: ASCII English text, with CRLF line terminators
Команду Unix egrep (расширенная grep) можно использовать для печати имен файлов Unix или DOS (при условии, что это только файлы в стиле Unix и DOS, а не классические файлы в стиле Mac OS):
$ egrep -L '\r\n' myfile.txt # show UNIX style file (LF terminated)
$ egrep -l '\r\n' myfile.txt # show DOS style file (CRLF terminated)
Другие инструменты позволяют пользователю визуализировать символы EOL:
$ od -a myfile.txt
$ cat -e myfile.txt
$ cat -v myfile.txt
$ hexdump -c myfile.txt
Интерпретация
[ редактировать ]Два способа просмотра новой строки, оба из которых являются самосогласованными , заключаются в том, что новые строки либо разделяют строки, либо завершают строки. Если новая строка считается разделителем, после последней строки файла новой строки не будет. В некоторых программах возникают проблемы с обработкой последней строки файла, если она не завершается символом новой строки. С другой стороны, программы, которые ожидают использования новой строки в качестве разделителя, будут интерпретировать последнюю новую строку как начало новой (пустой) строки. И наоборот, если новая строка считается терминатором, ожидается, что все текстовые строки, включая последнюю, будут завершаться новой строкой. Если последняя последовательность символов в текстовом файле не является новой строкой, последняя строка файла может считаться неправильной или неполной текстовой строкой, либо файл может считаться неправильно усеченным.
В тексте, предназначенном в первую очередь для чтения людьми с использованием программного обеспечения, реализующего функцию переноса слов , символ новой строки обычно необходимо сохранять только в том случае, если требуется разрыв строки, независимо от того, поместится ли следующее слово в той же строке, например, между абзацами. и в вертикальных списках. Поэтому в логике текстовых редакторов и большинства текстовых редакторов символ новой строки используется в качестве разрыва абзаца и известен как «жесткий возврат», в отличие от «мягких возвратов», которые динамически создаются для реализации переноса слов и изменяются с каждым экземпляр дисплея. Во многих приложениях существует отдельный управляющий символ , называемый «ручной разрыв строки», для принудительного разрыва строки внутри одного абзаца. Символом ( ¶ управляющего символа жесткого возврата обычно является опора ), а для ручного разрыва строки обычно используется стрелка возврата каретки (↵).
Обратный и частичный перевод строки
[ редактировать ]RI ( U +008D ОБРАТНАЯ ПЕРЕДАЧА СТРОКИ , [30] ISO/IEC 6429 8D, десятичное 141) используется для перемещения позиции печати на одну строку назад (путем подачи бумаги в обратном направлении или путем перемещения курсора дисплея на одну строку вверх), чтобы другие символы могли быть напечатаны поверх существующего текста. Это можно сделать, чтобы сделать их жирнее или добавить подчеркивания, зачеркивания или другие символы, например диакритические знаки .
Сходным образом, PLD ( U +008B ЧАСТИЧНАЯ СТРОКА ВПЕРЕД, десятичное 139) и PLU ( U +008C ЧАСТИЧНАЯ СТРОЧКА НАЗАД, десятичное число 140) может использоваться для продвижения или изменения позиции печати текста на некоторую долю вертикального межстрочного интервала (обычно половину). Их можно использовать в сочетании для нижних индексов (переворачивая, а затем переворачивая) и надстрочных индексов (путем переворачивания и затем перестановки), а также могут быть полезны для печати диакритических знаков.
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ «Что такое новая строка?» . www.computerhope.com . Проверено 10 мая 2021 г.
- ^ Куаллин, Стив (2001). Улучшенный Vi — Vim (PDF) . Издательство Самс . п. 120 . ISBN 9780735710016 . Архивировано из оригинала (PDF) 8 апреля 2022 года . Проверено 4 января 2023 г.
- ^ Дакетт, Крис. «Блокнот Windows наконец-то понимает символы конца строки, используемые всеми остальными» . ЗДНет . Архивировано из оригинала 13 мая 2018 года . Проверено 4 января 2023 г.
[После десятилетий разочарований и необходимости загрузки настоящего текстового редактора для изменения одной строки в файле конфигурации из окна Linux Microsoft обновила Блокнот, чтобы он мог обрабатывать символы конца строки, используемые в Unix, Linux и среды MacOS.
- ^ Лопес, Мишель (8 мая 2018 г.). «Представляем поддержку расширенных окончаний строк в Блокноте» . Командная строка Windows . Архивировано из оригинала 6 апреля 2019 года . Проверено 4 января 2023 г.
Как и в случае любого изменения в давно используемом инструменте, существует вероятность того, что это новое поведение может не работать в ваших сценариях, или вы можете предпочесть отключить это новое поведение и вернуться к исходному поведению Блокнота. Для этого вы можете изменить [...ключи реестра...], чтобы настроить, как Блокнот обрабатывает вставку текста и какой символ EOL использовать при нажатии Enter/Return.
- ^ Кан-Грин, Уилл Гуаральди. «ASCII-диаграмма» . bluesock.org .
- ^ Брей, Эндрю С.; Диккенс, Адриан К.; Холмс, Марк А. (1983). Расширенное руководство пользователя микрокомпьютера BBC (PDF) . Кембриджский микрокомпьютерный центр. стр. 103, 104. ISBN. 978-0946827008 . Проверено 30 января 2019 г.
- ^ «Вывод символов» . Справочное руководство программиста RISC OS 3 . 3QD Developments Ltd., 3 ноября 2015 г. Проверено 18 июля 2018 г.
- ^ Справочная карта данных IBM System/360, публикация GX20-1703, Отдел обработки данных IBM, Уайт-Плейнс, Нью-Йорк
- ^ Хенингер, Энди (20 сентября 2013 г.). «UAX № 14: Алгоритм разрыва строки в Юникоде» . Консорциум Юникод.
- ^ «Набор управляющих символов C1 стандарта ISO 6429» (PDF) . ITSCJ. IPSJ. 1 октября 1983 года . Проверено 3 марта 2022 г.
- ^ Функции управления наборами кодированных символов (PDF) (Отчет). ЭКМА Интернешнл. Июнь 1991 года.
- ^ Структура кода символов и методы расширения (PDF) (Отчет) (6-е изд.). ЭКМА Интернешнл. Декабрь 1994 года.
- ^ «Спецификация языка ECMAScript 2019» . ЭКМА Интернешнл. Июнь 2019. 11.3 Терминаторы линий .
- ^ «Спецификация языка ECMAScript 2019» . ЭКМА Интернешнл. Июнь 2019 г. 11.2 Пробелы .
- ^ Брей, Тим (март 2014 г.). «Струны» . Формат обмена данными нотации объектов JavaScript (JSON) . сек. 7. дои : 10.17487/RFC7159 . РФК 7159 .
- ^ «Включить JSON (он же JSON ⊂ ECMAScript)» . Гитхаб . 22 мая 2018 г.
- ^ «Спецификация языка ECMAScript 2019» . ЭКМА Интернешнл. Июнь 2019 г. 11.8.4 Строковые литералы .
- ^ «Спецификация языка ECMAScript 2018» . ЭКМА Интернешнл. Июнь 2018 г. 11.8.4 Строковые литералы .
- ^ «5.4. Символы разрыва строки» . YAML не является языком разметки, версия 1.2.2 . 1 октября 2021 г.
- ^ «бин-режим» . Перл-документация . Портеры Perl 5.
- ^ «PHP: Строки — Руководство» . Руководство по PHP . Группа PHP.
- ^ «2. Лексический анализ» . Справочник по языку Python . Фонд Python.
- ^ «Что нового в Python 2.3» . Фонд программного обеспечения Python.
- ^ «PHP: Предопределенные константы — Руководство» . Руководство по PHP . Группа PHP.
- ^ Бернштейн, DJ «Голые НЧ в SMTP» .
- ^ Резник, Пит (апрель 2001 г.). Формат Интернет-сообщений . дои : 10.17487/RFC2822 . РФК 2822 .
- ^ Лонгин, Тимо (18 декабря 2023 г.). «Контрабанда SMTP — подмена электронных писем по всему миру» . SEC Consult .
- ^ Зейл, Стивен (19 января 2015 г.). «Передача файлов» . Университет Олд Доминион. Архивировано из оригинала 14 мая 2016 года.
В случае сомнений передавайте в двоичном режиме.
- ^ Сапп, Крейг Стюарт. «Преобразование текста ASCII между UNIX, Macintosh, MS-DOS» . Центр компьютерных исследований в области музыки и акустики. Архивировано из оригинала 9 февраля 2009 года.
- ^ «Элементы управления C1 и дополнение Latin-1» (PDF) . unicode.org . Проверено 13 февраля 2016 г.
Внешние ссылки
[ редактировать ]- Ссылка на Юникод; см. параграф 5.8 в главе 5 стандарта Unicode 4.0 (PDF)
- «Символ новой строки [NEL]» .
- Головоломка «Конец линии»
- Счетчик строк на основе символа новой строки
- Понимание новых строк в Wayback Machine (архивировано 20 августа 2006 г.)
- «История конца строки»