Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

Хотя текст ASCII является стандартным, компьютеры интерпретируют его по-разному из-за различия в кодах конца строки. Системы Unix используют для этого , компьютеры PC — , a Macintosh — .

Для устранения этих различий FTP превращает локальный текстовый файл ASCII в формат NVT, а приемник преобразует NVT ASCII в собственный локальный формат. Например, если текстовый файл копируется с системы Unix на PC, все коды концов строк (в Unix — ) при получении файла на PC нужно преобразовать в .

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

С пересылки текстов ASCII легко переключиться на двоичный образ данных. В текстовом пользовательском интерфейсе для этого служит команда binary , а в графическом — командная кнопка binary (двоичные данные). Клиент меняет тип пересылаемых данных командой TYPE I , передаваемой по управляющему соединению.

Что произойдет, если пользователь забудет переключить тип данных с ASCII на двоичный при копировании двоичного файла? Хорошие реализации FTP предупредят, что задана ошибочная операция, и позволят до начала пересылки файла изменить тип данных. К сожалению, многие реализации идут еще дальше и "помогают" изменять все двоичные байты, которые выглядят как символы конца строк (исправляя их на специальные заполнители или полностью удаляя их из текста). Некоторые действительно плохие реализации все же начинают пересылку файла и аварийно завершаются в середине выполнения такой операции.

В FTP поддерживаются две структуры (ранее использовалась также страничная структура для файлов DEC TOPS-20, сейчас устаревшая):

■ Файловая структура , соответствующая неструктурированному файлу, который рассматривается как последовательность байт.

■ Структура записей , которая применяется для файлов, состоящих из последовательности записей.

Более распространена файловая структура , которая применяется по умолчанию. Перейти на структуру записей можно стандартной командой STRU R , пересылаемой по управляющему соединению.

Режим пересылки и структура файла определяют, как будут форматированы данные для обмена по соединению. Существуют три режима пересылки: stream (поток), block (блочный режим) и compressed (сжатые данные).

■ В режиме потока и файловой структуры файл передается как поток байт. FTP возлагает на TCP обеспечение целостности данных и не включает в данные никаких заголовков или разделителей. Единственным способом указания на конец файла будет нормальное завершение соединения для данных.

■ Для режима потока и структуры записей каждая запись отделяется 2-байтовым управляющим кодом конца записи (End Of Record — EOR), а конец файла отмечается символами конца файла (End Of File — EOF). EOR кодируется как X'FF 01, a EOF — X'FF 02. Для последней записи файла EOR и EOF записываются как X'FF 03. Если файл содержит байт данных из одних единиц, то такой байт представляется при пересылке как X'FF FF.

■ В блочном режиме файл пересылается как последовательность блоков данных. Каждый блок начинается 3-байтовым заголовком (см. рис. 14.4).

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

Рис. 14.4.Формат заголовка блочного режима пересылки FTP

Блок может содержать целую запись, или в записи объединяются несколько блоков. Дескриптор содержит:

■ Флаг End Of Record для идентификации границы записи

■ Флаг End Of File, который указывает, является ли блок последним при пересылке файла

■ Флаг Restart Marker (маркер перезапуска), указывающий, содержит ли данный блок текстовую строку, которую можно использовать для указания точки перезапуска после неудачной пересылки файла в более поздней точке