Новая линия - Newline

Новая строка вставлена ​​между словами "Hello" и "world"

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

При отображении (или печати) текстовый файл, этот управляющий символ заставляет текстовый редактор отображать следующие символы в новой строке.

История

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

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

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

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

В Мультики операционная система начала разработку в 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 код символа в дополнение к CR и LF коды. Unicode, помимо предоставления ASCII CR и LF коды управления, также предоставляет "следующую строку" (NEL) контрольный код, а также контрольные коды для маркеров "разделитель строк" и "разделитель абзацев".

Программные приложения и операционная система представление новой строки одним или двумя управляющие символы
Операционная системаКодировка символовСокращениешестнадцатеричный ценитьдекабрь ценитьПоследовательность выхода
Unix и Unix-подобный системы (Linux, macOS, FreeBSD, AIX, Xenix, так далее.), Мультики, BeOS, Amiga, ОС RISC, и другие[2]ASCIILF0A10 п
Майкрософт Виндоус, ДОС (MS-DOS, ПК DOS, так далее.), Atari TOS, DEC ТОП-10, РТ-11, CP / M, МП / м, OS / 2, ОС Symbian, Palm OS, Амстрад КТК, и большинство других ранних операционных систем, отличных от Unix и IBMCR LF0D 0A13 10 г п
Коммодор 8-битные машины (C64, C128 ), Желудь BBC, ZX Spectrum, TRS-80, Apple II серии, Оберон, то классическая Mac OS, Массачусетский технологический институт Лисп-машина и ОС-9CR0D13р
QNX реализация до POSIX (версия <4)RS1E30\036
Желудь BBC[3] и ОС RISC буферный вывод текста.[4]LF CR0A 0D10 13 п г
8-битные машины AtariATASCII9B155
IBM системы мэйнфреймов, включая z / OS (OS / 390 ) и i5 / OS (OS / 400 )EBCDICNL1521\025
ZX80 и ZX81 (Домашние компьютеры от Sinclair Research Ltd )используется определенный набор символов, отличных от ASCIIНОВАЯ ЛИНИЯ76118
  • EBCDIC системы - в основном IBM системы мэйнфреймов, включая z / OS (OS / 390 ) и i5 / OS (OS / 400 )-использовать NL (Новая линия, 0x15)[5] как символ, сочетающий в себе функции перевода строки и возврата каретки. Эквивалентный символ Юникода (0x85) называется NEL (Следующая строка). EBCDIC также имеет управляющие символы, называемые CR и LF, но числовое значение LF (0x25) отличается от используемого в ASCII (0x0A). Кроме того, некоторые варианты EBCDIC также используют NL но присвоить символу другой числовой код. Однако эти операционные системы используют файловая система на основе записей, в котором текстовые файлы хранятся по одной записи в строке. В большинстве форматов файлов терминаторы строки фактически не сохраняются.
  • Операционные системы для CDC 6000 серии определил новую строку как два или более шестибитных символа с нулевым знаком в конце 60-битного слова. Некоторые конфигурации также определяют нулевой символ как двоеточие символ, в результате чего несколько двоеточий можно интерпретировать как новую строку в зависимости от позиции.
  • RSX-11 и OpenVMS также используйте файловую систему на основе записей, в которой текстовые файлы хранятся по одной записи в строке. В большинстве форматов файлов терминаторы строки фактически не сохраняются, но Услуги по управлению записями средство может прозрачно добавлять терминатор к каждой строке, когда он извлекается приложением. Сами записи могут содержать одни и те же символы конца строки, что может рассматриваться либо как особенность, либо как неприятность в зависимости от приложения. RMS не только хранит записи, но также хранит метаданные о разделителях записей в разных битах для файла, что еще больше усложняет ситуацию (поскольку файлы могут иметь записи фиксированной длины, записи с префиксом счетчика или записи, завершаемые определенным символом ). Биты не были общими, поэтому, хотя они могли указать, что CRLF или же LF или даже CR был символом конца строки, он не мог заменить какой-либо другой код.
  • Фиксированная длина линии использовался некоторыми ранними мэйнфрейм операционные системы. В такой системе, например, подразумевается неявный конец строки каждые 72 или 80 символов. Символ новой строки не был сохранен. Если файл был импортирован из внешнего мира, строки короче, чем длина строки, должны были быть дополнены пробелами, а строки длиннее, чем длина строки, должны были быть усечены. Это имитировало использование перфокарты, где каждая строка хранилась на отдельной карте, обычно с 80 столбцами на каждой карте, часто с порядковыми номерами в столбцах 73–80. Многие из этих систем добавили управляющий символ каретки к началу следующий записывать; это может указывать на то, была ли следующая запись продолжением строки, начатой ​​предыдущей записью, или новой строкой, или должна перекрывать предыдущую строку (аналогично CR). Часто это был обычный печатный символ, например # это, таким образом, не может использоваться как первый символ в строке. Некоторые ранние линейные принтеры интерпретировали эти символы непосредственно в отправленных им записях.

Unicode

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

 LF:    Перевод строки, U + 000A
 VT:    Вертикальная табуляция, U + 000B
 FF:    Подача формы, U + 000C
 CR:    Возврат каретки, U + 000D
CR+LF: CR (U + 000D) с последующим LF (U + 000A)
 NEL:   Следующая строка, U + 0085
 LS:    Разделитель строк, U + 2028
 PS:    Разделитель абзацев, U + 2029

Это может показаться слишком сложным по сравнению с таким подходом, как преобразование всех ограничителей строки в один символ, например LF. Однако Unicode был разработан для сохранения всей информации при преобразовании текстового файла из любой существующей кодировки в Unicode и обратно. Следовательно, Unicode должен содержать символы, включенные в существующие кодировки. NL входит в EBCDIC с кодом 0x15, и часто сопоставляется с NEL, который является управляющим символом в контрольном наборе C1.[7] Как таковой, он определен в ECMA 48,[8] и распознается кодировками, соответствующими ISO / IEC 2022 (что эквивалентно ECMA 35).[9] Комплект управления C1 также совместим с ISO-8859-1.[нужна цитата ] Подход, принятый в стандарте Unicode, позволяет выполнять двустороннее преобразование с сохранением информации, в то же время позволяя приложениям распознавать все возможные типы терминаторов линии.

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

  • ECMAScript принимает LS и PS как перенос строки,[10] но считает U + 0085 (NEL) пробел вместо переноса строки.[11]
  • Windows 10 не относится ни к одному из NEL, LS, или же PS как разрывы строк в текстовом редакторе по умолчанию, Блокнот.
  • gedit, по умолчанию Текстовый редактор из ГНОМ среда рабочего стола, лечит LS и PS как символы новой строки, но не для NEL.
  • JSON[12] позволяет LS и PS символов внутри строк, а в ECMAScript до ES2019[13][14] обрабатывает их как новые строки и, следовательно, недопустимый синтаксис.[15]
  • YAML[16] больше не распознает их как особые, начиная с версии 1.2, чтобы быть совместимыми с JSON.

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

Последовательности выхода

An escape-последовательность представляет собой комбинацию символов, которая не представляет собой текста; вместо отображения (в виде текста) предполагается, что он будет перехвачен программой и должна выполняться специальная функция. Escape-последовательности также используются для обработки (установка, поиск, замена и т. Д.) Специальных символов.

Последовательности выхода
Особый персонажПоследовательность выходаИспользован ...Примеры
перевод строки пPerl, Vim, ...Vim: :% s /} /} r t / g = заменить каждый символ '}' на '} перевод строки табулятора' во всем файле
возврат кареткир
табулятор т

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

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

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

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

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

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

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

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

Ява, PHP,[18] и Python[19] предоставить ' r n' последовательность (для ASCII CR+LF). В отличие от C, они гарантированно представляют значения U + 000D и U + 000A, соответственно.

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

Пример:

   Нить эол = Система.lineSeparator();   Нить lineColor = "Красный цвет" + эол;

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

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

Пример в C #:

   нить эол = Среда.Новая линия;   нить lineColor = "Красный цвет" + эол;      нить eol2 = " п";   нить lineColor2 = "Цвет синий" + eol2;

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

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

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

Чтобы обозначить одинарный разрыв строки, Unix программы используют перевод строки, шестнадцатеричное значение которого в ASCII равно 0a, в то время как большинство программ, общих для MS-DOS и Майкрософт Виндоус использовать возврат каретки+перевод строки, шестнадцатеричное значение которого в ASCII равно 0d 0a. В ASCII, возврат каретки является отдельным управляющим символом.

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

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

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

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

Проблему трудно обнаружить, потому что некоторые программы правильно обрабатывают иностранные символы новой строки, а другие - нет. Например, компилятор может дать сбой из-за непонятных синтаксических ошибок, даже если исходный файл выглядит правильно при отображении на консоль или в редактор. В Unix-подобной системе команда кошка -v myfile.txt отправит файл на стандартный вывод (обычно терминал) и сделает ^ M visible, что может быть полезно для отладки. Современные текстовые редакторы обычно распознают все разновидности CR+LF новые строки и позволяют пользователям переходить между разными стандартами. Веб-браузеры обычно также могут отображать текстовые файлы и веб-сайты, использующие разные типы символов новой строки.

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

Самый текстовый Интернет протоколы (включая HTTP, SMTP, FTP, IRC и многие другие) предписывают использование ASCII CR+LF (' r n', 0x0D 0x0A) на уровне протокола, но рекомендуется, чтобы терпимые приложения распознавали одиночные LF (' n', 0x0A) также. Несмотря на продиктованный стандарт, многие приложения ошибочно используют C escape-последовательность новой строки ' n' (LF) вместо правильной комбинации escape-последовательностей возврата каретки и новой строки ' r n' (CR+LF) (см. раздел Новая строка в языках программирования над). Это случайное использование неправильных escape-последовательностей приводит к проблемам при попытке установить связь с системами, придерживающимися более строгой интерпретации стандартов вместо предлагаемой толерантной интерпретации. Одна из таких нетерпимых систем - это qmail агент по пересылке почты который активно отказывается принимать сообщения от систем, отправляющих голые LF вместо необходимого CR+LF.[22]

Стандартный формат интернет-сообщений[23] для состояний электронной почты: CR и LF ДОЛЖНЫ встречаться только вместе как CRLF; они НЕ ДОЛЖНЫ появляться в теле независимо друг от друга.

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

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

Текстовые редакторы часто используются для преобразования текстового файла между различными форматами новой строки; большинство современных редакторов могут читать и записывать файлы, используя как минимум другой ASCII CR/LF соглашения. Например, редактор Vim может сделать файл совместимым с текстовым редактором Windows Notepad. Внутри vim

 :набор формат файла=dos:wq

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

D: >ТИП unix_file | НАЙТИ / V "" > dos_file

Специальные программы для преобразования файлов между различными соглашениями о новой строке включают: unix2dos и dos2unix, mac2unix и unix2mac, mac2dos и dos2mac, и кувырок.[25]В tr команда доступна практически на каждом Unix-подобный system и может использоваться для выполнения произвольных операций замены над отдельными символами. Текстовый файл DOS / Windows можно преобразовать в формат Unix, просто удалив все ASCII CR персонажи с

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

или, если в тексте есть только CR новые строки, преобразовав все CR новые строки в LF с

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

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

$ awk '{sub ("$", " r  n"); printf ("% s", $ 0);} ' входной файл> выходной файл # UNIX в DOS (добавление CR в ОС Linux и BSD, не имеющих расширений GNU)$ awk '{gsub (" r", ""); Распечатать;}' входной файл> выходной файл # DOS в UNIX (удаление CR в ОС Linux и BSD, не имеющих расширений GNU)$ sed -e 's / $ /  r /' входной файл> выходной файл # UNIX в DOS (добавление CR в ОС на базе Linux, использующих расширения GNU)$ sed -e 's /  r $ //' входной файл> выходной файл # 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

В файл команда может определить тип окончания строки:

 $ файл 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 myfile.txt$ hexdump -c myfile.txt

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

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

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

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

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

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

Смотрите также

Рекомендации

  1. ^ Куаллин, Стив (2001). Улучшено Vi - Vim (PDF). Sams. п. 120. ISBN  9780735710016.
  2. ^ «Таблица ASCII».
  3. ^ Брей, Эндрю С.; Диккенс, Адриан Ч .; Холмс, Марк А. Расширенное руководство пользователя микрокомпьютера BBC (PDF). С. 103, 104. ISBN  978-0946827008. Получено 30 января 2019.
  4. ^ "Справочное руководство для программистов RISC OS 3". Получено 18 июля 2018.
  5. ^ Справочная карта данных IBM System / 360, публикация GX20-1703, IBM Data Processing Division, White Plains, NY
  6. ^ "UAX # 14: Алгоритм разрыва строки Unicode". www.unicode.org.
  7. ^ «Набор управляющих символов C1 по ISO 6429» (PDF). 1 октября 1983 г.
  8. ^ «Функции управления для кодированных наборов символов» (PDF). Июнь 1991 г.
  9. ^ «Структура кода символов и методы расширения, 6-е издание» (PDF). Декабрь 1994 г.
  10. ^ «Спецификация языка ECMAScript 2019». ECMA International. Июнь 2019. 11.3 Терминаторы линии.
  11. ^ «Спецификация языка ECMAScript 2019». ECMA International. Июнь 2019. 11.2 Пробел.
  12. ^ «Формат обмена данными JavaScript Object Notation (JSON)». Март 2014 г. 7. Струны. RFC  7159.
  13. ^ «Подложить JSON (он же JSON ⊂ ECMAScript)». GitHub. 22 мая 2018.
  14. ^ «Спецификация языка ECMAScript 2019». ECMA International. Июнь 2019. 11.8.4 Строковые литералы.
  15. ^ «Спецификация языка ECMAScript 2018». ECMA International. Июнь 2018 г. 11.8.4 Строковые литералы.
  16. ^ «YAML не является языком разметки (YAML ™) версии 1.2». yaml.org. 5.4. Символы разрыва строки.
  17. ^ "binmode - perldoc.perl.org". perldoc.perl.org.
  18. ^ «PHP: строки - Руководство». www.php.net.
  19. ^ «Лексический анализ - документация Python v3.0.1». docs.python.org.
  20. ^ «Что нового в Python 2.3».
  21. ^ «PHP: предопределенные константы - Руководство». www.php.net.
  22. ^ "cr.yp.to".
  23. ^ «RFC 2822 - формат Интернет-сообщений». Инженерная группа Интернета.
  24. ^ "Передача файла". Если есть сомнения, переводите в двоичный режим.
  25. ^ «Преобразование текста ASCII между UNIX, Macintosh, MS-DOS». Архивировано из оригинал 9 февраля 2009 г.
  26. ^ «Элементы управления C1 и приложение Latin-1» (PDF). unicode.org. Получено 13 февраля 2016.

внешняя ссылка