Из Википедии, бесплатной энциклопедии
  (Перенаправлено из перевода строки )
Перейти к навигации Перейти к поиску
Для использования в других целях, см Новая линия (значения) .

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

Новая строка (часто называемая окончанием строки , концом строки ( EOL ), переводом строки или разрывом строки ) - это управляющий символ или последовательность управляющих символов в спецификации кодировки символов (например, ASCII или EBCDIC ), которая используется для обозначения конца строки. строка текста и начало новой. [1] Некоторые текстовые редакторы устанавливают этот специальный символ при нажатии клавиши.↵ Enter

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

История [ править ]

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

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

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

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

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

Представление [ править ]

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

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

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

Юникод [ править ]

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

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

 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 ; он обычно отображается в Unicode NEL , 0x85 , который является управляющим символом в наборе элементов управления C1. [8] Таким образом, он определен в ECMA 48, [9] и распознается кодировками, соответствующими ISO / IEC 2022 (что эквивалентно ECMA 35). [10] Комплект управления C1 также совместим с ISO-8859-1 . [ необходима цитата ] Подход, принятый в стандарте Unicode, позволяет выполнять двустороннее преобразование с сохранением информации, в то же время позволяя приложениям распознавать все возможные типы терминаторов линии.

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

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

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

Последовательности выхода [ править ]

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

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

На языках программирования [ править ]

"\ n" перенаправляется сюда. Чтобы узнать об аналогичной нотации чисел, см. \ Nnn (значения) .

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

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

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

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

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

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

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

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

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

Пример:

 Строка  eol  =  System . lineSeparator ();  Строка  lineColor  =  "Цвет: Красный"  +  eol ;

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

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

Пример на C # :

 строка  eol  =  Environment . NewLine ;  строка  lineColor  =  "Цвет: Красный"  +  eol ;  строка  eol2  =  "\ n" ;  строка  lineColor2  =  "Цвет: синий"  +  eol2 ;

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

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

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

Для обозначения одинарного разрыва строки используются программы Unixline feed , шестнадцатеричное значение которого в ASCII равно 0a, в то время как большинство программ, общих для MS-DOS и Microsoft Windows, используют carriage return+ line feed, шестнадцатеричное значение которого в ASCII равно 0d 0a. В ASCII возврат каретки - это отдельный управляющий символ.

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

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

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

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

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

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

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

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

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

Найти замену новой строки [ править ]

Microsoft Word поддерживает абзац как специальный символ ^ p и ручной перенос строки как ^ l. Вы можете искать эти записи напрямую и заменять их напрямую, как эти символы, например, заменить ',' на ^ p ^ p заменяет запятые на двойной символ новой строки.

Документы Google поддерживают поиск символов новой строки, если вы выбрали «Сопоставить с использованием регулярных выражений» и «Сопоставить с выражением новой строки \ n». Это относится исключительно к сопоставлению текста и специальных символов, но не к замене. В настоящее время в Документах Google нет поддержки [26] для замены любых символов новой строки. Попытка заменить на \ n приводит к встраиванию этих двух символов в основной текст документа, а новые строки не добавляются. Пользователи продолжают спрашивать, поддерживается ли эта функция на форумах. [27]

Есть некоторые надстройки Google Docs, которые, как предполагается, поддерживают это [28], но ни одна из них не поддерживает замену новой строки [29] [30]

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

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

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

 : set  fileformat = dos : wq

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

D: \> ТИП unix_file | FIND / V ""  > dos_file

Программы специального назначения для преобразования файлов между различными соглашениями о новой строке включают unix2dos и dos2unix , mac2unix и unix2mac , mac2dos и dos2mac , а также flip . [31] Команда tr доступна практически во всех Unix-подобных системах и может использоваться для выполнения произвольных операций замены над отдельными символами. Текстовый файл 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);} ' inputfile> outputfile # UNIX в DOS (добавление CR в ОС Linux и BSD, не имеющих расширений GNU) $ awk ' {gsub ("\ r", ""); print;} ' inputfile> outputfile # DOS в UNIX (удаление CR в ОС Linux и BSD, не имеющих расширений GNU) $ sed -e ' s / $ / \ r / ' inputfile> outputfile # UNIX в DOS (добавление CR в ОС на базе Linux, использующей расширения GNU) $ sed -e 's / \ r $ //' inputfile> outputfile # DOS в UNIX (удаление CR в ОС на базе Linux, использующих расширения GNU) $ perl -pe's / \ r? \ n | \ r / \ r \ n / g' inputfile> outputfile # Конвертировать в DOS $ perl -pe 's / \ r? \ n | \ r / \ n / g' inputfile> outputfile # Конвертировать в UNIX $ perl -pe 's / \ r? \ N | \ r / \ r / g' inputfile> outputfile # Конвертировать в старый Mac

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

$ 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 myfile.txt $ hexdump -c myfile.txt

Интерпретация [ править ]

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

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

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

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

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

См. Также [ править ]

  • Управляющие символы каретки ASA
  • Коды управления C0 и C1
  • Конец файла
  • Линия голодать
  • Разрыв страницы
  • Возврат каретки
  • Клавиша ввода

Ссылки [ править ]

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

Внешние ссылки [ править ]

  • Ссылка на Unicode, см. Параграф 5.8 в главе 5 стандарта Unicode 4.0 (PDF)
  • Символ новой строки [NEL]
  • Конец линии головоломки
  • Понимание новых строк в Wayback Machine (архивировано 20 августа 2006 г.)
  • "Конец строки"