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

Question

Почему DOS / Windows и Mac решили использовать и для окончания строки вместо ?Было ли это просто результатом попытки "отличаться" от Unix?

И теперь, когда Mac OS X является Unix (-подобной), Apple переключилась на из ?

Answer 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.

Answer 2

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

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

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

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

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

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

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

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

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

Answer 3

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

Answer 4

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