Кратко

  • COMPRESSED различал буквальные данные, повтор любого байта и зависящее от представления заполнение; только заполнение не передавало значение.
  • TYPE поставлял пропущенное: пробел для ASCII/EBCDIC и нулевой байт для Image/Local byte.
  • Полная запись канала MODE C без истории параметров может не определять восстановленный файл однозначно.

После счётчика ничего не должно было быть

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

Поэтому отсутствие образца имеет противоположный смысл в двух случаях. После 10 поток оборван. После 11 ожидание образца само становится ошибкой: анализатор заберёт начало следующего элемента.

У буквальной строки третье обещание: нулевой старший бит, положительная семибитная длина до 127 и ровно n байтов далее. Требуемое продолжение задаёт класс, а не наличие числа вообще.

TYPE заполнял пробел в MODE

В ASCII заполнителем служит пробел с кодом 32, в EBCDIC — пробел с кодом 64. Для Image и Local byte это нулевой байт. Один и тот же описатель разворачивается в пробелы либо нули без изменения данных на проводе.

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

У регистратора одного лишь канала данных остаётся длина, но исчезает материал. Хеш подтверждает кодированные октеты, однако не доказывает, какой файл получил тогдашний приёмник.

Повторение ещё не было заполнением

Форма 10 годится для любого значения, поскольку несёт образец. Форма 11 применима только к привилегированному заполнителю текущего представления. Ряд нулей в ASCII не превращается из-за одинаковости в заполнитель: там им является пробел. В Image нули можно вывести без образца.

Экономия опиралась на смысловую категорию. Переговоры заранее сузили выбор до одного значения, и поток мог не называть его повторно.

Управляющая информация шла четвёртым путём: нулевой escape-байт и второй описатель использовали коды BLOCK для следующей строки. До записи на диск автомат различал буквальный участок, явный повтор, неявный заполнитель и управление.

Поля печати занимали линию связи

RFC 959 объяснял COMPRESSED как обмен небольших затрат CPU на пропускную способность при очень крупных передачах. Особенно эффективными считались файлы печати, в том числе созданные RJE-хостами. Фиксированные поля и отступы порождали длинные полосы пробелов.

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

Вместе с экономией часть доказательства переходила в управляющее соединение. Если журнал ошибочно заменит TYPE A на TYPE I, будущая реконструкция изменится без единой правки потока. Если библиотека требует образец после всякого счётчика, она объявит законный ввод повреждённым.

Принятые параметры создавали эпохи разбора

TYPE, STRU и MODE устанавливались командами и ответами. Важен подтверждённый сервером режим, а не только запрос клиента. Отклонённая смена TYPE не меняет активное представление.

Каждая передача связывается с состоянием на её старте; принятая смена открывает новую эпоху декодирования. Следует хранить границы, начальное и конечное состояние, вход и результат. TCP-сегменты и локальные чтения не имеют грамматической силы и могут разрезать любую форму.

Базовый MODE не гарантировал все варианты

RFC 959 назначил S, B и C, сделав Stream режимом по умолчанию. Позднее RFC 1123 включил в минимальную реализацию только Stream. Стандартизация MODE C не доказывает его повсеместную поддержку тогда или сейчас.

RFC 5797 и реестр IANA сохраняют MODE как базовую параметрическую команду. Реестр координирует имя и ссылку, но не проверяет аргумент C, автомат или сохранность после записи.

Хранить кодировку вместе с результатом

Надёжный пакет доказательств содержит сырой поток, длину и хеш; хронологию принятых TYPE/STRU/MODE; класс, число и ожидаемое продолжение каждого элемента; управляющие события; конечное состояние; хеш канонического результата. Явный повтор и заполнитель остаются разными фактами даже при одинаковом выходе.

Тесты прогоняют один 11 под ASCII, EBCDIC, Image и Local byte, сравнивают его с 10 и эквивалентным образцом, делят многобайтовые формы между чтениями и завершают поток после повтора без образца. Ответ задают грамматика и контекст, не размер пакета.

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

Источники