Символ новой строки (часто называемый концом строки , концом строки ( EOL ), следующей строкой ( NEL ) или разрывом строки ) — это управляющий символ или последовательность управляющих символов в спецификациях кодировки символов , таких как ASCII , EBCDIC , Unicode и т. д. Этот символ или последовательность символов, используется для обозначения конца строки текста и начала новой. [1]
В середине 1800-х годов, задолго до появления телетайпов и телетайпов, операторы азбуки Морзе или телеграфисты изобрели и использовали знаки азбуки Морзе для кодирования форматирования текста пробелов в формальных письменных текстовых сообщениях. В частности, прознак Морзе BT (мнемонический разрыв текста), представленный конкатенацией буквальных текстовых символов кода Морзе «B» и «T», отправленных без обычного межсимвольного интервала, используется в азбуке Морзе для кодирования и обозначения новой строки . или новый раздел в официальном текстовом сообщении.
Позже, в эпоху современных телетайпов , были разработаны стандартизированные коды управления набором символов, помогающие форматировать текст с пробелами. ASCII был разработан одновременно Международной организацией по стандартизации (ISO) и Американской ассоциацией по стандартизации (ASA), причем последняя является предшественницей Американского национального института стандартов (ANSI). В период с 1963 по 1968 год проекты стандартов ISO поддерживали использование либо .mw-parser-output .monospaced{font-family:monospace,monospace}CR+LF, либо LF в качестве новой строки, в то время как проекты ASA поддерживали только CR + НФ .
Последовательность CR + LF обычно использовалась во многих ранних компьютерных системах, которые использовали телетайпы - обычно Teletype Model 33 ASR - в качестве консольного устройства, поскольку эта последовательность требовалась для позиционирования этих принтеров в начале новой строки. Разделение новой строки на две функции скрывало тот факт, что печатающая головка не могла вовремя вернуться из крайнего правого положения в начало следующей строки, чтобы напечатать следующий символ. Любой символ, напечатанный после CR , часто печатался как пятно в середине страницы, пока печатающая головка все еще возвращала каретку в первое положение. «Решение заключалось в том, чтобы сделать новую строку двумя символами: CR , чтобы переместить каретку в первый столбец, и LF , чтобы переместить бумагу вверх». [2] На самом деле часто приходилось отправлять дополнительные символы заполнения — лишние CR или NUL — которые игнорируются, но дают печатающей головке время переместиться к левому полю. Многие ранние видеодисплеи также требовали нескольких символов для прокрутки дисплея.
В таких системах приложениям приходилось напрямую взаимодействовать с телетайпом и следовать его соглашениям, поскольку концепция драйверов устройств , скрывающих такие детали оборудования от приложения, еще не была хорошо развита. Поэтому текст обычно составлялся для удовлетворения потребностей телетайпов. Большинство миникомпьютерных систем DEC использовали это соглашение. CP/M также использовал его для печати на тех же терминалах, что и миникомпьютеры. Отсюда MS-DOS (1981) приняла CR + LF CP/M для обеспечения совместимости, и это соглашение было унаследовано более поздней операционной системой Microsoft Windows .
Операционная система Multics начала разработку в 1964 году и в качестве новой строки использовала только LF . Multics использовала драйвер устройства для преобразования этого символа в любую последовательность, необходимую принтеру (включая дополнительные символы заполнения ), и одиночный байт был более удобен для программирования. То, что кажется более очевидным выбором — CR — не использовалось, поскольку CR предоставлял полезную функцию наложения одной строки на другую для создания эффектов жирного шрифта , подчеркивания и зачеркивания . Возможно, что еще более важно, использование только LF в качестве терминатора линии уже было включено в проекты будущего стандарта ISO/IEC 646 . Unix последовала практике Multics, а позже Unix-подобные системы последовали за Unix. Это создавало конфликты между Windows и Unix-подобными операционными системами , в результате чего файлы, созданные в одной операционной системе, не могли быть правильно отформатированы или интерпретированы другой операционной системой (например, сценарий оболочки UNIX , написанный в текстовом редакторе Windows, таком как Блокнот [3] [4 ] ] ).
Понятия возврата каретки (CR) и перевода строки (LF) тесно связаны и могут рассматриваться как по отдельности, так и вместе. В физических носителях , таких как пишущие машинки и принтеры , для создания новой строки на странице необходимы две оси движения: «вниз» и «поперек» . Хотя при проектировании машины (пишущей машинки или принтера) они должны рассматриваться по отдельности, абстрактная логика программного обеспечения может объединить их как одно событие. Вот почему новая строка в кодировке символов может быть определена как и объединена в одну (обычно называемую или ).CRLFCR+LFCRLF
Некоторые наборы символов предоставляют отдельный код символа новой строки. Например, EBCDIC предоставляет код символа NL в дополнение к кодам CR и LF . Unicode , помимо предоставления управляющих кодов ASCII CR и LF , также предоставляет управляющий код «следующей строки» ( NEL ), а также управляющие коды для маркеров «разделитель строк» и «разделитель абзацев».
0x85#Многие протоколы связи имеют своего рода соглашение о новых линиях. В частности, протоколы, опубликованные Инженерной группой Интернета (IETF), обычно используют последовательность ASCII CRLF.
В некоторых старых протоколах за новой строкой может следовать символ контрольной суммы или четности.
Стандарт Unicode определяет ряд символов, которые соответствующие приложения должны распознавать как ограничители строк: [9]
Хотя это может показаться слишком сложным по сравнению с таким подходом, как преобразование всех символов конца строки в один символ (например, LF ), поскольку Unicode предназначен для сохранения всей информации при преобразовании текстового файла из любой существующей кодировки в Unicode и обратно ( туда и обратно) . целостность ), Unicode должен проводить такие же различия между разрывами строк, создаваемыми другими кодировками.
Например: NL является частью EBCDIC , который использует код 0x15 ; обычно он отображается в Unicode NEL , 0x85 , который является управляющим символом в наборе элементов управления C1 . [10] Таким образом, он определен стандартами ECMA 48, [11] и распознается кодировками, соответствующими стандарту ISO/IEC 2022 (что эквивалентно ECMA 35). [12] Комплект управления C1 также совместим с ISO-8859-1 . [ нужна цитация ] Подход, принятый в стандарте Unicode, позволяет двустороннему преобразованию сохранять информацию, в то же время позволяя приложениям распознавать все возможные типы терминаторов строки.
Распознавание и использование кодов новой строки больше 0x7F ( NEL , LS и PS ) выполняется нечасто. Они состоят из нескольких байтов в UTF-8 , а код NEL использовался как символ многоточия ( ) в Windows-1252 . Например:…
Специальные символы Юникода U+2424 ( СИМВОЛ НОВОЙ СТРОКИ , ), U+23CE ( СИМВОЛ ВОЗВРАТА , ), U+240D ( СИМВОЛ ВОЗВРАТА КАРЕТКИ , ) и U+240A ( СИМВОЛ ПЕРЕВОДА СТРОКИ , ) являются глифами , предназначенными для представления видимый пользователю символ для читателя документа и, таким образом, не распознаются как новая строка.⏎␍␊
Чтобы облегчить создание переносимых программ, языки программирования предоставляют некоторые абстракции для работы с различными типами последовательностей новой строки, используемыми в разных средах.
Язык программирования C предоставляет escape-последовательности '\n' (новая строка) и '\r' (возврат каретки). Однако они не обязательно должны быть эквивалентны управляющим символам ASCII LF и CR . Стандарт C гарантирует только две вещи:
На платформах 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 , [20] и Haskell , обеспечивают ту же интерпретацию '\n' , что и C. C++ имеет альтернативную модель ввода-вывода , где манипулятор std::endl может использоваться для вывода новой строки (и очищает буфер потока).
Java , PHP , [21] и Python [22] предоставляют последовательность '\r\n' (для ASCII CR + LF ). В отличие от C, они гарантированно представляют значения U+000D и U+000A соответственно.
Библиотеки ввода-вывода Java не транслируют их прозрачно в зависящие от платформы последовательности новой строки при вводе или выводе. Вместо этого они предоставляют функции для записи полной строки, которые автоматически добавляют собственную последовательность новой строки, и функции для чтения строк, которые принимают любой из CR , LF или CR + LF в качестве признака конца строки (см. BufferedReader.readLine()). Метод System.lineSeparator () можно использовать для получения базового разделителя строк.
Пример:
Строка eol = Система . Разделитель строк (); String lineColor = "Цвет: Красный" + eol ; Python допускает «универсальную поддержку новой строки» при открытии файла для чтения, при импорте модулей и при выполнении файла. [23]
В некоторых языках созданы специальные переменные , константы и подпрограммы для облегчения перехода на новую строку во время выполнения программы. В некоторых языках, таких как PHP и Perl , двойные кавычки необходимы для выполнения escape-подстановки для всех escape-последовательностей, включая '\n' и '\r' . В PHP, чтобы избежать проблем с переносимостью, последовательности новой строки следует выдавать с использованием константы PHP_EOL. [24]
Пример на С# :
строка eol = Окружающая среда . Новая линия ; строка lineColor = "Цвет: Красный" + eol ; строка eol2 = "\n" ; строка lineColor2 = «Цвет: Синий» + 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 + LF ( '\r\n' , 0x0D 0x0A ) на уровне протокола, но рекомендуют, чтобы толерантные приложения распознавали одиночный LF. ( '\n' , 0x0A ). Несмотря на предписанный стандарт, многие приложения ошибочно используют escape-последовательность новой строки C '\n' ( LF ) вместо правильной комбинации escape-последовательностей возврата каретки и escape-последовательностей новой строки '\r\n' ( CR + LF ) (см. раздел Новая строка в языки программирования выше). Такое случайное использование неправильных escape-последовательностей приводит к проблемам при попытке взаимодействия с системами, придерживающимися более строгой интерпретации стандартов вместо предлагаемой толерантной интерпретации. Одной из таких нетерпимых систем является агент передачи почты qmail , который активно отказывается принимать сообщения от систем, отправляющих голый LF вместо требуемого CR + LF . [25]
Стандартный формат интернет-сообщений [26] для электронной почты гласит: «CR и LF ДОЛЖНЫ встречаться только вместе как CRLF; они НЕ ДОЛЖНЫ появляться независимо в теле». Различия между реализациями SMTP в том, как они обрабатывают пустые символы LF и/или пустые CR, привели к атакам спуфинга SMTP, называемым «контрабанда SMTP». [27]
Протокол передачи файлов может автоматически преобразовывать символы новой строки в файлах, передаваемых между системами с различными представлениями новой строки, когда передача выполняется в «режиме ASCII». Однако передача двоичных файлов в этом режиме обычно приводит к катастрофическим результатам: любое появление последовательности байтов новой строки, которая в этом контексте не имеет семантики терминатора строки, а является всего лишь частью нормальной последовательности байтов, будет преобразовано в любое представление новой строки. другая система использует, фактически повреждая файл. FTP-клиенты часто используют некоторые эвристики (например, проверку расширений имен файлов ) для автоматического выбора двоичного режима или режима ASCII, но в конечном итоге пользователи должны убедиться, что их файлы передаются в правильном режиме. Если есть какие-либо сомнения относительно правильного режима, следует использовать двоичный режим, поскольку в этом случае файлы не будут изменены FTP, хотя они могут отображаться неправильно. [28]
Текстовые редакторы часто используются для преобразования текстового файла между различными форматами новой строки; большинство современных редакторов могут читать и записывать файлы, используя по крайней мере различные соглашения ASCII CR / LF .
Например, редактор Vim может сделать файл совместимым с текстовым редактором «Блокнот» Windows. Внутри vim
: установить формат файла = dos : вкРедакторы могут оказаться непригодными для преобразования файлов большего размера или массового преобразования большого количества файлов. Для файлов большего размера (в Windows NT/2000/XP) часто используется следующая команда:
D:\> ВВЕДИТЕ unix_file | НАЙТИ /V "" > dos_fileПрограммы специального назначения для преобразования файлов между различными соглашениями о переводе строки включают unix2dos и dos2unix , mac2unix и unix2mac , mac2dos и dos2mac и Flip . [29] Команда 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 > выходной файл # DOS в UNIX (удаление CR в ОС Linux и BSD, не имеющих расширений GNU) $ sed -e 's/$/\r/' inputfile > выходной файл # UNIX в DOS (добавление CR в ОС Linux, использующих расширения GNU) $ sed -e 's/\r$//' inputfile > выходной файл # DOS в UNIX (удаление CR в ОС Linux, использующих расширения GNU) $ perl -pe 's/\r ?\n|\r/\r\n/g' входной файл > выходной файл # Преобразовать в DOS $ perl -pe 's/\r?\n|\r/\n/g' входной файл > выходной файл # Преобразовать в UNIX $ perl -pe 's/\r?\n|\r/\r/g' входной файл > выходной файл # Преобразование в старый Mac Команда 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 $ cat -v myfile.txt $ hexdump -c myfile.txtДва способа просмотра новой строки, оба из которых являются самосогласованными , заключаются в том, что новые строки либо разделяют строки, либо завершают строки . Если новая строка считается разделителем, после последней строки файла новой строки не будет. В некоторых программах возникают проблемы с обработкой последней строки файла, если она не завершается символом новой строки. С другой стороны, программы, которые ожидают использования новой строки в качестве разделителя, будут интерпретировать последнюю новую строку как начало новой (пустой) строки. И наоборот, если новая строка считается терминатором, ожидается, что все текстовые строки, включая последнюю, будут завершаться новой строкой. Если последняя последовательность символов в текстовом файле не является новой строкой, последняя строка файла может считаться неправильной или неполной текстовой строкой, либо файл может считаться неправильно усеченным.
В тексте, предназначенном в первую очередь для чтения людьми с использованием программного обеспечения, реализующего функцию переноса слов , символ новой строки обычно необходимо сохранять только в том случае, если требуется разрыв строки, независимо от того, поместится ли следующее слово в той же строке, например, между абзацами . и в вертикальных списках. Поэтому в логике текстовых редакторов и большинства текстовых редакторов символ новой строки используется в качестве разрыва абзаца и известен как «жесткий возврат», в отличие от «мягких возвратов», которые динамически создаются для реализации переноса слов и изменяются с каждым экземпляр дисплея. Во многих приложениях существует отдельный управляющий символ , называемый «ручным разрывом строки», для принудительного разрыва строки внутри одного абзаца. Символом управляющего символа жесткого возврата обычно является опора ( ¶), а для ручного разрыва строки обычно используется стрелка возврата каретки (↵).
RI ( U +008D REVERSE LINE FEED , [30] ISO/IEC 6429 8D, десятичное 141) используется для перемещения позиции печати на одну строку назад (путем обратной подачи бумаги или путем перемещения курсора дисплея на одну строку вверх), чтобы другие символы могут быть напечатаны поверх существующего текста. Это можно сделать, чтобы сделать их жирнее или добавить подчеркивания, зачеркивания или другие символы, например диакритические знаки .
Аналогичным образом, PLD ( U +008B PARTIAL LINE FORWARD, десятичное 139) и PLU ( U +008C PARTIAL LINE BACKWARD, десятичное 140) могут использоваться для продвижения или изменения положения печати текста на некоторую долю вертикального межстрочного интервала (обычно половину ). Их можно использовать в сочетании для нижних индексов (переворачивая, а затем переворачивая) и надстрочных индексов (путем переворачивания и затем перестановки), а также могут быть полезны для печати диакритических знаков.
[После] десятилетий разочарований и необходимости загрузки настоящего текстового редактора для изменения одной строки в файле конфигурации из окна Linux Microsoft обновила Блокнот, чтобы он мог обрабатывать символы конца строки, используемые в Unix, Linux и среды MacOS.
Как и в случае любого изменения в давно используемом инструменте, существует вероятность того, что это новое поведение может не работать в ваших сценариях, или вы можете предпочесть отключить это новое поведение и вернуться к исходному поведению Блокнота.
Для этого вы можете изменить [... ключи реестра...], чтобы настроить, как Блокнот обрабатывает вставку текста и какой символ EOL использовать при нажатии Enter/Return.
В случае сомнений передавайте в двоичном режиме.