В конце раздела 4.1 RFC 959 , который касается стандартов протокола FTP, он относится к протоколу Telnet и коду Telnet eol.
Цитировать из RFC:
Протокол передачи файлов соответствует спецификациям протокола Telnet для всех соединений через управляющее соединение. Поскольку язык, используемый для связи Telnet, может быть согласованным вариантом, все ссылки в следующих двух разделах будут относиться к «языку Telnet» и соответствующему «Коду конца строки Telnet». В настоящее время можно считать, что они означают NVT-ASCII и <CRLF>
. Другие спецификации протокола Telnet не приводятся.
Затем в RFC 1123, раздел 3.3.1 ссылается на правильный конец строки как <CRLF>
:
Протокол Telnet определяет последовательность CR LF для обозначения «конец строки». Для ввода с терминала это соответствует нажатию клавиши завершения команды или «конца строки» на пользовательском терминале; на терминале ASCII это ключ CR, но он также может быть помечен как «Возврат» или «Ввод».
Затем идет дискуссия о неоднозначности концов строк на разных платформах. И говорит, что должны быть сделаны допуски для <CR NUL>
или \r\0
, но снова говорит, что <CRLF>
должно быть по умолчанию.
В статье в Википедии для Новые строки также обсуждается проблема и говорится:
Большинство текстовых интернет-протоколов (включая HTTP, SMTP, FTP, IRC и многие другие) требуют использования ASCII CR + LF (0x0D 0x0A) на уровне протокола, но рекомендуют, чтобы толерантные приложения также распознавали одиночный LF. На практике существует много приложений, которые вместо этого ошибочно используют символ новой строки C '\ n' (см. Раздел Newline на языках программирования ниже). Это приводит к проблемам при попытке установить связь с системами, придерживающимися более строгой интерпретации стандартов; Одной из таких систем является MTA qmail, который активно отказывается принимать сообщения от систем, которые отправляют пустой LF вместо требуемого CR + LF.
Так что придерживайтесь \r\n
, и все будет хорошо ...