FTP MODE Cが未送信バイトを復元した仕組み

要約

フィラー形式は先頭二ビットが11で、残り六ビットが個数になる。この一バイトで命令は終わる。後続に値は置かれない。RFC 765とRFC 959はいずれもこの形を定義している。

任意の値を反復するときは10形式を使う。六ビットの個数に続いて、実際に反復する一バイトdを送る。したがって10の直後で入力が終われば切断だが、11の直後に値を要求すれば、正常な次項目を誤って消費する。

通常列はさらに別で、最上位ビットがゼロ、残り七ビットが1から127までの長さとなり、その後に同数のデータが続く。受信側は「長さがあるから値が続く」と一般化せず、形式ごとの約束を守らなければならない。

ASCIIのフィラーはコード32の空白、EBCDICではコード64の空白である。ImageまたはLocal byteならゼロバイトになる。同一のフィラー記述が、TYPEによって空白列にもゼロ列にもなる。

RFC 959は、表現と伝送モードを基本的に独立と説明しつつ、Compressedではフィラーの性質が表現型に依存すると明記した。ここは小さな例外ではなく、一バイト形式を成立させる入力関係である。

データ接続だけを取り出した解析器には、個数は見えても素材が見えない。ビット列のハッシュが一致しても、どのファイル像が当時の受信結果だったかまでは確定しない。

10形式は明示したサンプルを反復するため、任意の値に使える。11形式は、その表現であらかじめ「空き」とされた値だけを暗黙に復元する。ASCII中のゼロ列は、同値が続いていてもASCIIフィラーではない。Image中のゼロ列なら、サンプルなしで表せる。

つまりこれは頻度だけを見る圧縮ではなく、意味の分類を利用した圧縮だった。すでに交渉済みの知識を参照することで、送信側は値一個分を省いた。

制御情報にはゼロのエスケープと二番目の記述子を使い、BLOCKモードのコードを後続列へ適用した。リテラル、明示反復、暗黙フィラー、制御を判別する状態機械が、保存処理より前に必要だった。

RFC 959は、少量のCPU負荷と引き換えに大規模転送の帯域を節約できると述べ、RJEホストが作るプリンターファイルを有力例に挙げた。固定幅の帳票には、列や余白のための長い空白が生じる。

文字表現では空白、バイナリ系ではゼロを特別扱いする理由は、この運用背景から読める。汎用圧縮の歴史ではなく、当時の表現規則と負荷に密着した設計である。

ただし節約は、意味の一部を制御接続へ移した。ログがTYPEを誤って正規化すれば、データ列を一切変えずに将来の復元結果が変わる。すべての個数の後に値があると仮定する検査器は、正規入力を破損扱いする。

証拠として重要なのは、クライアントが送った命令だけでなく、サーバーが受理した命令と応答である。拒否されたTYPE変更は新しい状態を作らない。各データ転送は、その開始時点のTYPE、STRU、MODEへ結びつける必要がある。

パラメータ変更ごとに復号エポックを区切り、入力範囲、初期・終端状態、復元結果を保存する。TCPセグメントやread呼び出しの境界には文法上の意味がない。

RFC 959はS、B、Cを割り当て、既定をStreamとした。RFC 1123が後に定めた最小実装もStreamである。MODE Cが標準に存在したことと、あらゆる実装が対応したことは別の主張だ。

RFC 5797とIANAのFTP Commands and ExtensionsレジストリはMODEを基礎コマンドとして残す。これは語彙と参照の証拠であり、C引数やパーサーの適合試験ではない。

原データ列の長さとハッシュ、受理パラメータの時系列、各形式のクラスと個数、制御イベント、最終状態、正規化した出力のハッシュを一組にする。結果が偶然同じでも、フィラーと明示反復の由来を統合してはいけない。

カナリアでは同じ11をASCII、EBCDIC、Image、Local byteで実行し、同じ出力を作る10 + サンプルと比較する。複数バイト形式はread境界で分割し、サンプル前で終了するケースも含める。期待値を決めるのはパケット長ではなく、文法と状態である。

送信側が値を送らなかったのは、会話がすでにその値を名指していたからだ。借りた文脈で帯域を節約したなら、後世の証拠にはその文脈も返さなければならない。