Историческая причина разрыва линии на разных платформах

Ответ 1

DOS унаследовала конечные строки CR-LF (что вы вызываете \r\n, просто делая символы ascii явными) из CP/M. CP/M унаследовал его от различных операционных систем DEC, которые повлияли на дизайнера CP/M Гэри Килдалла.

CR-LF использовался так, чтобы телетайпные машины возвращали печатающую головку в левое поле (CR = возврат каретки), а затем переходили к следующей строке (LF = строка).

Ребята из Unix обрабатывали это в драйвере устройства и при необходимости переводили LF в CR-LF на выходе на устройства, которые в нем нуждались.

И как вы уже догадались, Mac OS X теперь использует LF.

Ответ 2

Действительно добавление в @Mark Harrison...

Люди, которые говорят вам, что Unix "просто выводит текст, указанный программистом", в то время как DOS не работает, неправильно. Есть также утверждения, что глупо для DOS для обозначения EOF, когда он видит символ EOF, что поднимает вопрос о том, что именно за символ EOF.

Нет никакого истинного соглашения для окончаний строк текстовой строки - только соглашения, специфичные для платформы. В конце концов, даже CR-LF, CR и LF не являются единственными соглашениями о конце линии, которые когда-либо использовались, и ASCII никогда не был единственным и единственным набором символов. Проблема заключается в стандартной библиотеке C и времени выполнения, что не абстрагировало эту зависящую от платформы детальную информацию. Другие языки третьего поколения (такие как Pascal и даже Basic) управляли им, по крайней мере, в некоторой степени. Из-за этого, когда компиляторы C были написаны для других платформ, для обеспечения совместимости с существующим исходным кодом и книгами необходимы хакеры библиотеки времени выполнения.

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

Взаимодействие ввода/вывода текста C в принципе аналогично тому, что CygWin делает сейчас, взломав время автономной работы Linux, а также можно ожидать в Windows. Там есть реальная история взлома вещей, чтобы превратить их в Unix-alikes, но потом также Wine, превратив Linux в Windows. Как ни странно, вы можете прочитать какую-то неуместную кривую конца Windows в Часто задаваемые вопросы CygWin (ссылка на Интернет-архив добавлена ​​в 2013 году - страница больше не существует). Возможно, это просто их чувство юмора, поскольку они в основном делают то, что критикуют, но в гораздо более масштабных масштабах; -)

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

[ РЕДАКТИРОВАТЬ Оказалось, что вышеизложенное требование неверно и никогда не было. std::endl буквально переводит на \n и флеш. \n - это точно то же самое \n, которое вы получаете в C - он имеет тенденцию получать вызванную "новую строку", но на самом деле это символ строки строки ASCII, который затем при необходимости переводится во время выполнения. Забавно, как ложные предположения могут настолько укорениться, что вы никогда их не зададите - в принципе, у С++ не было выбора делать то, что сделал C (кроме добавления большего количества слоев сверху) по соображениям совместимости, и это всегда должно было быть очевидным.]

Самый большой кусок вины от моего POV - это C, но C - не единственный проект, который не смог предвидеть его переход на другие платформы. Обвинение Билла Гейтса - просто орехи - все, что он сделал, это купить и отполировать вариант популярного CP/M. Действительно, это просто история - та же самая причина, почему мы не знаем, какие коды символов от 128 до 255 относятся к большинству текстовых файлов. Учитывая легкость справиться со всеми тремя соглашениями о конце строки, странно, что некоторые разработчики все еще настаивают на том, что "соглашение с моими платформами - это единственный истинный способ, и я буду принуждать его к вам, нравится это или нет".

Также - будет ли разделитель строк Unicode кодовым номером U + 2028 заменить все эти соглашения в будущих текстовых файлах?; -)

Ответ 3

Здесь довольно длинная статья о концах строк в википедии. Раздел "История" отвечает хотя бы на часть вашего вопроса: http://en.wikipedia.org/wiki/Newline#History

Ответ 4

Интересно отметить, что CRLF - это в значительной степени интернет-стандарт. То есть, почти каждый стандартный интернет-протокол, ориентированный на линию, использует CRLF. SMTP, POP, IMAP, NNTP и т.д. Тело письма состоит из строк, завершенных CRLF.