Как узнать символ перевода строки в текстовом файле

Обновлено: 07.07.2024

Notepad в windows 10 начал понимать юниксовый перевод строки, а не только формат Windows.

С проблемой «каши» вместо удобочитаемого текста десятилетиями сталкивались те, кто пытался открыть в среде Windows текстовые документы, подготовленные на других операционных системах. Теперь же всё в одночасье изменяется. И это изменение столь же мало, сколь и эпично по своим практическим результатам и идеологическим последствиям. Microsoft вновь пытается играть в кросс-интеграцию и поддержку открытых стандартов.

Долгие годы Windows Блокнот мог нормально отображать только те текстовые документы, которые содержали символы начала новой строки в формате Windows End of Line (EOL) — «возврат каретки» (CR) и «подача на строку» (LF). На деле это приводило к тому, что Notepad не смог правильно отобразить содержимое текстовых файлов, созданных в Unix, Linux и macOS, где в качестве признака конца строки использовался только символ LF.

Например, вот скриншот Notepad, пытающегося отобразить содержимое текстового файла Linux .bashrc, который содержит только символы Unix LF EOL:

image

А вот скриншот недавно обновленного «Блокнота», отображающего содержимое того же самого файла UNIX / Linux .bashrc, но с правильными переносами:

image


Обратите внимание, что строка состояния указывает обнаруженный формат EOL текущего открытого файла.

Так же для гибкого управления новой возможностью в разделе реестра [HKEY_CURRENT_USER\Software\Microsoft\Notepad] вводятся два дополнительных ключа:

image

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

Что мы можем узнать о проблеме из Википедии

Исторически на механических пишущих машинках был рычаг, который возвращал каретку к левому краю страницы и прокручивал вал, подвигая бумагу вверх на строку. На телетайпах и более поздних алфавитно-цифровых печатающих устройствах (АЦПУ) вместо каретки была головка, в лазерных принтерах она перестала быть материальной, но в термине возврат каретки всё это продолжали называть кареткой, чтобы его не менять. На телетайпах возврат каретки и подачу строки разделили, откуда традиция представления перевода строки как CR+LF перешла и к текстовым файлам.

Системы, основанные на ASCII или совместимом наборе символов, используют или LF (перевод строки, 0x0A), или CR (возврат каретки, 0x0D) по отдельности, или последовательность CR+LF. Эти названия основаны на командах принтера: перевод строки означает, что одна строка на бумаге должна быть перенесена при печати, а возврат каретки означает, что каретка печатающего устройства должна вернуться к началу текущей строки.

  • LF (U+000A): англ. line feed — подача строки <ПС>;
  • CR (U+000D): англ. carriage return — возврат каретки <ВК>;
  • NEL (U+0085): англ. next line — переход на следующую строку;
  • LS (U+2028): англ. line separator — разделитель строк;
  • PS (U+2029): англ. paragraph separator — разделитель абзацев.

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

Юникод старается примирить эту разницу, уравнивая CR, LF и CR+LF, однако вступает в противоречие с наследуемым им ASCII при трактовке последовательности LF+CR, не предварённой CR: согласно ASCII это один перевод строки, а согласно Юникоду — два.

Новая строка или перевод строки или перенос строки или разделитель строк или символ конца строки (EOL) в информатике — специальный управляющий символ (или их последовательность), служащий для завершения или разделения строк в текстовых данных.

Содержание

Общие сведения

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

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

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

Терминология

Но́вая строка́ (калька с англ. new line зд. «с новой строки») — понятие логического форматирования текста в текстовом процессоре, браузере и т.д. Как правило (хотя и не обязательно), новая строка начинает запись текста с нового абзаца (англ. hard return ). Новая строка подразумевает обязательный перевод строки в соответственном месте текста, хотя «переводы строки» вообще имеются и внутри абзаца.

Возвра́т каре́тки (англ. Carriage Return, CR ) — управляющий символ 0x0D, при выводе которого курсор перемещается к левому краю поля, не меняя высоту. Этот управляющий символ вводится клавишей «Enter». Будучи записан в файле, в отдельности рассматривается как перевод строки только в системах Macintosh.

Пода́ча строки́ (от англ. Line Feed, LF «подача [бумаги] на строку») — управляющий символ ASCII 0x0A, при выводе которого «курсор» перемещается на следующую строку.

В случае принтера это означает сдвиг бумаги вверх, в случае дисплея — сдвиг курсора вниз если ещё осталось место, и прокрутку текста вверх если курсор находится на нижней строке.

Возвращается ли при этом курсор к левому краю или нет, зависит от реализации.

Таким образом, вывод последовательности CR LF в семантике терминала гарантирует действие «создание новой строки».

Терминалы (и их эмуляторы) могут также проводить различные преобразования символов (например, «LF» → «CR LF», «CR» → «CR LF») при вводе и выводе текста.

Представления и реализации

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

Краткие сведения

Системы, основанные на LF (от англ. Line feed (перевод строки), 0x0A) или CR (от англ. Carriage Return, 0x0D) по отдельности, или CR следует за LF (CR+LF, 0x0D 0x0A); см. ниже историческую причину для соглашения CR+LF. Эти символы основаны на командах принтера: перевод строки означает, что одна строка на бумаге должна быть перенесена при печати, а возврат каретки означает, что каретка печатающего устройства должна вернуться к началу текущей строки.

Основные цифровые реализации

  • LF (ASCII 0x0A) — используется в Unix и Unix-подобных операционнах системах (Linux, Xenix, Mac OS X, BeOS,
    • CR (ASCII 0x0D) — используется в машинах Commodore, Apple II, Mac OS до версии 9 и — используется в DEC CP/M, MP/M, OS/2, Microsoft Windows, Symbian OS, протоколах internet.

    Перевод строки в Unicode

    По стандарту, любое совместимое с Уникодом приложение должно воспринимать как перевод строки каждый из нижеследующих символов:

    • LF: подача строки, U+000A
    • CR: возврат каретки, U+000D
    • NEL: новая строка, U+0085
    • FF: новая страница, U+000C
    • LS: разделитель строк, U+2028
    • PS: разделитель абзацев, U+2029

    Последовательность CR LF (U+000D U+000A) надлежит воспринимать как один перевод строки (а не два) [1] .

    Трудности

    • Юникод старается примирить разницу представлений перевода строки, уравнивая CR, LF и CR LF, однако вступает в противоречие с наследуемым ASCII при трактовке LF CR, не предварённых CR: согласно ASCII это один перевод строки, а согласно Юникоду — два. Вероятно, Юникод сделал ставку на не существовавшие в ASCII разделители строк и абзацев, но они не прижились.
    • В зависимости от того, считать ли перевод строки её частью (завершителем) или не считать (считая их разделителем), после последней строки его ставят или нет. При пренебрежении одной из этих возможностей во время декодирования конец текста может стать неожиданным или появится лишняя пустая строка. Для сравнения, точка с запятой в Си команды завершает, а в Паскале разделяет.

    История

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

    На АЦПУ функции возврата каретки (головки) и подачи новой строки были разделены, откуда традиция представления перевода строки как CR LF перешла и к текстовым файлам.

    Некоторые исторические цифровые системы записи текста (например, при помощи перфокарт) вообще не использовали символ перевода строки.

    Примечания

    Дополнительные источники

    • The Unicode reference, see paragraph 5.8 in Chapter 5 of the Unicode 4.0 standard (PDF) - software for Unix that converts to and from DOS newlines : a Windows shell extension that is able to convert multiple files from DOS to UN*X (and vice-versa) line endings right from the context menu.

    Wikimedia Foundation . 2010 .

    Полезное

    Смотреть что такое "Перенос строки" в других словарях:

    Перенос в математических формулах — разбивка не умещающейся в строку мат. формулы на части по строкам. Разделять формулы на части по строкам надо в первую очередь на знаках отношения между левой и правой частями формул (=, ≈, <, >, ≤, ≥): во вторую на отточии, знаках сложения … Издательский словарь-справочник

    Перенос в химических формулах — разбивка не умещающейся в строку хим. формулы на части по строкам. Допускается только в случае крайней необходимости. Разбивку рекомендуется делать на знаках направления реакции (стрелках), знаках равенства, равновесия , взаимодействия (+ или –) … Издательский словарь-справочник

    Перенос слова — Перенос в типографике разрыв части текста (слова, формулы и т. п.), при котором её начало оказывается на одной строке, а конец на другой. Содержание 1 Перенос слов 1.1 Знаки переноса 1.2 Осложненный перенос … Википедия

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

    Содержание

    Терминология

    Таким образом, вывод последовательности CR+LF в семантике терминала гарантирует действие «создание новой строки».

    Терминалы (и их эмуляторы) могут также проводить различные преобразования символов (например, LF → CR+LF, CR → CR+LF) при вводе и выводе текста.

    В ASCII

    Системы, основанные на ASCII или совместимом наборе символов, используют или LF (перевод строки, 0x0A), или CR (возврат каретки, 0x0D) по отдельности, или последовательность CR+LF; см. ниже историческую причину для соглашения CR+LF. Эти названия основаны на командах принтера: перевод строки означает, что одна строка на бумаге должна быть перенесена при печати, а возврат каретки означает, что каретка печатающего устройства должна вернуться к началу текущей строки.

    В Юникоде

    По стандарту, любое совместимое с Юникодом приложение должно воспринимать как перевод строки каждый из нижеследующих символов:

    Последовательность CR+LF (U+000D U+000A) надлежит воспринимать как один перевод строки, а не два [1] .

    Трудности

    Разница представлений

    Последняя строка

    Даже в современных изданиях ОС UNIX и Linux отсутствие перевода строки в конце системных конфигурационных файлов приводит к тому, что последняя строка не учитывается [2] , а вроде правильно составленный файл не работает, представляясь головоломкой для пользователя, не предупреждённого об этой самобытной особенности. См. раздел Конец строки.

    История

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

    На механических пишущих машинках был рычаг, который возвращал каретку к левому краю страницы и прокручивал вал, подвигая бумагу вверх на строку. На телетайпах и более поздних алфавитно-цифровых печатающих устройствах (АЦПУ) вместо каретки была головка, в лазерных принтерах она перестала быть материальной, но в термине возврат каретки всё это продолжали называть кареткой, чтобы его не менять. На телетайпах возврат каретки и подачу строки разделили, откуда традиция представления перевода строки как CR+LF перешла и к текстовым файлам.

    Конец строки

    Абзац

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

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

    Недавно я читал книгу «Компьютерные системы: архитектура и программирование. Взгляд программиста». Там, в главе про систему ввода-вывода Unix, авторы упомянули о том, что в конце файла нет особого символа EOF .


    Если вы читали о системе ввода-вывода Unix/Linux, или экспериментировали с ней, если писали программы на C, которые читают данные из файлов, то это заявление вам, вероятно, покажется совершенно очевидным. Но давайте поближе присмотримся к следующим двум утверждениям, относящимся к тому, что я нашёл в книге:

    1. EOF — это не символ.
    2. В конце файлов нет некоего особого символа.

    EOF — это не символ

    Почему кто-то говорит или думает, что EOF — это символ? Полагаю, это может быть так из-за того, что в некоторых программах, написанных на C, можно найти код, в котором используется явная проверка на EOF с использованием функций getchar() и getc() .

    Это может выглядеть так:


    Если заглянуть в справку по getchar() или getc() , можно узнать, что обе функции считывают следующий символ из потока ввода. Вероятно — именно это является причиной возникновения заблуждения о природе EOF . Но это — лишь мои предположения. Вернёмся к мысли о том, что EOF — это не символ.

    А что такое, вообще, символ? Символ — это самый маленький компонент текста. «A», «a», «B», «b» — всё это — разные символы. У символа есть числовой код, который в стандарте Unicode называют кодовой точкой. Например — латинская буква «A» имеет, в десятичном представлении, код 65. Это можно быстро проверить, воспользовавшись командной строкой интерпретатора Python:


    Или можно взглянуть на таблицу ASCII в Unix/Linux:


    Выясним, какой код соответствует EOF , написав небольшую программу на C. В ANSI C константа EOF определена в stdio.h , она является частью стандартной библиотеки. Обычно в эту константу записано -1 . Можете сохранить следующий код в файле printeof.c , скомпилировать его и запустить:


    Скомпилируем и запустим программу:


    У меня эта программа, проверенная на Mac OS и на Ubuntu, сообщает о том, что EOF равняется -1 . Есть ли какой-нибудь символ с таким кодом? Тут, опять же, можно проверить коды символов в таблице ASCII, можно взглянуть на таблицу Unicode и узнать о том, в каком диапазоне могут находиться коды символов. Мы же поступим иначе: запустим интерпретатор Python и воспользуемся стандартной функцией chr() для того, чтобы она дала бы нам символ, соответствующий коду -1 :


    Как и ожидалось, символа с кодом -1 не существует. Значит, в итоге, EOF , и правда, символом не является. Переходим теперь ко второму рассматриваемому утверждению.

    В конце файлов нет некоего особого символа

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

    Возьмём простой текстовый файл, helloworld.txt, и выведем его содержимое в шестнадцатеричном представлении. Для этого можно воспользоваться командой xxd :


    Как видите, последний символ файла имеет код 0a . Из таблицы ASCII можно узнать о том, что этот код соответствует символу nl , то есть — символу новой строки. Это можно выяснить и воспользовавшись Python:


    Так. EOF — это не символ, а в конце файлов нет некоего особого символа. Что же такое EOF ?

    Что такое EOF?

    EOF (end-of-file) — это состояние, которое может быть обнаружено приложением в ситуации, когда операция чтения файла доходит до его конца.

    Взглянем на то, как можно обнаруживать состояние EOF в разных языках программирования при чтении текстового файла с использованием высокоуровневых средств ввода-вывода, предоставляемых этими языками. Для этого напишем очень простую версию cat , которая будет называться mcat . Она побайтно (посимвольно) читает ASCII-текст и в явном виде выполняет проверку на EOF . Программу напишем на следующих языках:

    • ANSI C
    • Python 3
    • Go
    • JavaScript (Node.js)

    ANSI C

    Начнём с почтенного C. Представленная здесь программа является модифицированной версией cat из книги «Язык программирования C».


    Вот некоторые пояснения, касающиеся вышеприведённого кода:

    • Программа открывает файл, переданный ей в виде аргумента командной строки.
    • В цикле while осуществляется копирование данных из файла в стандартный поток вывода. Данные копируются побайтово, происходит это до тех пор, пока не будет достигнут конец файла.
    • Когда программа доходит до EOF , она закрывает файл и завершает работу.

    Python 3

    В Python нет механизма явной проверки на EOF , похожего на тот, который имеется в ANSI C. Но если посимвольно читать файл, то можно выявить состояние EOF в том случае, если в переменной, хранящей очередной прочитанный символ, будет пусто:


    Запустим программу и взглянём на возвращаемые ей результаты:


    Вот более короткая версия этого же примера, написанная на Python 3.8+. Здесь используется оператор := (его называют «оператор walrus» или «моржовый оператор»):


    Запустим этот код:

    В Go можно явным образом проверить ошибку, возвращённую Read(), на предмет того, не указывает ли она на то, что мы добрались до конца файла:

    JavaScript (Node.js)

    В среде Node.js нет механизма для явной проверки на EOF . Но, когда при достижении конца файла делается попытка ещё что-то прочитать, вызывается событие потока end.

    Низкоуровневые системные механизмы

    Как высокоуровневые механизмы ввода-вывода, использованные в вышеприведённых примерах, определяют достижение конца файла? В Linux эти механизмы прямо или косвенно используют системный вызов read(), предоставляемый ядром. Функция (или макрос) getc() из C, например, использует системный вызов read() и возвращает EOF в том случае, если read() указывает на возникновение состояния достижения конца файла. В этом случае read() возвращает 0 . Если изобразить всё это в виде схемы, то получится следующее:


    Получается, что функция getc() основана на read() .

    Напишем версию cat , названную syscat , используя только системные вызовы Unix. Сделаем мы это не только из интереса, но и из-за того, что это вполне может принести нам какую-то пользу.

    Вот эта программа, написанная на C:


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

    Читайте также: