推理曲线76作为MIME段的线路长度限制，由RFC 2045定义？ [英] Reasoning behing 76 being the line length limit for MIME sections, as defined by RFC 2045?

问题描述

RFC 2045将编码数据的最大行长定义为76 - 但是我找不到任何解释为什么是76.这个数字是完全任意的，还是有一些推理？

解决方案

RFC2822是电子邮件的传统标准。
在RFC2822的第2.1.1节中，您可以找到如下原因：
它也会影响MIME。

此标准有两个限制一行中
个字符数的位置。每行字符必须不超过
998个字符，并且应该不超过78个字符，不包括
CRLF。

998字符限制是由于在许多实现中发送，接收或存储Internet消息格式消息的
的限制，
根本无法处理一行上超过998个字符。接收
的实现将很好地处理一个任意大的
的一行字符中的健壮性。然而，有这样的
许多实现（符合[RFC2821]的传输
要求）不接受包含
超过1000个字符的消息，包括每行的CR和LF，对于不创建这样的消息的实现，
是重要的。

更保守的78字符建议是为了适应
许多用户界面的实现这些
消息可能会截断或灾难性地包装
的显示超过每行78个字符，尽管这样的
实现不符合此$的意图b $ b规范（如果实际导致
信息丢失，则为[RFC2821]规范）。再次，即使这个限制是放在
消息上，它显示消息
执行一行中任意大量的字符
（肯定至少达到998字符限制）为
鲁棒性。

RFC 2045 defines the maxmimum line length for encoded data as 76 - however I cannot find any explanation as to why it is 76. Is this number entirely arbitrary, or is there some reasoning behind it?

解决方案

RFC2822 is legacy standard of EMail. In section 2.1.1 of RFC2822, you can find reason as below: It also affects MIME.

There are two limits that this standard places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.

The 998 character limit is due to limitations in many implementations which send, receive, or store Internet Message Format messages that simply cannot handle more than 998 characters on a line. Receiving implementations would do well to handle an arbitrarily large number of characters in a line for robustness sake. However, there are so many implementations which (in compliance with the transport requirements of [RFC2821]) do not accept messages containing more than 1000 character including the CR and LF per line, it is important for implementations not to create such messages.

The more conservative 78 character recommendation is to accommodate the many implementations of user interfaces that display these messages which may truncate, or disastrously wrap, the display of more than 78 characters per line, in spite of the fact that such implementations are non-conformant to the intent of this specification (and that of [RFC2821] if they actually cause information to be lost). Again, even though this limitation is put on messages, it is encumbant upon implementations which display messages to handle an arbitrarily large number of characters in a line (certainly at least up to the 998 character limit) for the sake of robustness.

这篇关于推理曲线76作为MIME段的线路长度限制，由RFC 2045定义？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！