LINUX.ORG.RU
ФорумTalks

Обоснование применения в offtopic двух символов для обозначения \n


0

0

Собственно, интересует, тот тупорылый кретин, что придумал 0x0D 0x0A использовать вместо *никсового 0x0A хоть как-нить обосновывает этот идиотизм? Меня просто бесит, что при открытии файла в бинарке символов оказывается БОЛЬШЕ, чем при открытии в тексте!

Ответ на: комментарий от Deleted

> Древними принтерами, собственно.

И соответственно кривожопыми дровами к ним.

anonymous
()

С передачей текста связана одна давняя проблема: PC-системы (операционные системы D'OS и Windows) используют для обозначения конца строки символ возврата каретки '\г' к символ перевода строки ' \п', а системы Unix — только символ перевода строки. Возврат каретки — это артефакт, дошедший до нас от древнего устройства, называемого телетайпом, который имел операцию возврата каретки (CR) для возврата печатающего механизма в начало строки и отдельный оператор протяж-'ки на строку (LF — от Line Feed) для перевода этого механизма на следующую строку.

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

anonymous
()

>Меня просто бесит, что при открытии файла в бинарке символов оказывается БОЛЬШЕ, чем при открытии в тексте!

А еще у меня есть ручка и она немного скрипит... Лечись

iRunix ★★★★
()
Ответ на: комментарий от anonymous

Читал, что в конце 1970-х был принят стандарт не то ANSI, не то ISO, предписывавший на всех компьютерах употреблять CRLF. IBM делала PC в соответствии с ним.

acheron ★★★★
()
Ответ на: комментарий от anonymous

Не, пждит-те! Насколько я знаю, UNIX-ы всякие тоже работали по телетайпам, вон, vi (vim), emacs -- до сих пор такое могут, и поддерживают туеву хучу такого, что и в Политехническом музее не найдёшь. Как это в *nix-ах обходилось?

one_more_hokum ★★★
() автор топика
Ответ на: комментарий от iRunix

Не говорите, что мне делать, и я не скажу, куда вам идти...

one_more_hokum ★★★
() автор топика
Ответ на: комментарий от acheron

ЕМНИП

CR - unix

LF - mac

CRLF - рудимент для совместимости на уровне текстовиков

iRunix ★★★★
()

CRLF был раньше -- как уже и сказали из-за принтеров. Это была инновация использовать один символ..

dilmah ★★★★★
()
Ответ на: комментарий от one_more_hokum

>History

>ASCII was developed simultaneously by the ISO and the ASA, the predecessor organization to ANSI. During the period of 1963–1968, the ISO draft standards supported the use of either CR+LF or LF alone as a newline, while the ASA drafts supported only CR+LF. The Multics operating system began development in 1964 and used LF alone as its newline. Unix followed the Multics practice, and later systems followed Unix.

>The sequence CR+LF was in common use on many early computer systems that had adopted teletype machines, typically an ASR33, as a console device, because this sequence was required to position those printers at the start of a new line. On these systems, text was often routinely composed to be compatible with these printers, since the concept of device drivers hiding such hardware details from the application was not yet well developed; applications had to talk directly to the teletype machine and follow its conventions. The separation of the two functions concealed the fact that the print head could not return from the far right to the beginning of the next line in one-character time. That is why the sequence was always sent with the CR first. In fact, it was often necessary to send extra characters (extraneous CRs or NULs, which are ignored) to give the print head time to move to the left margin. Even after teletypes were replaced by computer terminals with higher baud rates, many operating systems still supported automatic sending of these fill characters, for compatibility with cheaper terminals that required multiple character times to scroll the display. MS-DOS, built upon a CP/M clone called 86-DOS (which Microsoft purchased and renamed), adopted CP/M's CR+LF; CP/M's use of CR+LF made sense for using computer terminals via serial lines. This convention was inherited by Microsoft's later Windows operating system.

Буржуйская кивипедия нашептала белке.

wfrr ★★☆
()
Ответ на: комментарий от wfrr

Ох! Тяжко мне... Счас встроенный переводчик включать придётся, а он глючит...

one_more_hokum ★★★
() автор топика
Ответ на: комментарий от anonymous

>ONLCR (XSI) Map NL to CR-NL on output.

Из man 3 termios. Фича posix, ещё с лохматых годов. Т.е. символ конца строки преобразуется драйвером последовательного порта в CRNL.

marsijanin ★★
()

> Меня просто бесит, что при открытии файла в бинарке символов оказывается БОЛЬШЕ, чем при открытии в тексте!

С добрым утром, родной, уникод на дворе.

Miguel ★★★★★
()
Ответ на: комментарий от anonymous

> (операционные системы D'OS и Windows) используют для обозначения конца строки символ возврата каретки '\г' к символ перевода строки ' \п', а системы Unix — только символ перевода строки

Были разные системы, и ВКПС использовался ещё до микрушников.

> артефакт, дошедший до нас от древнего устройства, называемого телетайпом

У любого принтера возврат каретки и перевод строки - это две разные операции. Для текстового терминала их так же различали.

anonymous
()
Ответ на: комментарий от one_more_hokum

Ещё раз с добрым утром, солнышко, уже прошло. И все вменяемые люди уже перешли.

Miguel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.