18

RFC 2045 は、エンコードされたデータの最大行長を 76 と定義しています。しかし、76 である理由についての説明が見つかりません。この数は完全に恣意的ですか、それとも何らかの理由があるのでしょうか?

4

4 に答える 4

13

RFC2822 は、EMail の従来の標準です。RFC2822 のセクション 2.1.1 で、次のような理由を見つけることができます: MIME にも影響します。

この標準では、1 行の文字数に 2 つの制限があります。文字の各行は、CRLF を除いて、998 文字を超えてはならず、78 文字を超えてはなりません。

998 文字の制限は、1 行で 998 文字を超える文字を処理できない Internet Message Format メッセージを送信、受信、または保存する多くの実装における制限によるものです。受信実装は、堅牢性のために行内の任意の多数の文字を処理するのに適しています。ただし、([RFC2821] のトランスポート要件に準拠して) 行ごとに CR と LF を含む 1000 文字を超えるメッセージを受け入れない実装が非常に多いため、実装がそのようなメッセージを作成しないことが重要です。

より保守的な 78 文字の推奨事項は、これらのメッセージを表示するユーザー インターフェイスの多くの実装に対応することです。これらの実装は、1 行あたり 78 文字を超える表示を切り捨てたり、壊滅的に折り返す可能性があります。この仕様の意図 (および、実際に情報が失われる場合は [RFC2821] の意図)。繰り返しになりますが、この制限はメッセージに課せられますが、堅牢性のために、行内の任意の多数の文字 (確かに少なくとも 998 文字の制限まで) を処理するためにメッセージを表示する実装には負担がかかります。

于 2014-05-29T08:02:57.023 に答える
3

終了のキャリッジ リターンとライン フィードを含めて最大 80 行の長さは、最大 80 列の穴を含む古き良きパンチ カードに由来します。
なぜ80？どの本でも、1 行がスペースを含めて 80 文字を超えることはめったにないからです。
これは、終端のキャリッジ リターン (テレタイプまたはタイピング マシンのキャリッジを一番左の位置に移動する) とライン フィード (紙を 1 行進める) を含めて、最大 80 行の長さを意味していました。
Base64 は 4 文字の倍数であるため、CR+LF を除いて最大 76 文字になります。
もう 1 つの例は、衛星の軌道を記述する TLE (Two-Line Element set) です。2枚のパンチカードに収まります。
CR (左端への水平移動、垂直位置を維持) と LF (次の行への垂直移動、水平位置をそのまま維持) は 2 つの完全に独立したものなので、まだ両方を持っています。次の行は一番左の位置から開始する必要がありますね。
太字で印刷する場合、行は間に CR のみを入れて 2 回印刷されました。つまり、紙を進めません。したがって、標準シーケンスは最初に CR で、次に LF です。
ただし、古き良き機械式タイピング マシンは通常、最初に LF を実行し、次に CR を実行しました。

于 2019-12-06T10:01:20.317 に答える