Кратко

  • Зрелый FTP закрепил восьмибитный байт передачи, но TYPE L отдельно объявлял обязательную ширину логического байта, границы которого могли проходить внутри октета.
  • Получатель выбирал удобное локальное размещение, однако преобразование должно было быть обратимым и возвращать тот же файл при тех же параметрах.
  • Image сохранял непрерывную битовую строку; Local сообщал ещё и её единицы. Успех команды не доказывал смысл данных, физическое резервирование или всеобщую поддержку выбранной ширины.

Транспортный счёт дал правильное число и неправильный вывод

Девять восьмибитных октетов содержат 72 бита. Это могут быть девять единиц по восемь, восемь по девять или два слова по 36. Контрольная сумма всей строки одинакова при любом таком разбиении. Она отвечает на вопрос, изменились ли биты, но не на вопрос, где находятся смысловые границы.

RFC 765 и RFC 959 приводят точный пример: две 36-битные машины могут использовать TYPE L 36. Первые четыре октета несут 32 бита первого слова. Первые четыре бита пятого заканчивают его, а оставшиеся четыре уже начинают второе.

Поэтому девять записей в сетевом журнале не означают девять объектов файла. Посредник способен безошибочно переписать каждый октет и разрушить представление, если забудет ширину или выровняет каждое слово по новой восьмибитной границе.

В 1971 году различия пытались перечислить

RFC 114 описывал ранний FTP через широкий набор интерпретируемых типов. В нём были варианты ASCII, EBCDIC, SIXBIT, десятичные, восьмеричные и шестнадцатеричные формы, целые числа с разными схемами знака, а также форматы плавающей точки IBM 360 и PDP-10. Для некоторых целых можно было указать ширину от одного до 255 бит.

Хост, принявший тип, мог преобразовать данные к удобному внутреннему виду. Машина с 36-битным словом по-разному упаковывала символы длиной семь, восемь, девять или шесть бит. Физическое слово не определяло единственный логический элемент.

Эта таблица не является синтаксисом более позднего RFC 959. Она показывает первоначальный масштаб задачи. Сеть связывала системы, которые не соглашались о длине слова, коде символов и формате чисел. Надёжно доставить биты было необходимо, но недостаточно.

Сначала менялась даже ширина байта на соединении

RFC 354 1972 года уже разделял тип представления, структуру файла и режим. Для ASCII и части печатных форм байт передачи имел восемь бит; Image и Local Byte могли использовать другой выбранный размер.

Сервер не обязан был принимать все размеры. Он мог реализовать только те, которые эффективно обрабатывал, хотя восемь бит рекомендовались как минимум. Возможность выразить параметр никогда не была свидетельством поддержки на каждом узле.

Преобразование Local Byte зависело от ширины передачи и конкретного хоста. Оно должно было быть обратимым и опубликованным. Пользователь отвечал за сохранение типа и размера, с которыми положил файл. После закрытия соединения эта информация не переставала быть частью происхождения.

Такая свобода расширяла матрицу совместимости. Понимание 36-битных слов внутри процессора не гарантировало, что реализация соединения умеет принимать 36-битные транспортные байты.

Восемь бит стали правилом дороги, а не правилом файла

RFC 765 сократил общую поверхность: байт передачи всегда равен восьми битам. RFC 959 сохранил отдельный логический размер файла. Кроме них, принимающая система могла иметь собственное физическое слово или блок хранения.

Команда TYPE L требует второй десятичный параметр. Значения по умолчанию нет. Без него получатель знает, как читать октеты линии, но не знает, через сколько бит восстанавливать единицы файла.

Логические байты упаковываются подряд, без привязки к границам транспортных октетов. Стандартизация линии не запретила единицы в девять, 18 или 36 бит. Она перенесла упаковку к краям и избавила среду передачи от необходимости знать каждую архитектуру.

Граница TCP-сегмента тоже ничего не добавляет. Поток может быть разделён сетью в любом месте. Протокол представления, а не пакетизация, сообщает логическую сетку.

Число 36 ограничивает, но не объясняет

L 36 разрешает восстановить две границы в 72-битной строке. Оно не сообщает, являются ли слова целыми, числами с плавающей точкой, командами процессора или элементами другого формата. Из него не следуют знак, экспонента, внутренний порядок или правила приложения.

Это не делает параметр пустым. Приложение не сможет применить свой формат, если промежуточный слой уже уничтожил 36-битное разбиение. FTP сохраняет одно необходимое условие интерпретации, не присваивая себе всю интерпретацию.

Положительный ответ TYPE тоже имеет узкий смысл. Он показывает, что сервер принял режим для последующей передачи. Он не доказывает, что локальная программа понимает значения или что данные уже надёжно записаны.

Дополнение разрешалось только в конце

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

Место делает дополнение устранимым. Ноль в середине может быть исходным содержимым. В конце файла или записи получатель сопоставляет окончание с активной шириной и вычисляет остаток.

Одной последовательности нулей в дампе недостаточно, чтобы назвать её padding. Нужны TYPE, логический размер, структура и подтверждённый конец. Без них наблюдатель видит только восьмибитные контейнеры.

36 бит можно хранить в 64, не превращая файл в 64-битный

RFC 959 рассматривает 32-битный хост, получающий 36-битные логические значения. Он может поместить каждое в 64-битное двойное слово, чтобы удобно обрабатывать. Неиспользованные 28 бит относятся к местной раскладке, а не к переданному содержимому.

Свобода ограничена обратимостью. При хранении и извлечении с теми же параметрами сервер обязан вернуть идентичный файл. Реализация должна достаточно ясно описывать своё преобразование.

Условие о тех же параметрах существенно. Для файла, положенного как TYPE L 36 и запрошенного как TYPE L 8, общей гарантии идентичности нет. Архив, сохранивший только 64-битные ячейки и потерявший правило, позже не сможет доказать, какие биты были содержимым, а какие локальным пространством.

Image и Local могли совпасть в результате, но не в утверждении

Image рассматривает файл как непрерывные биты, упакованные в октеты. Получатель сохраняет непрерывность. Если его устройство требует выравнивания, нулевое дополнение допускается лишь в конце файла или записи и должно быть узнаваемым при обратном чтении.

Local добавляет объявленную единицу. Она даёт основание преобразовывать каждую группу для локальной машины. В некоторых архитектурах результат совпадает с Image, но доказательная роль команд различна.

RFC 1123 говорит, что на восьмибитной машине TYPE L 8 эквивалентен Image. Между двумя машинами со словами m бит TYPE L m должен давать тот же эффект. Но Image сам по себе не разрешает получателю придумать m. Совпадение результата не заменяет отсутствующего объявления.

Обязательный минимум был намеренно ограничен

RFC 1123 требует поддержки TYPE I и TYPE L 8. Машина, чья память организована в слова m бит, где m не кратно восьми, может дополнительно поддерживать TYPE L m.

Это право, а не универсальная обязанность. Синтаксис способен записать 36, но конкретный сервер вправе его отвергнуть. Такой ответ доказывает предел представления в сессии, а не сетевую аварию, нехватку диска или порчу файла.

Клиент выбирает: перейти на Image, заранее преобразовать к общему формату или не продолжать. Молчаливая замена 36 на восемь устраняет ошибку команды ценой исчезновения исходной единицы.

Другие оси файла не растворились в TYPE

FTP отдельно задавал представление, структуру и режим передачи. Логическая ширина не определяет конец записи, страницу, Stream, Block или Compressed. Она не говорит, какой restart marker безопасен и когда данные стали устойчивыми.

Опубликованная статья о FTP restart разбирала, почему маркер мог быть не простым номером байта: получатель кодировал состояние своего преобразования. TYPE L задаёт единицу для этого процесса. Маркер задаёт точку возобновления. Один не восстанавливает другой.

ALLO считает уже определённые единицы

ALLO мог сообщать ожидаемый объём в логических байтах. Их размер поступал из активного представления. Команда выделения не создавала 36-битную границу, а положительный ответ не обязательно означал физическое резервирование.

Поэтому статья про ALLO исследует соседний, но иной объект: связала ли оценка ресурсы. Здесь вопрос в том, что было единицей оценки и как она переживала восьмибитную линию. Достаточный объём не исправляет неверные границы, а верные границы не гарантируют резерв.

Реестр хранит имя команды, а не карту памяти

Реестр IANA команд и расширений FTP записывает TYPE как Representation Type и указывает спецификацию. Это свидетельство назначенного имени и ссылки.

Он не показывает, какие размеры принимает конкретный сервер, как тот хранит их и как часто они используются сейчас. Для этого нужны сведения реализации, ответ сессии, обратное чтение с теми же параметрами и проверка приложения.

Чем скромнее линия, тем ценнее контекст на краях

FTP прошёл от большого каталога форматов через переменные байты соединения к фиксированной восьмибитной перевозке и отдельной логической ширине. Общий слой стал проще, не объявляя машины одинаковыми.

Эта скромность требует сохранять на краях то, что линия не толкует. Биты, тип, ширина, структура и версия локального преобразования вместе образуют восстанавливаемый объект. Девять неповреждённых октетов могут всё равно быть неполным архивом двух 36-битных слов.

Источники и границы

Основание составляют RFC 114, RFC 354, RFC 765, RFC 959, RFC 1123 и реестр IANA. Они устанавливают исторические и нормативные правила, но не измеряют современное внедрение, поведение продукта, физическую запись или прикладной смысл 36-битного значения.