Кратко

  • При STRU R и MODE S байт из одних единиц вводил двухбайтовый код: значение 1 означало EOR, 2 — EOF, 3 — обе границы в одной точке.
  • Если зарезервированный байт был данными, его повторяли. Получателю требовались согласованные параметры и состояние анализатора между чтениями.
  • В BLOCK и COMPRESSED те же границы переносили биты дескриптора. Запись, строка, сегмент TCP и буфер чтения оставались разными понятиями.

Решение откладывалось до соседа

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

Если второе значение равно 1, пара закрывает запись; 2 — файл; 3 — последнюю запись и файл одновременно. Первый байт сам по себе ещё не управление. Значение завершают следующий байт и ранее выбранное STRU R.

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

Упорядоченный поток не знал границ записей

FTP разделял структуру и режим. STRU F объявляла непрерывную последовательность байтов, STRU R — последовательность записей. MODE S определял представление на соединении данных.

Надёжная доставка по порядку не знает, где кончилась запись источника. Поэтому все EOR были явными, включая последний. Отправитель преобразовывал местное обозначение в общую форму FTP, получатель — в подходящую местную форму хранения.

Внутренний счётчик длины на одном мейнфрейме не был переносимым разделителем. Стандарт передавал общий смысл границы, а не внутреннюю разметку чужого диска.

Четыре продолжения одного состояния

Обычный байт анализатор выпускает сразу. Увидев признак, он ждёт продолжение. Оно либо выдаёт один буквальный байт, либо создаёт EOR, EOF или оба события.

Совмещённый код не требовал придумывать пустую запись после последней. Удвоение сохраняло в данных любое возможное значение. Встроенное управление оставалось обратимым.

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

Граница чтения могла разрезать пару

RFC 9293 определяет TCP как надёжный упорядоченный поток байтов, а не службу записей FTP. Один вызов чтения не обязан совпадать с единицей приложения.

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

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

При STRU F тот же байт снова был обычными данными

В сочетании STRU F + MODE S все байты являются данными, а EOF задаётся закрытием соединения данных. Байт из единиц не открывает специальную грамматику.

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

Закрытие тоже имеет разную доказательную силу. В File Structure оно обычно сообщает EOF. В Record Structure последний EOR должен быть явным. Успешное завершение соединения не доказывает завершение последней записи.

Другие режимы вынесли границы в дескрипторы

В BLOCK каждому блоку предшествовали длина и биты описания. Один бит отмечал EOR, другой EOF; оба могли быть установлены вместе. Ещё два относились к подозрительным данным и маркеру возобновления.

COMPRESSED также применял описания EOR/EOF и добавлял формы повторённых данных и заполнителя. Семантика границы сохранялась, но её вид на линии зависел от MODE.

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

Конец строки не был универсальным концом записи

FTP различал end-of-line и end-of-record. ASCII без структуры записей мог разделять строки CRLF, EBCDIC — NL. При STRU R EOR передавался отдельно.

В файлах «одна строка — одна запись» границы совпадают случайно. Запись может содержать несколько строк, а перевод строки быть только оформлением. Автоматическая замена даёт читаемый текст и всё же меняет источник.

RFC 959 требовала принимать структуру записей для ASCII/EBCDIC и стремиться к полезному обратимому преобразованию между файловыми и записными хостами. Читаемость не заменяла проверку исходного деления.

Позднее минимальное требование стало уже

RFC 1123 требовала Record Structure только от хостов, чьи файловые системы её поддерживали. Остальные могли принять STRU R и буквально сохранить поток.

Архивировать кодировку — не то же самое, что восстановить местные записи. Архив может позволить точное последующее извлечение, но не доказывает готовую структуру для приложений. Реконструкция, хранение, уплощение и отказ — разные результаты.

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

Декодер входит в цепочку доказательств

Надёжная запись хранит TYPE, STRU, MODE, хэши сырого потока и данных, обе длины, позиции EOR/EOF, закрытие, конечное состояние парсера и результат реконструкции.

Канарейки делят пару между чтениями, смешивают буквальное удвоение с тремя кодами и сравнивают STREAM с BLOCK для одной карты. Висящий escape, невозможное продолжение, отсутствующий финальный EOR или состояние после смены MODE означают ошибку смысла.

Байт появился дважды не из-за сетевого повтора. FTP зарезервировал вход в управление, не исключив законное значение данных; различие сохранял полный контекст.

Источники